Was ist die Syntax eines SPF-Eintrags, und wie wirkt sie sich auf Anwendungs-E-Mails aus?

Ein SPF-Eintrag ist ein geordneter Richtlinienausdruck

RFC 7208 definiert einen SPF-Eintrag als DNS-TXT-String, dessen erster Term v=spf1 ist. Die übrigen, durch Leerzeichen getrennten Terme sind Mechanismen, die zutreffen können, und Modifier, die die Verarbeitung verändern. Die Auswertung läuft von links nach rechts und endet beim ersten zutreffenden Mechanismus; die Reihenfolge drückt also die Richtlinie aus. Ein typischer Eintrag könnte zwei feste Adressbereiche autorisieren, eine Provider-Richtlinie einbinden und dann mit -all enden. Übernehmen Sie dieses Muster nicht unverändert: Der richtige Eintrag hängt von den exakten SMTP-Identitäten MAIL FROM oder HELO und den tatsächlichen Versandquellen ab. Erfassen Sie zuerst Anwendungs-Provider, Mailserver, Support-Tools, Identitätsplattformen, Marketingsysteme, Weiterleitungspfade und Absender für den Notfallbetrieb. Veröffentlichen Sie die Richtlinie an der Domain, die ausgewertet wird, und nicht automatisch an der sichtbaren From-Domain. Auch ein syntaktisch gültiger Eintrag kann die falschen Quellen autorisieren, einen produktiven Stream auslassen oder die Grenzen der DNS-Auswertung überschreiten.

Qualifier ordnen einem zutreffenden Mechanismus ein SPF-Ergebnis zu

Ein Mechanismus kann mit einem Qualifier beginnen: + für pass, - für fail, ~ für softfail oder ? für neutral. Fehlt der Qualifier, gilt +. Der Qualifier wirkt nur, wenn der Mechanismus zutrifft. Er ändert nichts daran, ob spätere Terme ausgewertet werden, wenn der Mechanismus nicht zutrifft. Teams konzentrieren sich oft auf den abschließenden all-Term, doch auch jeder vorherige include-, Adress-, a-, mx- oder exists-Mechanismus hat einen Qualifier und kann die Auswertung beenden. Prüfen Sie das ausdrücklich, statt anzunehmen, dass ~all einen Testmodus bedeutet oder -all belegt, dass jede Quelle bekannt ist. Ein fail-Ergebnis ist ein Nachweis des Empfängers über die ausgewertete SMTP-Identität und IP, kein allgemeiner Befehl, die E-Mail zu löschen. Empfänger wenden ihre lokale Richtlinie an. Neutral und softfail sind keine bestandene Autorisierung. Halten Sie das beabsichtigte Ergebnis für autorisierte, nicht autorisierte und vorübergehend nicht auflösbare Quellen fest und prüfen Sie es mit kontrollierten IP- und Identitäts-Fixtures.

Adressmechanismen sind direkt, setzen aber Zuständigkeit voraus

Die Mechanismen ip4 und ip6 autorisieren passende Netzbereiche in der jeweiligen protokollspezifischen Syntax mit optionaler Präfixlänge. Sie ersparen zusätzliche Adress-Lookups bei der Auswertung, können aber veralten, wenn sich Egress-Netze ändern. Verwenden Sie öffentliche Versandadressen, niemals private Laufzeitadressen, und halten Sie die Bereiche so eng, wie es das betriebliche Failover erlaubt. Jeder Bereich sollte einen Verantwortlichen, ein Quellsystem, eine Umgebung, ein Änderungsverfahren und ein Prüfdatum haben. Der a-Mechanismus löst einen A- oder AAAA-Namen auf; standardmäßig ist das die aktuelle SPF-Domain, sofern keine andere domain-spec angegeben ist. Der mx-Mechanismus löst MX-Hosts und deren Adressen auf. Diese Mechanismen verursachen zusätzliche DNS-Arbeit und können Infrastruktur autorisieren, die sich außerhalb der Releases der Anwendung ändert. Nutzen Sie a oder mx nicht als Abkürzung, es sei denn, alle aufgelösten Adressen dürfen bewusst mit genau dieser SMTP-Identität senden. Überwachen Sie Änderungen und testen Sie sowohl IPv4- als auch IPv6-Pfade.

include wertet eine andere Richtlinie aus, kein Textfragment

Der include-Mechanismus wertet die SPF-Richtlinie der referenzierten Domain aus und trifft zu, wenn diese verschachtelte Auswertung pass ergibt. Er fügt keine Terme mechanisch in den aktuellen String ein, und andere verschachtelte Ergebnisse haben festgelegte Auswirkungen. Verwenden Sie include nur, wenn die referenzierte Organisation diese Domain ausdrücklich für Ihre Versandbeziehung dokumentiert. Die Website-Domain, MX-Domain oder sichtbare From-Domain eines Providers ist nicht automatisch sein SPF-include. Includes schaffen betriebliche Abhängigkeiten: Eine Änderung am Eintrag des Providers kann die Autorisierung verändern, weitere verschachtelte DNS-Lookups hinzufügen oder vorübergehende und permanente Fehler verursachen. Halten Sie Anbieter, Dienst, exakte include-Domain, vertragliche Quelle, Verantwortlichen und Plan für die Entfernung fest. Testen Sie die resultierende Richtlinie mit der tatsächlichen Versand-IP des Providers und Ihrer Envelope-Domain. Lösen Sie Provider-Includes niemals in kopierte IP-Listen auf, es sei denn, Sie übernehmen auch die Verantwortung, jede Adressänderung des Providers nachzuverfolgen und die ursprüngliche Semantik zu erhalten.

all, redirect und exp erfüllen unterschiedliche Aufgaben

Der all-Mechanismus trifft immer zu und steht normalerweise am Ende; Terme danach haben keinen Einfluss auf die Auswertung. Sein Qualifier bestimmt das Ergebnis für Quellen, auf die vorher nichts zugetroffen hat. Der redirect-Modifier weist SPF an, die Richtlinie einer anderen Domain zu verwenden, wenn kein Mechanismus im aktuellen Eintrag zugetroffen hat. redirect ist nicht dasselbe wie include: include ist ein Mechanismus in der Reihenfolge, während redirect unter den festgelegten Bedingungen die abschließende Richtlinienentscheidung ersetzt. Ein Eintrag sollte nicht mehrere redirect-Modifier enthalten. Der exp-Modifier kann auf eine Erklärung für ein fail-Ergebnis verweisen, autorisiert aber keine E-Mails und bringt zusätzliche betriebliche und datenschutzrelevante Aspekte mit sich. Halten Sie Erklärungen allgemein und vermeiden Sie Absender- oder Empfängerdaten. Wählen Sie redirect, wenn Domains bewusst eine komplette Richtlinie teilen und gemeinsam verwaltet werden. Wählen Sie include, wenn Sie die autorisierten Quellen eines Providers in eine umfassendere lokale Richtlinie aufnehmen. Testen Sie auch Pfade, auf die nichts zutrifft, nicht nur die erwarteten pass-Ergebnisse.

ptr vermeiden, exists und Makros als fortgeschritten behandeln

RFC 7208 besagt, dass der ptr-Mechanismus nicht verwendet werden sollte, weil er langsam, unzuverlässig und belastend ist. Fügen Sie ptr nicht hinzu, nur damit eine unbekannte IP besteht. Der exists-Mechanismus kann mit einer domain-spec einen DNS-Existenztest durchführen, und SPF-Makros können Bestandteile von Identität und Verbindung in unterstützten Feldern expandieren. Mit diesen Werkzeugen lässt sich delegierte oder kundenspezifische Autorisierung ausdrücken, sie erhöhen aber Komplexität, DNS-Arbeit, Datenschutzrisiken und Fehlerquellen. Die Makrosyntax ist kein beliebiges String-Templating; gültig sind nur festgelegte Buchstaben, Transformer, Trennzeichen und Kontexte. Setzen Sie niemals vollständige Empfängeradressen, Geheimnisse oder unbegrenzte Mandanteneingaben in DNS-Abfragen ein. Lässt sich die Richtlinie mit einer einfachen Menge eigener IP-Bereiche und dokumentierter Provider-Includes ausdrücken, ziehen Sie das vor. Erstellen Sie für fortgeschrittene Richtlinien vor dem Produktivbetrieb deterministische Fixtures für mehrere Domains, Absender, IP-Familien, leere Reverse-Paths, Makro-Escaping, NXDOMAIN, Timeouts und unerwartete DNS-Antworten.

Das Limit von zehn DNS-Lookups einhalten

RFC 7208 begrenzt SPF-Implementierungen auf zehn Terme, die während einer Prüfung DNS-Abfragen auslösen, einschließlich der Verarbeitung von include, a, mx, ptr, exists und redirect. Verschachtelte Includes zählen mit. Die Spezifikation empfiehlt außerdem, Void-Lookups – bei denen das DNS eine leere Antwort oder einen Namensfehler liefert – auf zwei zu begrenzen. Werden Verarbeitungslimits überschritten, kann statt eines pass ein permanenter Fehler entstehen. Zählen Sie den expandierten Auswertungsgraphen, nicht nur die im TXT-String der obersten Ebene sichtbaren Terme. Ein einziges Provider-include kann mehrere verschachtelte Abhängigkeiten mitbringen, und ein mx-Mechanismus kann Adress-Lookups für mehrere Hosts auslösen. Verwenden Sie einen standardkonformen Evaluator mit aufgezeichneten DNS-Fixtures, prüfen Sie den Abhängigkeitsbaum aber auch selbst. Entfernen Sie nicht genutzte Provider und redundante Mechanismen. Vermeiden Sie unsicheres Flattening, bei dem Provider-Aktualisierungen stillschweigend verloren gehen. Überwachen Sie Richtlinienänderungen und lassen Sie Spielraum für künftige Änderungen der Provider, statt genau am Maximum zu arbeiten.

Genau eine SPF-Richtlinie pro Domain veröffentlichen

RFC 7208 verwendet DNS-TXT-Einträge für SPF und verlangt, den Eintrag auszuwählen, der mit v=spf1 beginnt. Mehrere SPF-Einträge unter demselben exakten Namen führen zu einem permanenten Fehler, statt die Autorisierungen zusammenzuführen. Ändern Sie die bestehende Richtlinie in abgestimmter Zuständigkeit; legen Sie keinen zweiten TXT-Eintrag an, weil eine weitere Anwendung Zugriff braucht. Andere, nicht zusammenhängende TXT-Einträge unter dem Namen können daneben bestehen, aber es sollte nur eine ausgewählte SPF-Richtlinie geben. Prüfen Sie, wie die DNS-Verwaltung mit Anführungszeichen und dem Aufteilen von Strings umgeht, fragen Sie die autoritativen Server ab und danach unabhängige rekursive Resolver. Bewahren Sie den vorherigen Wert und die TTL für einen Rollback auf. Die DNS-Propagierung erfolgt nicht sofort, und negative Caches können bestehen bleiben. Ein grüner Haken im Dashboard belegt nur die dort beobachtete Abfrage und das Verhalten des Parsers. Prüfen Sie die exakte produktive Envelope-Domain anhand roher Received-Header und Provider-Logs, einschließlich Subdomains und Bounce-Adressen, die eigene Richtlinien veröffentlichen können.

SPF-Syntax mit DMARC verbinden, ohne beides zu vermischen

SPF wertet nach den Protokollregeln normalerweise die MAIL-FROM-Domain oder die HELO-Identität aus. DMARC verwendet die sichtbare From-Domain nach RFC 5322 und akzeptiert SPF nur dann als Weg, wenn die per SPF authentifizierte Domain mit dieser sichtbaren Domain ausgerichtet ist. Ein Return-Path des Providers kann daher SPF bestehen und für DMARC trotzdem nicht ausgerichtet sein. Umgekehrt kann ein ausgerichtetes DKIM-pass DMARC erfüllen, wenn SPF fehlschlägt oder nicht ausgerichtet ist. Erfassen Sie SPF-Ergebnis, ausgewertete Domain, verbindende IP, sichtbares From, DKIM-Ergebnisse, Alignment und DMARC-Ergebnis getrennt. Weiterleitungen ändern häufig die verbindende IP und können SPF brechen, selbst wenn der ursprüngliche Absender autorisiert war. Erweitern Sie SPF nicht um beliebige Weiterleitungsdienste. Nutzen Sie DKIM und, wo sinnvoll, Mechanismen für authentifizierte Ketten sowie Nachweise der Empfänger. Ein SPF-pass belegt weder die Integrität der Nachricht noch die Unbedenklichkeit des Inhalts, die Einwilligung des Empfängers, die Annahme durch den Server oder die Platzierung im Posteingang.

Änderungen mit einem deterministischen Workflow prüfen

Exportieren Sie vor einer DNS-Änderung den aktuellen Eintrag und listen Sie jeden Mechanismus und Modifier mit Verantwortlichem und Zweck auf. Parsen Sie den Kandidaten nach der Grammatik von RFC 7208, expandieren Sie die DNS-Abhängigkeiten aus kontrollierten Snapshots, zählen Sie die Lookup-auslösenden Terme und testen Sie autorisierte und nicht autorisierte IPv4- und IPv6-Fixtures. Prüfen Sie das Verhalten verschachtelter Includes bei pass, fail, neutral, softfail, temporärem und permanentem Fehler. Testen Sie die Behandlung eines leeren Reverse-Path über HELO, Subdomains, Return-Paths von Providern und eine Quelle, die bis zu all durchfallen sollte. Veröffentlichen Sie über die üblichen Änderungsprozesse, fragen Sie autoritatives und rekursives DNS ab und senden Sie dann kontrollierte Nachrichten über jeden tatsächlichen Stream. Bewahren Sie die rohen Authentication-Results vertrauenswürdiger Empfänger auf und vergleichen Sie sie mit den erwarteten Identitäten. Rollen Sie zurück bei fehlenden produktiven Quellen, Auswahl mehrerer Einträge, Fehlern durch das Lookup-Limit, verbreitetem temperror oder unbeabsichtigter Autorisierung. Testen Sie niemals, indem Sie unerwünschte E-Mails senden.

SPF mit SendHQ einrichten

SendHQ stellt im Rahmen der Einrichtung der Absenderidentität eine SPF-TXT-Richtlinie bereit. Bei widersprüchlichen SPF-Richtlinien wird die Einrichtung gestoppt und ein empfohlener zusammengeführter SPF-Wert gemeldet, statt eine unabhängige Richtlinie stillschweigend zu überschreiben. Behalten Sie genau eine auswählbare SPF-Richtlinie; Details zu Einrichtung und Reparatur finden Sie in der Dokumentation Domains und DNS.

Häufig gestellte Fragen

Quellen

• RFC 7208: Sender Policy Framework — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC-Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC-Editor