Wie man seinen SPF-Eintrag prüft (und worauf zu achten ist)

dig +short TXT beispiel.de

nslookup -type=TXT beispiel.de

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

Schritt 3: die DNS-Auflösungen zählen

Das ist die am häufigsten vernachlässigte Kontrolle. Jedes include, a, mx, ptr, exists und redirect kostet mindestens eine DNS-Auflösung, und die Gesamtzahl darf zehn nicht überschreiten. Darüber gibt es einen PermError, und das SPF wird nicht mehr ausgewertet. Die Falle: Die include von Dienstleistern entfalten sich jeweils in mehrere Auflösungen, sodass die „sichtbare" Zählung täuscht.

Bei einem komplexen Eintrag lässt sich diese Berechnung nicht mit dem Auge machen — man muss den Baum entfalten. Genau das macht unser kostenloser Analyzer: Er löst jedes include rekursiv auf und zeigt die reale Zählung. Liegt sie nahe an zehn oder darüber, siehe die Grenze von 10 DNS-Lookups zur Behebung.

Schritt 4: die terminale Qualifikation prüfen

Entscheidend ist, was auf das abschließende all folgt:

• -all (hardfail) — das Ziel: Was nicht gelistet ist, ist nicht die Domain.
• ~all (softfail) — ein Übergangskompromiss, akzeptabel, aber kein Ziel.
• ?all (neutral) — behauptet nichts; zu ersetzen.
• +all (pass) — Gefahr: autorisiert die ganze Welt. Sofort zu beheben.

Taucht +all auf, ist das der absolute Notfall: Die Domain erklärt sich selbst für spoofbar. Das Detail der Qualifikatoren steht in die Mechanismen -all und ~all.

Schritt 5: den doppelten Eintrag prüfen

Eine Domain darf nur einen einzigen v=spf1-Eintrag haben. Tauchen zwei auf (etwa einer vom Marketing-Team hinzugefügt und ein anderer von der IT), betrachten viele Empfänger die Konfiguration als ungültig und ignorieren beide — die Domain steht dann ohne effektives SPF da, während man sich abgedeckt glaubt. Die Korrektur besteht darin, die beiden zu einem einzigen Eintrag zu verschmelzen, indem man ihre Mechanismen kombiniert (und dabei die Grenze der zehn Auflösungen im Auge behält).

Schritt 6: die Ausrichtung bestätigen, nicht nur den Durchlauf

Hier ist die subtilste Kontrolle und die wichtigste für DMARC. Ein SPF, das technisch „besteht", nützt nichts, wenn es sich nicht mit der Domain des From: ausrichtet. Die meisten Drittanbieter verwenden ihre eigene Envelope-Domain; ihr SPF besteht dann für sie, nicht für die Absenderdomain, und DMARC berücksichtigt es nicht. Um die reale Ausrichtung zu prüfen, zählt der Blick von der Empfängerseite: Genau das enthüllen die Aggregatberichte, die Quelle für Quelle anzeigen, ob SPF sich ausgerichtet hat. Bleibt „Ausrichtung" unklar, hilft wie die drei Protokolle zusammenarbeiten.

Die schnelle Methode: ein Analyzer

All diese Prüfungen lassen sich von Hand machen, aber ein guter Analyzer macht sie in Sekunden und fehlerfrei. Die Eingabe der Domain in unseren kostenlosen Analyzer genügt: Er bestätigt die Existenz des SPF, validiert die Syntax, entfaltet den Baum und zählt die Auflösungen, zeigt die terminale Qualifikation, meldet einen etwaigen doppelten Eintrag und — gekoppelt an die Berichte — sagt, ob die Quellen sich wirklich ausrichten. Das ist die vollständige Kontrolle, nicht nur das „er existiert".

Eine End-to-End-Prüfung, in der Praxis

Rollen wir eine vollständige Prüfung auf einer fiktiven Domain aus, shop.de. Ein dig +short TXT shop.de liefert:

"v=spf1 include:_spf.google.com include:shopify.com include:sendgrid.net include:_spf.mailjet.com ~all"

Erster Reflex: ein einziges v=spf1? Ja, gut. Syntax? Korrekt. Qualifikation? ~all — akzeptabel, aber wir merken an, dass wir -all anstreben. Nun der kritische Punkt, die Zählung: Diese vier include entfalten sich. Google ≈ 4 Auflösungen, Shopify ≈ 2, SendGrid ≈ 1-2, Mailjet ≈ 2. Gesamt: um die zehn, an der Grenze. Ein fünfter Dienstleister würde in einen PermError kippen. Verdikt: Der Eintrag „funktioniert" heute, ist aber fragil, und jede neue Quelle muss über eine Subdomain laufen.

Letzter Schritt, die Ausrichtung: Ein Blick in die Aggregatberichte zeigt, dass die Shopify-Post SPF besteht, sich aber nicht ausrichtet (Shopify verwendet seine eigene Envelope-Domain). Konkrete Schlussfolgerung: Damit die Bestellbenachrichtigungen für DMARC zählen, muss man eine ausgerichtete DKIM-Signatur auf Shopify-Seite aktivieren — das SPF allein genügt nicht.

Diese Fünf-Minuten-Prüfung hat drei Dinge zutage gefördert, die ein simples „das SPF existiert" verborgen hätte: Der Eintrag streift die Grenze der zehn, seine Qualifikation ist zurückhaltend, und eine der Schlüsselquellen richtet sich nicht aus. Das ist genau der Unterschied zwischen einer Präsenz feststellen und eine Qualität beurteilen — und es ist dieser Unterschied, der entscheidet, ob die Post ankommt.

Eine Checkliste zum Griffbereithalten

Für ein gesundes SPF ist zu prüfen, dass:

• es einen einzigen v=spf1-Eintrag gibt;
• die Syntax gültig ist (kein Fehler, kein totes include);
• die Auflösungszählung bei zehn oder darunter liegt;
• die terminale Qualifikation -all ist (oder ~all in bewusstem Übergang);
• es kein +all und kein ptr gibt;
• die legitimen Quellen sich in den Berichten ausrichten.

Wenn die sechs Kästchen angehakt sind, macht das SPF seine Arbeit. Andernfalls ist genau bekannt, was zu beheben ist.

Diese Liste taugt nicht nur für den Moment, in dem etwas schiefgeht. Der eigentliche Wert einer Checkliste liegt in ihrer regelmäßigen Anwendung, bevor ein Problem sichtbar wird. Ein SPF-Eintrag ist kein statisches Objekt: Er atmet mit dem Sendepark. Jeder neue Dienstleister, den das Marketing anschließt, jede Migration, die die IT durchführt, jede Übernahme eines Werkzeugs durch eine andere Abteilung kann eine Auflösung hinzufügen, eine Quelle verschieben oder ein zweites v=spf1 entstehen lassen. Ein Eintrag, der heute alle sechs Prüfungen besteht, kann in drei Monaten an einer davon scheitern, ohne dass jemand es bemerkt — bis die Zustellraten anfangen zu bröckeln. Die Disziplin, diese Kontrolle bei jeder Änderung des Sendeparks durchzugehen, ist der Unterschied zwischen einem SPF, das dauerhaft schützt, und einem, das nur am Tag seiner Einrichtung funktionierte.

Häufige Fragen

Wie oft sollte ich mein SPF prüfen? Mindestens bei jedem Hinzufügen oder Entfernen eines Versanddienstleisters und idealerweise bei einer vierteljährlichen Überprüfung. Die Versandparks driften, und ein heute gesunder Eintrag kann morgen die Grenze der zehn überschreiten.

Mein SPF besteht in einem Tester, genügt das? Nicht unbedingt. Viele Tester bestätigen, dass die Syntax gültig ist, prüfen aber weder die reale Auflösungszählung (durch Entfalten der Kaskaden) noch die Ausrichtung mit dem From:. Genau diese beiden Punkte machen den Unterschied in der Produktion.

Warum schlägt meine Post fehl, obwohl mein SPF „existiert"? Drei häufige Ursachen: ein PermError durch Überschreiten der zehn Auflösungen, eine nicht gelistete legitime Quelle oder ein SPF-Durchlauf, der sich nicht ausrichtet (der Dienstleister signiert auf seiner Domain, nicht auf der des Absenders). Die Aggregatberichte entscheiden.

Kann ich das SPF einer anderen Domain prüfen? Ja — das SPF ist öffentlich. Das ist nützlich, um einen Anbieter zu prüfen oder die eigene Haltung mit der eines Konkurrenten zu vergleichen. Ein Analyzer akzeptiert jede Domain.

Was tun, wenn ich kein SPF habe? Eines veröffentlichen, das die echten Sendequellen auflistet und mit -all (oder ~all für die Dauer der Inventarisierung) abschließt. Das ist der erste Baustein der Authentifizierung, vor DKIM und DMARC.

Muss ich das SPF meiner Subdomains separat prüfen? Ja. Eine sendende Subdomain (news., notif.) hat ihren eigenen SPF-Eintrag, unabhängig von der Root. Wird von einer Subdomain gesendet, gilt für sie dieselbe Prüfung wie für die Hauptdomain — und sie verfügt über ihr eigenes Budget von zehn Auflösungen, was oft ein auszunutzender Vorteil ist.

Aktualisiert sich das SPF von allein, wenn ein Dienstleister seine IPs ändert? Nur wenn es als include belassen wurde: Das ist der ganze Vorteil, der Dienstleister pflegt den Eintrag mit. Sind seine IPs in ip4: fixiert (oder ist das SPF geflattet), nein — dann ist selbst nachzuziehen, und eine periodische Prüfung wird unverzichtbar.

Thomas übernimmt die Überwachung

Sein SPF einmal zu prüfen ist gut; es auf Dauer gesund zu halten ist besser. Thomas, der virtuelle CISO, kontrolliert den Eintrag fortlaufend — Syntax, Auflösungszählung, Qualifikation, Doppeleintrag — und prüft anhand der Berichte, dass die Quellen sich wirklich ausrichten. Er warnt, sobald etwas abdriftet, bevor die Post darunter leidet.

Kostenlose DMARC-Analyse einer Domain oder ein Konto erstellen für ein dauerhaft überwachtes SPF.