Was passiert, wenn SPF eine Domäne einschließt, die keinen SPF, sondern einen A-Eintrag hat?

Was passiert, wenn SPF eine Domäne einschließt, die keinen SPF, sondern einen A-Eintrag hat?

Ein Unternehmen, dessen Mailserver wir gelegentlich zum Versenden von E-Mails verwenden, hat uns gebeten, seine Domäne wie folgt in unseren SPF-Eintrag aufzunehmen: v=spf1 [...] include:app.sgizmo.eu ~all.

Nun stellt sich heraus, dass es in der Domäne, auf die wir verweisen, tatsächlich keinen SPF-Eintrag gibt app.sgizmo.eu. Die einzigen Einträge dort sind AEinträge, die sich ständig ändern (wahrscheinlich Cloudflare).

Nach allem, was ich über SPF weiß, bedeutet das Fehlen von SPF-Einträgen, app.sgizmo.eudass unser includeabsolut keine Auswirkungen hat. Es ist, als ob es nicht da wäre.

Was mich verwirrt ist, dass das SPF-Check-Toolspf-record.comapp.sgizmo.eu Alistet die im Datensatz für den E-Mail-Versand erscheinenden IPs allowedmit folgendem Wortlaut auf:

Zusätzliche, externe SPF-Einträge.

Wir konnten weitere autorisierte Datensätze im SPF-Eintrag finden: app.sgizmo.eu

A-Einträge: 52.222.174.243 52.222.174.77 52.222.174.112 52.222.174.23

Ist das ein Fehler des Tools? Oder verstehe ich SPF falsch und das Fehlen eines SPF-Eintrags bedeutet, dass A-Einträge als akzeptierte IPs gelten?

Antwort1

Ihr Verständnis ist richtig und dies scheint ein Fehler im Tool zu sein. Oder vielleicht ist es gängige Praxis, vom RFC für SPF abzuweichen und dieses Verhalten zuzulassen.

Wenn Sie dieDmarcian-Werkzeug, wird es fehlschlagen, wie es gemäß dem SPF RFC sein sollte.RFC-ZuständeDer Include-Mechanismus sollte auf einen gültigen SPF( TXT)-Eintrag verweisen. Falls keiner gefunden wird, sollte ein PERMERROR zurückgegeben werden.

Damit dies funktioniert, können Sie hinzufügen a:app.sgizmo.eu, wenn dies tatsächlich die IP-Adressen sind, die zum Versenden von E-Mails in Ihrem Namen verwendet werden.

verwandte Informationen