Wie prüfen Sie einen SPF-Eintrag für Anwendungs-E-Mails?

Mit der Identität beginnen, die SPF tatsächlich prüft

Eine SPF-Prüfung braucht drei Eingaben: die IP-Adresse des SMTP-Clients, die Domain, deren Autorisierungsrichtlinie ausgewertet wird, und die Absenderidentität. Bei gewöhnlichen Anwendungs-E-Mails stammt diese Domain aus der SMTP-Adresse MAIL FROM, auch Envelope-Absender oder Return-Path genannt. Sie kann sich von der Adresse unterscheiden, die Menschen im From-Header der Nachricht sehen. Ist MAIL FROM leer, wie normalerweise bei einer Zustellstatusbenachrichtigung, verwendet SPF die HELO-Identität für die MAIL-FROM-Prüfung. Erfassen Sie die echte Verbindungs-IP und die Envelope-Identität aus einer empfangenen Testnachricht oder der Konfiguration des sendenden Providers, bevor Sie DNS abfragen. Eine Prüfung von example.test, nur weil die Domain im From steht, ist nicht aussagekräftig, wenn die Anwendung tatsächlich mit MAIL FROM unter bounce.provider.test oder bounces.example.test sendet.

TXT an der exakten MAIL-FROM-Domain abfragen

Fragen Sie DNS-TXT an genau der Domain ab, die Sie im ersten Schritt bestimmt haben. RFC 7208 schreibt vor, dass Richtlinien der SPF-Version 1 als TXT-Einträge unter dem Owner-Namen veröffentlicht werden, für den sie gelten. Ignorieren Sie fremde TXT-Werte und wählen Sie die Einträge, deren Versionsabschnitt exakt v=spf1 lautet. Wird kein Eintrag gefunden, ergibt SPF none. Mehr als ein gefundener SPF-Eintrag ergibt permerror; getrennte Einträge für verschiedene Anbieter zu veröffentlichen ist kein gültiger Weg, sie zu kombinieren. Ein einzelner TXT-Resource-Record kann von DNS-Tools in mehrere Zeichenketten in Anführungszeichen aufgeteilt werden, doch diese Zeichenketten werden vor dem Parsen von SPF ohne eingefügte Leerzeichen verkettet. Erfassen Sie die vollständige Antwort, den Resolver, die Abfragezeit und die TTL, damit sich die Prüfung nach einer Änderung wiederholen lässt.

Syntax validieren und Terme von links nach rechts auswerten

Ein SPF-Eintrag ist eine geordnete Richtlinie, keine ungeordnete Liste von Providern. Nach v=spf1 werden die Mechanismen von links nach rechts ausgewertet, bis einer zutrifft. Ein vorangestellter Qualifier bestimmt das Ergebnis: + bedeutet pass und ist der Standard, - bedeutet fail, ~ bedeutet softfail und ? bedeutet neutral. Die Mechanismen ip4 und ip6 vergleichen die Client-Adresse mit einer Adresse oder einem Netz. Die Mechanismen a und mx lösen DNS auf, während include die SPF-Richtlinie einer anderen Domain auswertet und nur nach den include-Regeln zutrifft. exists führt einen DNS-basierten Test durch. all trifft immer zu und schließt den Eintrag üblicherweise ab. Syntaxfehler an beliebiger Stelle führen zu permerror, bevor die normale Auswertung beginnt. Ein brauchbarer Checker sollte melden, welcher Mechanismus zugetroffen hat, mit welchem Qualifier, und jede aufgelöste Domain nennen, statt nur ein farbiges Badge zurückzugeben.

include und redirect verfolgen, ohne sie als Aliase zu behandeln

Verfolgen Sie jedes include und jedes redirect im selben Auswertungskontext. include ist ein Mechanismus: Er fragt, ob die eingebundene Richtlinie für den aktuellen Client und Absender pass liefert, und setzt die Auswertung im ursprünglichen Eintrag fort, wenn nicht. redirect ist ein Modifier, der erst berücksichtigt wird, wenn keiner der Mechanismen des aktuellen Eintrags zutrifft; er übergibt die Auswertung an eine andere Richtlinie und behält dabei Client-IP und Absender bei. Ein redirect wird ignoriert, wenn all irgendwo im Eintrag vorkommt. Diese Unterschiede sind bei Migrationen wichtig. Wer include:vendor.test durch redirect=vendor.test ersetzt, ersetzt womöglich die gesamte Fallback-Richtlinie des Domaininhabers, statt nur einen Anbieter hinzuzufügen. Erkennen Sie Zyklen, fehlende Ziele, ungültige Ziele sowie verschachtelte dauerhafte oder vorübergehende Fehler, und bewahren Sie die Abhängigkeitskette im Ergebnis auf, damit eine Richtlinienänderung auf Provider-Seite sichtbar wird.

Das gesamte Budget an DNS-Abfragen zählen

Zählen Sie die Terme, die DNS-Abfragen auslösen, über die gesamte rekursive Auswertung – nicht nur im obersten Eintrag. RFC 7208 begrenzt die Terme include, a, mx, ptr, exists und redirect auf zehn pro SPF-Auswertung; wird das Limit überschritten, ist permerror vorgeschrieben. Die Mechanismen all, ip4 und ip6 verbrauchen nichts von diesem Budget. Für die Verarbeitung von MX und PTR gelten zusätzliche Limits für Adressabfragen. Das RFC empfiehlt außerdem, leere Lookups – also erfolgreiche leere Antworten oder Namensfehler – auf zwei zu begrenzen und bei Überschreitung permerror zu liefern. Vom Mechanismus ptr wird abgeraten, weil er langsam und unzuverlässig ist. Ein Eintrag kann kurz aussehen, während die includes der Provider zu so vielen verschachtelten Termen aufgelöst werden, dass er scheitert. Melden Sie daher die Gesamtzahl, jeden beitragenden Term, die leeren Lookups und den genauen Zweig, der für die getestete IP durchlaufen wurde.

Das SPF-Ergebnis deuten, ohne es zu überschätzen

Verwenden Sie das Standardvokabular für Ergebnisse. pass bedeutet, dass der getestete Client die geprüfte SMTP-Identität verwenden darf. fail bedeutet, dass eine zutreffende negative Autorisierung gefunden wurde. softfail ist eine schwache negative Aussage, während neutral besagt, dass die Domain über diesen Client nichts aussagt. none bedeutet, dass kein SPF-Eintrag gefunden wurde. temperror steht für ein vorübergehendes Problem bei der Auswertung, meist im DNS; permerror steht für eine Richtlinie, die sich nicht korrekt auswerten lässt. Trifft kein Mechanismus zu und greift kein redirect, ist das Ergebnis neutral, gleichbedeutend mit einem impliziten ?all. Melden Sie das Ergebnis zusammen mit Identität, Client-IP, zutreffendem Term, DNS-Trace und Zeitpunkt. Übersetzen Sie pass nicht in sichere Nachricht, erwünschte E-Mail, Annahme durch den Provider, Zustellung ins Postfach oder Platzierung im Posteingang, denn SPF entscheidet über keines dieser Ergebnisse.

Eine echte Nachricht prüfen, nicht nur den veröffentlichten Eintrag

Eine statische Prüfung des Eintrags beantwortet, ob sich eine Richtlinie finden und parsen lässt. Sie belegt nicht, dass die Anwendung die erwartete MAIL-FROM-Domain oder die erwartete ausgehende IP verwendet hat. Senden Sie über jeden echten Produktivpfad eine kontrollierte Nachricht an ein Empfängerkonto, das Sie selbst verwalten, und untersuchen Sie dann die empfangenen Header. Vergleichen Sie die verbindende IP, den Envelope-Absender und den Authentication-Results-Eintrag des Empfängers mit der DNS-Auswertung. Wiederholen Sie das für jeden Provider, jede Region, jeden dedizierten oder geteilten Pool, jeden Fallback-Pfad und jede Nachrichtenklasse, die den Return-Path ändern kann. Bewahren Sie die Header in zugriffsbeschränktem Speicher auf, da Adressen und Routing-Details sensibel sein können. Widersprechen sich Provider-Dashboard und empfangene Nachricht, ist die Nachricht der stärkere Beleg für den tatsächlich genutzten Pfad – das Ergebnis eines einzelnen Empfängers sollte aber trotzdem nicht auf ein allgemeines Zustellverhalten verallgemeinert werden.

DMARC-Alignment als eigenen Schritt auswerten

SPF kann für eine Return-Path-Domain des Providers pass ergeben, während DMARC dieses Ergebnis trotzdem nicht nutzen kann. Die aktuellen DMARC-Regeln vergleichen die erfolgreich per SPF authentifizierte RFC5321.MailFrom-Domain mit der Autorendomain im sichtbaren RFC5322.From-Feld. Striktes Alignment verlangt dieselbe DNS-Domain. Relaxtes Alignment lässt Domains zu, die nach den Discovery-Regeln von DMARC auf dieselbe Organisationsdomain zurückgehen. So können bounces.example.test und example.test im relaxten Modus ausgerichtet sein, bounce.provider.test und example.test dagegen nicht. Ein DMARC-Ergebnis kann sich stattdessen auf eine ausgerichtete, verifizierte DKIM-Signatur stützen; ein nicht ausgerichtetes SPF-Ergebnis bedeutet also für sich genommen nicht, dass DMARC fehlschlägt. Melden Sie Authentifizierung und Alignment getrennt und verwenden Sie das aktuelle Verfahren zur Domain-Ermittlung statt eines fest codierten Vergleichs der letzten beiden Labels.

Provider-spezifische MAIL-FROM-Konfiguration testen

Die Provider-Einrichtung bestimmt, welche SPF-Identität tatsächlich übertragen wird. Amazon SES beispielsweise dokumentiert eine benutzerdefinierte MAIL-FROM-Domain, die einen eigenen MX-Eintrag und einen eigenen SPF-TXT-Eintrag benötigt. Ist der MX der benutzerdefinierten Domain falsch konfiguriert, kann SES je nach eingestelltem Verhalten auf eine regionsabhängige MAIL-FROM-Domain unter amazonses.com zurückfallen oder den Versand ablehnen. Dieser Fallback kann das DMARC-Alignment ändern, obwohl die sichtbare From-Adresse gleich bleibt. Erfassen Sie für jeden Provider die konfigurierte Return-Path-Domain, die erforderlichen DNS-Werte, das Fallback-Verhalten, die Versandregionen und die Zuständigkeit. Warten Sie nach einer DNS- oder Provider-Änderung, bis die relevanten zwischengespeicherten Antworten abgelaufen sind, und wiederholen Sie dann DNS-Auswertung und kontrollierte Sendungen. Kopieren Sie kein include eines Anbieters in die sichtbare From-Domain, es sei denn, das ist tatsächlich die Identität und das vollständige Absenderinventar der Domain rechtfertigt es.

Bei Änderungen ein reproduzierbares SPF-Audit nutzen

Führen Sie pro Versandpfad eine Zeile mit Verantwortlichem, Anwendung, Nachrichtenklasse, sichtbarer From-Domain, MAIL-FROM-Domain, HELO-Domain, erwarteten Quellbereichen, Provider-Abhängigkeit und dem Zeitpunkt des letzten kontrollierten Tests. Speichern Sie jede SPF-Prüfung mit dem gefundenen Eintrag, dem rekursiven Trace, der Zahl der DNS-Abfragen, dem zutreffenden Mechanismus, dem Ergebnis, der Alignment-Entscheidung und einer nicht sensiblen Test-ID. Lassen Sie während einer Migration alte und neue legitime Quellen nur für das nötige Übergangsfenster autorisiert, verifizieren Sie den neuen Pfad und entfernen Sie veraltete Autorisierungen dann bewusst. Überwachen Sie dauerhafte und vorübergehende Authentifizierungsfehler, statt nur auf Ablehnungen zu reagieren. Führen Sie das Audit erneut aus nach Provider-Wechseln, Umzügen von IP-Pools, Domain-Änderungen, DNS-Änderungen oder neuen Anwendungen. Dieser Ablauf findet sowohl zu enge Richtlinien, die legitime Pfade blockieren, als auch zu weite Richtlinien, die ungenutzte Autorisierungen beibehalten.

SendHQ nach demselben Beweismaßstab prüfen

SendHQ dokumentiert, dass ein direkter Versand eine Adresse auf einer verifizierten Workspace-Domain verwenden muss. Das verifiziert die Absenderidentität, ersetzt aber keine SPF-Auswertung. Auch für eine kontrollierte SendHQ-Nachricht sind der oben beschriebene DNS-Trace, die Prüfung empfangener Header, das SPF-Ergebnis und die DMARC-Alignment-Prüfung erforderlich.

Häufig gestellte Fragen

Quellen

• RFC 7208: Sender Policy Framework (SPF) — IETF
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — RFC-Editor
• Benutzerdefinierte MAIL-FROM-Domain in Amazon SES verwenden — Amazon Web Services
• OpenAPI-Vertrag von SendHQ — SendHQ