SPF-Record: was er prüft und wie ihr ihn selbst lest

Ein SPF-Record ist ein einzelner DNS-Texteintrag eurer Domain, der auflistet, welche Mailserver in eurem Namen versenden dürfen. Empfangende Systeme wie Microsoft 365 oder Gmail schlagen bei jeder eingehenden E-Mail automatisch diesen Eintrag nach und vergleichen ihn mit dem tatsächlich sendenden Server. Stimmt er nicht überein, gilt die Mail als nicht autorisiert – unabhängig davon, wie seriös ihr Inhalt ist.

Was im DNS tatsächlich steht

Ein SPF-Record ist ein TXT-Eintrag auf eurer Domain, keine separate Datei und kein Login irgendwo. Er sieht typischerweise so aus:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all

Jedes Element hat eine feste Bedeutung:

Die Einträge werden von links nach rechts geprüft, und der erste Treffer entscheidet. all gehört deshalb immer ans Ende: Was dahinter steht, wird nie geprüft. Das Präfix vor all bestimmt, wie streng nicht gelistete Server behandelt werden.

Welche Absenderadresse SPF prüft — und welche nicht

SPF prüft den Envelope-Sender, also die Adresse, die der sendende Server im SMTP-Dialog als MAIL FROM nennt. Diese Adresse ist Teil des Transportprotokolls und wird dem Empfänger im Postfach nie angezeigt. Die Absenderadresse, die euer Kunde tatsächlich liest, steht im From-Header der Nachricht – und die kann eine völlig andere Domain tragen, ohne dass SPF das bemerkt.

Daraus folgt die praktische Grenze des Verfahrens: Ein Absender kann eine Domain im Envelope verwenden, für die er sauber autorisiert ist, und im sichtbaren From-Feld trotzdem eure Firma nennen. SPF meldet «pass». Erst DMARC verlangt, dass die geprüfte Domain zur sichtbaren passt.

Wie ihr euren SPF-TXT-Eintrag im DNS abfragt

Ihr braucht kein Spezialwerkzeug, ein einfacher DNS-Abfragebefehl genügt:

dig TXT euredomain.ch +short

Unter Windows funktioniert nslookup -type=TXT euredomain.ch ebenso. Das Ergebnis kann mehrere TXT-Einträge zeigen – gesucht ist die Zeile, die mit v=spf1 beginnt. Prüft darin jeden include:, ob der jeweilige Dienst tatsächlich noch aktiv genutzt wird, und jede ip4:-Adresse, ob der dahinterliegende Server noch existiert.

Warum die meisten SPF-Fehler erst nach dem Einrichten entstehen

Die meisten SPF-Probleme entstehen nicht beim Einrichten, sondern beim Vergessen danach:

• Verwaiste include:-Einträge. Ein Newsletter-Anbieter wird gewechselt, der alte Eintrag bleibt aber im Record stehen.
• Das 10-Lookup-Limit. SPF erlaubt maximal 10 DNS-Abfragen pro Prüfung (jedes include: zählt, teils mehrfach verschachtelt). Wird das überschritten, gilt der gesamte Record als ungültig – auch die korrekten Einträge werden dann ignoriert.
• +all statt ~all oder -all. Das erlaubt praktisch jedem Server, in eurem Namen zu senden – das Gegenteil von Schutz.
• Zwei SPF-Records gleichzeitig. Pro Domain ist nur ein SPF-TXT-Eintrag zulässig; ein zweiter macht beide ungültig.
• Ein include: auf einen Namen ohne SPF-Record. Der Name existiert, etwa als Adresse eines Mailservers, hat aber selbst keinen v=spf1-Eintrag. Das ergibt kein «passt nicht», sondern einen permerror – der ganze Record ist ungültig, und beim Versand fällt es niemandem auf.
• Die feste IP des Büroanschlusses im Record. Ein Scanner oder eine Fachanwendung verschickt direkt über den Internetanschluss statt über den Mail-Anbieter, und dessen IP-Adresse landet als Schnelllösung per ip4: im Record. Damit darf jedes Gerät an diesem Anschluss in eurem Namen senden. Sauber ist der Versand über den Mail-Anbieter; danach gehört die IP wieder hinaus.

Ein konkretes Beispiel: Ein Treuhandbüro wechselt von einem lokalen Mailserver zu Microsoft 365, vergisst aber, den alten ip4:-Eintrag zu entfernen und den neuen include:spf.protection.outlook.com zu ergänzen. Ergebnis: Ausgehende Mails über Microsoft 365 werden bei manchen Empfängern als nicht autorisiert markiert, weil der SPF-Record noch den stillgelegten Server nennt und Microsoft fehlt.

Ein SPF-Record ohne DKIM und DMARC schützt nur die technische Versandroute – nicht die sichtbare Absenderadresse, die eure Kunden tatsächlich lesen.

Was SPF prüft und was erst DKIM und DMARC abdecken

Die drei Verfahren werden oft in einem Atemzug genannt, prüfen aber verschiedene Dinge und greifen an verschiedenen Stellen der Nachricht an:

Die Zeile «Übersteht eine Weiterleitung?» erklärt, warum SPF allein nie genügt: Sobald eine Mail über eine Weiterleitung läuft, ist der ursprüngliche Absenderserver nicht mehr derjenige, den der Empfänger sieht.

Warum ~all die bessere Endung ist, sobald DMARC steht

-all klingt nach mehr Schutz, bringt zusammen mit DMARC aber kaum welchen. Manche empfangenden Server werten SPF schon im SMTP-Dialog aus, bevor die Nachricht überhaupt übertragen ist. Bei -all können sie die Mail an dieser Stelle abweisen – die DKIM-Signatur und die DMARC-Regel kommen dann gar nicht mehr zum Zug. Die DMARC-Spezifikation weist Domain-Inhaber ausdrücklich darauf hin und hält fest, dass so abgewiesene Mails in keinem DMARC-Bericht erscheinen (RFC 9989, Abschnitt 7.1).

Daraus folgt: Den Schutz gegen Fälschungen liefert die DMARC-Policy, nicht -all. Mit ~all hängt er allerdings ganz an ihr – ~all ist deshalb kein Grund, bei p=none stehen zu bleiben.

Wie ihr euren Record prüft und die 10-Lookup-Kette auszählt

Der SPF-Record ist in zwei Minuten abgefragt – die Arbeit steckt darin, die verschachtelten include:-Ketten aufzulösen und zu zählen. Diese Reihenfolge führt zum Ziel:

1. Den eigenen Record holen. dig TXT euredomain.ch +short und die Zeile mit v=spf1 herausgreifen. Kommt mehr als eine solche Zeile zurück, ist das bereits der Befund: zwei SPF-Records machen beide ungültig.
2. Jedes include: einzeln nachschlagen. Für jeden Eintrag dig TXT _spf.google.com +short (bzw. die jeweilige Domain) ausführen. Enthält das Ergebnis selbst wieder include:, geht es eine Ebene tiefer – genau hier wächst die Kette unbemerkt. Kommt für ein include: keine Zeile mit v=spf1 zurück, ist das bereits ein Befund: Der ganze Record endet in einem permerror.
3. Die Lookups zählen. Zählend sind include:, a, mx, ptr, exists und redirect. Nicht zählend sind ip4: und ip6: – sie brauchen keine Abfrage. Die Spezifikation erlaubt maximal 10 DNS-Abfragen pro Prüfung; alles darüber ergibt einen permerror. Zusätzlich sind höchstens zwei Abfragen ohne Ergebnis erlaubt (Name existiert nicht oder hat keinen Eintrag) – verwaiste Einträge abgeschalteter Dienste sind deshalb nicht harmlos.
4. Das Ergebnis an einer echten Mail gegenprüfen. Schickt eine Mail von jedem produktiven Versandweg an ein externes Postfach und seht euch im Quelltext den Header Authentication-Results an. Dort steht spf=pass, spf=fail, spf=softfail oder spf=permerror – zusammen mit der Domain, gegen die geprüft wurde.
5. Die Versandwege inventarisieren, bevor ihr etwas verschärft. Mailserver, Newsletter-Tool, CRM, Buchhaltungssoftware, Formular-Plugin der Website, Monitoring-Dienste. Was hier fehlt, fällt spätestens durch, sobald die DMARC-Policy greift.

Zwei Fallstricke, an denen es in der Praxis scheitert:

• Weiterleitungen brechen SPF – und zwar korrekt. Leitet ein Empfänger eure Mail automatisch an ein anderes Postfach weiter, verschickt sie der weiterleitende Server mit seiner IP-Adresse, während der Envelope-Sender eure Domain bleibt. Die SPF-Prüfung am Ziel schlägt fehl, obwohl niemand etwas gefälscht hat. Umgehen lässt sich das nur vom weiterleitenden Server aus (etwa mit SRS), nicht von euch. Genau deshalb darf -all nie das einzige Standbein sein: DKIM übersteht die Weiterleitung, SPF nicht.
• Das 10-Lookup-Limit wird von Dienstleistern verbraucht, nicht von euch. Ein einziges include: eines grossen Anbieters kann intern mehrere weitere include: nachziehen. Euer Record sieht kurz aus und ist trotzdem über dem Limit. Wer die Kette per «SPF-Flattening» durch feste ip4:-Listen ersetzt, umgeht das Limit – handelt sich aber ein neues Problem ein: Ändert der Anbieter seine Server-Adressen, erfährt euer eingefrorener Record nichts davon, und der Versand bricht ohne erkennbaren Anlass ab. Flattening braucht darum zwingend eine Automatik, die den Record nachführt.