Was der SPF-Check prüft
Das Sender Policy Framework (SPF, spezifiziert in RFC 7208) legt fest, welche Server E-Mails im Namen einer Domain versenden dürfen. Dazu veröffentlicht der Domaininhaber einen TXT-Eintrag im DNS, der mit v=spf1 beginnt. Ein empfangender Mailserver vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste und bewertet die Nachricht entsprechend. Geprüft wird dabei die Domain des Envelope-Absenders (Return-Path), nicht zwingend die Adresse, die Empfänger im Feld „Von“ sehen. Die Grundlagen erklärt der Glossar-Eintrag SPF-Record.
Der SPF-Check liest die TXT-Records Ihrer Domain per DNS-over-HTTPS direkt in Ihrem Browser aus, zunächst über Cloudflare, ersatzweise über Google. Sie können eine Domain, eine vollständige URL oder eine E-Mail-Adresse eingeben; das Tool kürzt die Eingabe automatisch auf die Domain. Anschließend sucht es den Eintrag mit v=spf1, zerlegt ihn in Mechanismen und Modifier und erklärt jeden Bestandteil einzeln. Verweise per include und redirect verfolgt das Tool rekursiv, stellt sie als Include-Baum dar und zählt alle DNS-Lookups, die beim Auswerten anfallen. Das Ergebnis lässt sich über eine URL wie /tools/spf-check/?domain=beispiel.de teilen, etwa mit Ihrem IT-Dienstleister.
So lesen Sie das Ergebnis
Oben steht der gefundene Roh-Record, darunter die Ampel-Bewertung. Grün bedeutet: formal korrekt, keine bekannten Risiken. Gelb markiert Punkte, die zwar funktionieren, aber veraltet sind oder Zustellprobleme begünstigen. Rot steht für Fehler, bei denen Empfangsserver den Record als ungültig verwerfen (PermError) oder die Domain praktisch ungeschützt ist.
Jeder Bestandteil erscheint in der Tabelle mit seinem Qualifier. Der Qualifier steht vor dem Mechanismus und bestimmt das Ergebnis, sobald der Mechanismus auf die einliefernde IP passt:
- + (Pass): Der Server ist autorisiert. Fehlt ein Qualifier, gilt automatisch
+. - - (Fail): Der Server ist ausdrücklich nicht autorisiert.
- ~ (SoftFail): Wahrscheinlich nicht autorisiert; die Nachricht wird meist angenommen, aber kritischer bewertet.
- ? (Neutral): Die Domain trifft keine Aussage.
Die folgende Übersicht zeigt, was die einzelnen Bestandteile bedeuten und welche davon auf das Lookup-Limit angerechnet werden:
| Bestandteil | Bedeutung | Zählt als DNS-Lookup |
|---|---|---|
ip4 / ip6 | erlaubt eine einzelne IP-Adresse oder ein Netz | nein |
a | erlaubt die Adressen aus dem A- bzw. AAAA-Record | ja |
mx | erlaubt die Mailserver aus den MX-Records | ja |
include | übernimmt die Freigaben einer anderen Domain, etwa eines Mailanbieters | ja |
exists | passt, wenn ein bestimmter Hostname existiert | ja |
ptr | prüft per Reverse-DNS; laut RFC 7208 nicht mehr verwenden | ja |
all | passt immer und dient als Auffangregel am Ende | nein |
redirect= (Modifier) | übernimmt den SPF-Record einer anderen Domain, wenn kein Mechanismus passt | ja |
exp= (Modifier) | verweist auf einen Erklärungstext für abgelehnte Nachrichten | nein |
RFC 7208 begrenzt die Zahl dieser Lookups auf 10 pro Prüfung, verschachtelte Includes eingeschlossen. Der Zähler im Tool zeigt bei mehr als 10 Lookups einen Fehler, bei 9 oder 10 eine Warnung: Ergänzt ein eingebundener Anbieter seinen eigenen Record um einen weiteren Verweis, kippt die Prüfung ohne Ihr Zutun in den PermError. Im Include-Baum sehen Sie, welcher Zweig wie viele Abfragen verbraucht.
Typische SPF-Fehler und ihre Lösung
Kein SPF-Record vorhanden
Ohne Eintrag kann jeder Server Mails mit Ihrer Domain als Absender verschicken, und Empfänger haben keine Grundlage für eine Bewertung. Ein minimaler Record für eine Domain, die über Google Workspace versendet, sieht so aus:
beispiel.de. TXT "v=spf1 include:_spf.google.com ~all"Mehrere SPF-Records
Pro Domain darf es genau einen TXT-Eintrag mit v=spf1 geben. Existieren zwei, ist das Ergebnis ein PermError, und SPF gilt als nicht bestanden. Das passiert häufig, wenn ein neuer Dienst eingerichtet und dessen Vorgabe als zusätzlicher Eintrag angelegt wird:
beispiel.de. TXT "v=spf1 include:_spf.google.com ~all"
beispiel.de. TXT "v=spf1 include:spf.protection.outlook.com ~all"Die Lösung ist ein zusammengeführter Eintrag mit einem einzigen Abschluss:
beispiel.de. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"+all, ?all oder fehlender Abschluss
+all erlaubt jedem Server im Internet, für Ihre Domain zu senden, und hebt den Schutz vollständig auf. ?all ist formal gültig, liefert aber keine verwertbare Aussage. Fehlen all und redirect ganz, endet die Prüfung bei nicht passender IP laut RFC ebenfalls mit Neutral. Schließen Sie den Record daher mit ~all oder -all ab.
Mehr als 10 DNS-Lookups
Das betrifft vor allem Unternehmen, die über viele Dienste versenden: Mailserver, CRM, Newsletter-Tool, Ticketsystem und Outreach-Software. Entfernen Sie zuerst Includes von Diensten, die nicht mehr im Einsatz sind. Ersetzen Sie a und mx durch feste ip4-Angaben, wenn sich die Adressen selten ändern. Häufig ist es sinnvoller, einzelne Versandströme auf Subdomains mit eigenem SPF-Record auszulagern, etwa news.beispiel.de. Vorsicht bei „SPF-Flattening“, also dem Ersetzen von Includes durch IP-Listen: Ändert ein Anbieter seine Adressen, ist Ihr Record veraltet, solange er nicht automatisch nachgeführt wird.
include auf eine Domain ohne SPF
Verweist ein include auf eine Domain, die keinen SPF-Record besitzt, endet die Prüfung mit PermError. Ursache sind meist Tippfehler oder Hostnamen, die ein Anbieter inzwischen geändert hat. Gleichen Sie den Wert mit der aktuellen Dokumentation des Dienstes ab.
ptr-Mechanismus
ptr ist langsam, unzuverlässig und laut RFC 7208 nicht mehr zu veröffentlichen. Ersetzen Sie ihn durch ip4- oder ip6-Angaben.
~all oder -all: Was ist die richtige Wahl?
Beide Varianten sind gültig. -all ist die strikte Aussage, dass alle nicht gelisteten Server unzulässig sind. ~all signalisiert dasselbe in abgeschwächter Form und ist weit verbreitet. Sobald eine DMARC-Policy veröffentlicht ist, verlieren die Unterschiede an Gewicht, denn DMARC wertet SoftFail und Fail gleichermaßen als „nicht bestanden“ und steuert die Behandlung über die eigene Policy. Einige Empfangsserver lehnen bei -all allerdings bereits im SMTP-Dialog ab, bevor DKIM und DMARC ausgewertet werden, was etwa weitergeleitete Mails treffen kann. Deshalb kombinieren viele Administratoren ~all mit einer DMARC-Policy. Für Domains, die überhaupt keine Mails versenden, ist v=spf1 -all dagegen die klare Empfehlung.
SPF im B2B-Outreach: Warum saubere Authentifizierung zählt
Wer im Rahmen der Kaltakquise und Outbound-Akquise E-Mails verschickt, startet meist mit eigenen Versanddomains, die noch keine Historie haben. Empfangsserver bewerten solche Absender besonders kritisch. Google und Yahoo verlangen seit Februar 2024 von allen Absendern mindestens SPF oder DKIM. Bulk-Sender, bei Google ab 5.000 Mails pro Tag an Gmail-Adressen, brauchen SPF, DKIM und DMARC.
SPF allein reicht dabei nicht aus. Es prüft nur den Envelope-Absender, nicht die sichtbare Absenderadresse. Erst DMARC verknüpft beides: Die Nachricht besteht nur, wenn SPF oder DKIM erfolgreich ist und die geprüfte Domain zur Absenderadresse passt (Alignment). Viele Versandtools nutzen eine eigene Return-Path-Domain; SPF ist dann zwar bestanden, zählt aber nicht für Ihre Domain. In diesem Fall entscheidet eine DKIM-Signatur mit Ihrer eigenen Domain.
Für Outreach-Domains gilt deshalb: genau ein SPF-Record pro Domain, nur die Dienste, die tatsächlich senden, und ein Blick auf das Lookup-Budget, bevor Sie ein weiteres Tool anbinden. Saubere Authentifizierung ersetzt kein E-Mail-Warmup, ist aber die Voraussetzung dafür, dass sich überhaupt eine positive Sender-Reputation aufbauen kann.
Nächste Schritte
- Prüfen Sie mit dem DKIM-Check, ob Ihre Mails mit einem gültigen Schlüssel der eigenen Domain signiert werden.
- Kontrollieren Sie mit dem DMARC-Check, ob eine DMARC-Policy veröffentlicht ist und wie Reporting und Alignment eingestellt sind.
- Klären Sie mit dem Blacklist-Check, ob Ihr Mailserver oder Ihre Domain auf einer gängigen DNS-Blacklist geführt wird.
Häufige Fragen
Wie prüfe ich meinen SPF-Record?
Geben Sie Ihre Domain in den SPF-Check ein. Das Tool fragt die TXT-Records im DNS ab, zeigt den Eintrag mit v=spf1 und bewertet ihn per Ampel. Alternativ liefert die Kommandozeile mit nslookup -type=TXT beispiel.de oder dig TXT beispiel.de den Rohwert. Wie viele DNS-Lookups die verschachtelten Includes tatsächlich verursachen, verrät der Rohwert allein allerdings nicht.
Was bedeutet ~all im SPF-Record?
Der Abschluss ~all steht für SoftFail: Alle Server, die vorher im Record nicht autorisiert wurden, sind wahrscheinlich nicht berechtigt. Empfangsserver nehmen solche Mails meist trotzdem an, stufen sie aber kritischer ein oder sortieren sie in den Spam-Ordner. Zusammen mit einer DMARC-Policy ist ~all eine gängige und gültige Wahl, die strengere Variante lautet -all.
Was passiert bei mehr als 10 DNS-Lookups im SPF-Record?
Laut RFC 7208 endet die Prüfung dann mit PermError. Empfangsserver behandeln den Record in diesem Fall als ungültig, und für DMARC gilt SPF als nicht bestanden. Abhilfe schaffen das Entfernen ungenutzter Includes, feste ip4- oder ip6-Angaben statt a und mx sowie das Auslagern einzelner Versanddienste auf Subdomains mit eigenem SPF-Record.
Kann eine Domain zwei SPF-Records haben?
Nein. Pro Domain ist nur ein TXT-Eintrag erlaubt, der mit v=spf1 beginnt. Bei zwei oder mehr Einträgen bricht die Prüfung mit PermError ab. Nutzen Sie mehrere Dienste, etwa Microsoft 365 und ein Newsletter-Tool, fassen Sie deren include-Angaben in einem einzigen Record zusammen und setzen Sie den Abschluss nur einmal ans Ende. Subdomains dürfen dagegen eigene SPF-Records besitzen.
Wie lange dauert es, bis ein geänderter SPF-Record wirkt?
Das hängt von der TTL des DNS-Eintrags ab, die Ihr DNS-Anbieter vorgibt. Resolver halten den alten Wert bis zum Ablauf dieser Zeit im Cache, das können wenige Minuten oder mehrere Stunden sein. Da der SPF-Check über öffentliche Resolver abfragt, kann auch dort kurzzeitig noch der alte Stand erscheinen. Prüfen Sie im Zweifel nach Ablauf der TTL erneut.
