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

„Wir haben doch ein SPF." Dieser Satz beruhigt zu Unrecht: Die bloße Existenz eines SPF-Eintrags sagt nichts über seine Qualität. Ein SPF kann existieren und dennoch die Auflösungsgrenze überschreiten, einen Syntaxfehler enthalten, die ganze Welt autorisieren oder keine deiner Quellen ausrichten. Seinen SPF zu prüfen ist also weit mehr, als zu bestätigen, dass er da ist. Dieser Leitfaden zeigt dir Schritt für Schritt, wie du deinen Eintrag findest, ihn korrekt liest und die Probleme erkennst, die stillschweigend deine Zustellbarkeit untergraben.

Schritt 1: deinen Eintrag finden

Dein SPF ist ein TXT-Eintrag, veröffentlicht an der Wurzel deiner Domain. Um ihn zu sehen, kannst du das DNS direkt abfragen. Auf der Kommandozeile:

dig +short TXT ton-domaine.fr

oder unter Windows:

nslookup -type=TXT ton-domaine.fr

Unter den zurückgegebenen TXT-Einträgen ist der SPF derjenige, der mit v=spf1 beginnt. Wenn es einen gibt, notiere ihn; wenn es zwei gibt, die mit v=spf1 beginnen, hast du bereits ein Problem (siehe weiter unten). Wenn es keinen gibt, hat deine Domain überhaupt kein SPF — das ist das Erste, was zu beheben ist.

Schritt 2: die Syntax lesen

Ein SPF-Eintrag wird von links nach rechts gelesen, Mechanismus für Mechanismus. Beispiel:

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

• v=spf1 — die Version, obligatorisch am Anfang.
• include:_spf.google.com — autorisiert die von Google gelisteten Server.
• ip4:203.0.113.0/24 — autorisiert einen fest eingetragenen Adressbereich.
• -all — die terminale Qualifikation: Alles Übrige wird abgewiesen.

Jedem Mechanismus kann ein Qualifikator vorangestellt sein (+, -, ~, ?). Prüfe, dass es keine häufigen Fehler gibt: fehlendes Leerzeichen, vergessener Doppelpunkt, ein include, das auf eine nicht existierende Domain zeigt. Ein einziger Fehler kann den ganzen Eintrag in einen Fehlerzustand kippen.

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 dein 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.

Du kannst diese Berechnung bei einem komplexen Eintrag 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 dir die reale Zählung. Wenn du nahe an oder über zehn bist, siehe die Grenze von 10 DNS-Lookups zur Behebung.

Schritt 4: die terminale Qualifikation prüfen

Sieh dir an, was auf das abschließende all folgt:

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

Wenn du +all findest, ist das der absolute Notfall: Deine 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. Wenn du zwei findest (etwa einen vom Marketing-Team hinzugefügten und einen anderen von der IT), betrachten viele Empfänger die Konfiguration als ungültig und ignorieren beide — sodass du ohne effektives SPF dastehst, während du dich abgedeckt glaubst. 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 deines From: ausrichtet. Die meisten Drittanbieter verwenden ihre eigene Envelope-Domain; ihr SPF besteht dann für sie, nicht für dich, und DMARC berücksichtigt es nicht. Um die reale Ausrichtung zu prüfen, musst du auf die Empfängerseite schauen: Genau das enthüllen deine Aggregatberichte, die Quelle für Quelle anzeigen, ob SPF sich ausgerichtet hat. Wenn dir „Ausrichtung" unklar erscheint, lies wie die drei Protokolle zusammenarbeiten.

Die schnelle Methode: ein Analyzer

Du kannst all diese Prüfungen von Hand machen, aber ein guter Analyzer macht sie in Sekunden und fehlerfrei. Gib deine Domain in unseren kostenlosen Analyzer ein: Er bestätigt die Existenz des SPF, validiert die Syntax, entfaltet den Baum und zählt die Auflösungen, zeigt dir die terminale Qualifikation, meldet einen etwaigen doppelten Eintrag und — gekoppelt an deine Berichte — sagt dir, ob deine 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, boutique.fr. Du startest dig +short TXT boutique.fr und erhältst:

"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: Du öffnest deine Aggregatberichte und stellst fest, 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 dir drei Dinge beigebracht, die ein simples „das SPF existiert" dir verborgen hätte: Du streifst die Grenze der zehn, deine Qualifikation ist zurückhaltend, und eine deiner 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 deine Post ankommt.

Eine Checkliste zum Griffbereithalten

Für ein gesundes SPF prüfe, 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;
• deine legitimen Quellen sich in den Berichten ausrichten.

Wenn die sechs Kästchen angehakt sind, macht dein SPF seine Arbeit. Andernfalls weißt du genau, was zu beheben ist.

Bewahre diese Liste nicht nur für den Moment auf, 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 deinem 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 an dem Tag funktionierte, an dem du es eingerichtet hast.

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 deinem 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 deiner). Deine 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 deine Haltung mit der eines Konkurrenten zu vergleichen. Ein Analyzer akzeptiert jede Domain.

Was tun, wenn ich kein SPF habe? Veröffentliche eines, indem du deine echten Sendequellen auflistest 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. Wenn du von einer Subdomain sendest, prüfe sie wie die Hauptdomain — und denke daran, dass sie über ihr eigenes Budget von zehn Auflösungen verfügt, was oft ein auszunutzender Vorteil ist.

Aktualisiert sich das SPF von allein, wenn ein Dienstleister seine IPs ändert? Nur wenn du es als include belassen hast: Das ist der ganze Vorteil, der Dienstleister pflegt den Eintrag für dich. Wenn du seine IPs in ip4: fixiert (oder dein SPF geflattet) hast, nein — dann musst du selbst nachziehen, und eine periodische Prüfung wird unverzichtbar.

Lass Thomas für dich überwachen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto für ein dauerhaft überwachtes SPF.