Wie kann man den SPF-Eintrag optimieren?

Juli 28, 2020

11 Min Lesezeit

Wenn Sie eine Domain haben, die E-Mails versendet, haben Sie wahrscheinlich einen Standard-SPF-Eintrag, der bereits vom Hosting-Provider eingestellt wurde. Warum also müssen Sie den SPF-Eintrag optimieren?

Dieser Eintrag besteht in der Regel entweder aus A- oder IP4- / IP6- und MX-Mechanismen, wenn Sie ein dediziertes Hosting haben, oder aus MX- und INCLUDE-Mechanismen, wenn Sie Shared Hosting nutzen.

Dieser Standard-SPF-Eintrag stellt sicher, dass E-Mails, die von Ihrer Website oder Ihrem VPS-Rechner bei Ihrem Hosting-Provider gesendet werden, authentifiziert werden.

Im wirklichen Leben verwenden Unternehmen jedoch auch eine Vielzahl anderer Systeme von Drittanbietern, um E-Mails von ihrer Domain aus zu versenden (z. B. CRM oder Cloud-E-Mail-Anbieter wie G Suite oder Office 365), so dass der Standard-Eintrag geändert werden muss, um die Server abzudecken, von denen Systeme von Drittanbietern E-Mails senden, damit ihre E-Mails authentifiziert bleiben.

Erstellen eines neuen oder Ändern eines bestehenden SPF-Eintrags

Sie können einen neuen SPF-Eintrag erstellen oder einen bestehenden ändern, indem Sie eine der folgenden Möglichkeiten nutzen:

Verwenden Sie unseren SPF-Eintrag-Generator, um einen neuen SPF-Eintrag zu erstellen oder einen bestehenden zu aktualisieren. Dieses Tool generiert einen syntaktisch korrekten Eintrag und weist gleichzeitig auf die Probleme mit den verwendeten Mechanismen hin, wenn diese bei der Validierung des generierten Eintrags entdeckt werden.

Verwenden Sie unser SPF-Eintrag-Validierungstool, wenn Sie mit der SPF-Eintrag-Syntax gut vertraut sind und lieber mit dem Roheintrag arbeiten möchten. Dieses Tool validiert den Entwurf des Eintrags, zeigt den erweiterten SPF-Eintragsbaum an und hebt Probleme hervor, wenn sie gefunden werden.

Überprüfung des SPF-Eintrags auf korrekte Syntax und Einschränkungen

Bei der Pflege eines effizient arbeitenden SPF-Eintrags gibt es mehrere versteckte Herausforderungen. Einige davon beziehen sich auf die Syntax des Eintrags, andere auf Beschränkungen, die noch aus der Zeit stammen, als SPF als Standard eingeführt wurde (2006).

Hier ist die Liste der bekanntesten Fälle:

Verwendung des PTR-Mechanismus

Der PRT-Mechanismus verlangt ein DNS-Reverse-Mapping der sendenden IP-Adresse und führt dann eine DNS-Abfrage der zurückgegebenen Hostnamen durch, um zu überprüfen, ob die sendende IP-Adresse zu den aufgelösten IP-Adressen gehört. In Fällen, in denen die IP-Adresse in viele Hostnamen-Einträge aufgelöst wird, wie z. B. hier, werden mehrere DNS-Abfragen initiiert, was dazu führen kann, dass das Limit von 10 DNS-Abfragen erreicht wird, wie in einem der folgenden Punkte beschrieben. Es ist nicht möglich, den PTR-Mechanismus während der SPF-Eintragsprüfung zu validieren, da es sich um einen dynamischen Mechanismus handelt, der von der sendenden IP abhängt.

Verwendung von CDN zum Proxy für Domain DNS

Wenn Ihre Domain durch ein CDN wie z. B. Cloudflare geschützt ist und DNS A / AAAA-Einträge als Proxy verwendet werden, werden diese Einträge auf die Proxy-IP und nicht auf die tatsächliche IP-Adresse des Hosts, der die E-Mails sendet, aufgelöst. In solchen Fällen müssen Sie den A-Mechanismus durch IP4 / IP6 ersetzen und die tatsächliche IP-Adresse des sendenden Servers angeben.

10 DNS-Abfragen

„SPF zu viele DNS-Abfragen“ ist die häufigste Herausforderung, die auftritt, wenn zusätzliche E-Mail-Quellen zum SPF-Eintrag hinzugefügt werden. Gemäß RFC7208 sollte die maximale Anzahl der erlaubten DNS-Abfragen auf 10 begrenzt werden, um eine unangemessene Belastung des DNS zu vermeiden. Jeder der a-, mx- oder include-Mechanismen sowie der Redirect-Modifier weist den empfangenden Mailserver an, eine DNS-Abfrage durchzuführen, um die Hosts in IP-Adressen aufzulösen. Wenn der SPF-Eintrag, der vom include-Mechanismus aufgelöst wurde, einen weiteren include-Mechanismus enthält, erhöht sich die Anzahl der DNS-Abfragen um eins usw. Es ist nicht so einfach, die Anzahl der Abfragen zu zählen und die Überschreitung des Limits festzustellen, ohne ein spezielles Abfrage-Tool zu verwenden.

Der SPF-Eintrag wird von links nach rechts gelesen, daher wird der Mechanismus/Modifikator, der sich in der Zeichenkette nach der 10. Abfrage befindet, ignoriert und E-Mails, die von der Quelle kommen, die durch diese ignorierten Mechanismen definiert ist, werden bei der SPF-Authentifizierung mit dem Prüfergebniscode „permerror“ scheitern.

Zwei ungültige Abfragen

Dieser Fall wird im selben Abschnitt von RFC7208 erwähnt, in dem die Beschränkung von 10 DNS-Abfragen definiert wird. Wenn der A-, MX-, INCLUDE-Mechanismus im SPF-Eintrag den Hostnamen auflösen kann, die zurückgegebene Antwort aber ungültig ist (z. B. include:existing-domain-with-no-spf.com) oder ein Hostname nicht aufgelöst werden kann (z. B. a:non-exising-domain.com), dann spricht man von „ungültigen Abfragen“. Es wird empfohlen, die Verarbeitung von SPF-Einträgen zu stoppen, sobald die Anzahl der ungültigen Ergebnisse 2 erreicht hat. Ein Überschreiten dieses Limits sollte ebenfalls einen „Permerror“-Prüfergebniscode erzeugen.

Rekursive Abfragen

Es ist auch ziemlich schwer, den Fall zu erkennen, dass ein Include-Mechanismus direkte oder indirekte Include-Mechanismen zu sich selbst enthält, was eine Endlosschleife erzeugt und sofort zu einer Einschränkung der DNS-Abfragen führt. Zwei Beispiele für solche Einträge:

example.com TXT v=spf1 include:example.com ~all

ODER

sub1.example.com TXT v=spf1 include:sub2example.com include:sub3.example.com ~all

sub3.example.com TXT v=spf1 include:sub1.example.com ~all

Verwendung von Leerzeichen

Wenn Sie versehentlich ein zusätzliches Leerzeichen im Namen des Mechanismus oder der Domain eingeben (z. B. inclu de:_spf.google.com oder a:so mecrm.com oder ip 4:12.3 4.56.78 ), kann der Rest der Zeichenkette nach dem nicht erkannten Element ignoriert werden, so dass die korrekten Quellen, die nach dem fehlerhaften Element aufgelistet sind, fallen gelassen werden, wenn der empfangende Mailserver eine Suche nach Ihrem Domain SPF-Eintrag durchführt. Außerdem wird das Leerzeichen im Hostnamen, auf das die Mechanismen A und INCLUDE verweisen, als ungültige Abfrage behandelt.

Mehr als ein SPF-Eintrag

Sie müssen sicherstellen, dass nur ein TXT-Eintrag, der mit „v=spf1“ beginnt, in der Domain-DNS existiert. Mehr als ein TXT-Eintrag, der mit „v=spf1“ beginnt, führt zu unvorhersehbaren Ergebnissen bei der Suche durch den empfangenden Mailserver und die SPF-Validierung kann fehlschlagen.

Länge des SPF-Eintrags

Die maximale Länge eines einzelnen TXT-Eintrags ist auf 255 Byte begrenzt. Gemäß RFC7208 können jedoch mehrere Datenstrings mit einer Länge von jeweils bis zu 255 Byte zu einem TXT-Eintrag verkettet werden, wenn Sie einen längeren SPF-Eintrag benötigen. Z.B.TXT „v=spf1 …. first string-“ „second string…“ wird geparst als TXT „v=spf1 …. first string-second string…“.

Sie müssen auch sicherstellen, dass die DNS-Zonenverwaltungsschnittstelle Ihres Domain Host Providers TXT-Einträge unterstützt, die länger als 255 Bytes sind. Sollte dies nicht der Fall sein, müssen Sie in Erwägung ziehen, Ihre Domain-DNS-Zone auf ein alternatives System zu verschieben, das lange TXT-Einträge unterstützt, z. B. Cloudflare. Neben dem oben Gesagten gibt es eine weitere wichtige Einschränkung, die speziell für SPF-TXT-Einträge gilt. Es wird empfohlen, die Eintragsgröße klein genug zu halten, so dass das Ergebnis der DNS-Abfrageantwort 512 Bytes umfasst. Andernfalls besteht die Möglichkeit, dass eine im DNS-Protokoll festgelegte Grenze für die Größe von UDP-Paketen überschritten wird. Obwohl diese Beschränkung in RFC6891 überarbeitet wurde, sollte die Unterschreitung von 512 Bytes immer noch Fälle vermeiden, in denen Parteien mit älteren, nicht RFC6891-konformen DNS-Implementierungen E-Mails von Domains mit langen SPF-Einträgen nicht validieren können. Tatsächlich gibt die DNS-Abfrage, die zum Lesen des SPF-Eintrags ausgeführt wird, nicht nur den SPF-Eintrag zurück, sondern alle TXT-Einträge, die im Domain-DNS veröffentlicht sind. Da Ihre Domain andere TXT-Einträge haben kann (und wahrscheinlich auch hat), wie z.B. Google Websites, Microsoft O365 oder andere Systeme, die TXT-Einträge verifizieren, müssen Sie daran denken, diese ebenfalls zu zählen, wenn Sie die verbleibende Größe für den SPF-Eintrag berechnen (512 – DNS-Hostname – Länge aller anderen TXT-Einträge) Sie können den txt-Befehl dig example.com unter Linux oder das Online-Tool Dig Web Interface verwenden, um zu sehen, wie viele TXT-Einträge Sie haben und die sichere Größe für den SPF-Eintrag zu berechnen:

Alle oben genannten Fälle können von unserem Tool zur SPF-Eintrag-Abfrage erkannt und angezeigt werden, siehe Screenshot:

Optimierung des SPF-Eintrags

Nachfolgend finden Sie die Schritte, die Ihnen helfen, den SPF-Eintrag zu optimieren:

Reihenfolge der Quellen ändern

Der SPF-Eintrag wird von links nach rechts gelesen, daher ist es sinnvoll, die wichtigsten oder am häufigsten verwendeten E-Mail-Quellen an den Anfang des Eintrags zu setzen.

Bereinigung des Eintrags von doppelten Quellen

Manchmal müssen Sie teuren SPF-Speicherplatz von doppelten Quellen freimachen und neue Quellen hinzufügen, insbesondere wenn Sie kurz davor sind, die Grenze von 10 DNS-Abfragen zu erreichen. Verwenden Sie unser Tool zur SPF-Eintrag-Abfrage, um doppelte Quellen in der erweiterten Struktur des SPF-Eintrags zu erkennen.

Beseitigung veralteter/überholter Quellen

Wenn Sie die DMARC-Berichte über einen ausreichenden Zeitraum (z. B. 1-2 Monate) analysieren, können Sie einige zum SPF-Eintrag hinzugefügte Quellen erkennen, die in diesem Zeitraum keine E-Mails versendet haben. Vergewissern Sie sich, ob die zugehörigen Systeme noch in Ihrem Unternehmen verwendet werden, und entfernen Sie sie, wenn sie nicht mehr verwendet werden.

Reduzierung der Anzahl der INCLUDEs

Jeder INCLUDE-Mechanismus benötigt eine DNS-Abfrage. Wenn der INCLUDE-Mechanismus keine direkt hinzugefügten IP4/IP6-Mechanismen enthält, sondern andere INCLUDEs, die ebenfalls eine DNS-Abfrage erfordern, können Sie versuchen, diese INCLUDEs durch IP4/IP6 zu ersetzen.

Dies ist jedoch ein sehr heikler Schritt, insbesondere wenn sich INCLUDE auf einen ESP-Dienst einer dritten Partei bezieht. Es kann leicht passieren, dass Sie die SPF-Konformität Ihrer E-Mails verletzen, weil Sie nie wissen werden, ob Ihr ESP eines Tages beschließt, E-Mails von neuen IPs zu versenden und sein SPF zu aktualisieren. Außerdem müssen Sie an die empfohlene Begrenzung der Größe des SPF-Eintrags denken, die in ein DNS-Abfrage-UDP-Antwortpaket passt (512 Byte).

Verwendung von MX- und A-Mechanismen vermeiden

Der MX-Mechanismus nimmt eine DNS-Abfrage vom Limit von 10 DNS-Abfragen und löst außerdem eine DNS-Abfrage für Hostnamen aus, auf die Ihre MX-Einträge verweisen. Diese Nachforschungen werden zwar nicht auf das SPF-DNS-Abfrage-Limit angerechnet, können aber die Latenzzeit der E-Mail-Zustellung erhöhen.

Es wäre sinnvoller, stattdessen IP4-/IP6-Mechanismen zu verwenden und IP-Bereiche einzubeziehen, von denen aus Ihre MX-E-Mails gesendet werden, um die Antwortzeiten auf DNS-Abfragen zu verkürzen.

Die Verwendung von IP4/IP6-Direktiven ist auch für den A-Mechanismus geeignet.

sender-domain-unaligned Quellen entfernen

Wie Sie wissen, wird die SPF-Prüfung anhand der Domain in der Return-path-E-Mail-Adresse (smtp.mailfrom) oder der Domain in smtp.helo (wenn smtp.mailfrom leer ist) durchgeführt. Normalerweise sind die Domain in der „Header From“- und „Return-path“-Adresse dieselbe. In Google Mail sehen Sie die „Header From“-Adresse im From-Feld und die „Return-path / smtp.helo“-Domain im Mailed-by-Feld.

Siehe nachstehendes Beispiel:

Header From: VMware <[email protected]>

Return-Path: <[email protected]>

Einige ESPs verwenden jedoch ihre eigene Domain in der Return-Path-E-Mail-Adresse, siehe Beispiel unten:

Header From: Booked Scheduler <[email protected]>

Return-Path: <bounce-mc.us19_134631002.4790858-956d20b353@mail249.suw12.mcsv.net>

In den Konfigurationshandbüchern vieler dieser „nicht konformen“ ESPs wird entweder empfohlen oder verlangt, dass Sie deren SPF-Include-String in den SPF-Eintrag Ihrer Domain aufnehmen. Offensichtlich ist dies das Ergebnis mangelnder Kenntnisse über die Funktionsweise der SPF-Verifizierung. Einige der bekannten ESPs, die ihre eigene Domain in Return-Path-Adressen verwenden, sind Active Campaign, Aweber, Mailchimp, Marketo und Salesforce.

Da, wie bereits erwähnt, der empfangende Server eine Überprüfung des SPF-Eintrags der Domain durchführt, der in der Return-path-Adresse und nicht in der Header From-Adresse angegeben ist, ist es nicht erforderlich, den SPF-Include-String des ESP in den SPF-Eintrag Ihrer Domain einzufügen. Dies würde nur teuren Speicherplatz belegen und unnötige DNS-Abfragen auslösen.

Verschieben eines Teils der Quellen in die Subdomain

Wenn aufgrund der Verwendung vieler INCLUDE-Mechanismen das Limit von 10 DNS-Abfragen vollständig ausgeschöpft ist, können Sie versuchen, einige E-Mail-Quellen so zu rekonfigurieren, dass sie von einer Subdomain und nicht von der Root-Domain gesendet werden (siehe das VMware-E-Mail-Beispiel in Punkt 6), und die INCLUDE-Zeichenfolge dieser Quellen in einen neuen SPF-Eintrag verschieben, der für die Subdomain erstellt wurde.

Verwendung unseres EasySPF zur intelligenten und dynamischen Verflachung des SPF-Eintrags

Und schließlich, wenn Sie die obigen 7 Empfehlungen nicht selbst umsetzen möchten, was definitiv viel Zeit für die Optimierung in Anspruch nehmen wird, sowie eine regelmäßige Überprüfung der SPF-Einträge von Drittanbieter-ESPs auf mögliche Änderungen voraussetzt (anwendbar, wenn Sie die Empfehlung #4 umsetzen), können Sie unsere EasySPF-Lösung verwenden, die alle obigen Empfehlungen automatisch für Sie erledigt, ohne jegliches Eingreifen Ihrerseits.

Sie müssen lediglich den EasySPF-Dienst aktivieren und Ihren SPF-Eintrag durch unseren angepassten Eintrag für Smart SPF ersetzen.