SPF-Record-Syntax: Mechanismen, Qualifizierer und Limits

Ein SPF-Record ist ein einzelner DNS-TXT-Eintrag auf der Wurzel Ihrer Domain, der mit v=spf1 beginnt, die zum Versand in Ihrem Namen berechtigten Mailserver auflistet und mit einem all-Mechanismus endet, der empfangenden Servern sagt, was mit allem übrigen geschehen soll. v=spf1 include:_spf.google.com ~all ist ein vollständiger, gültiger Record. Alles Weitere in der SPF-Syntax sind Variationen dieser drei Bestandteile - plus eine Reihe harter Limits, die Records still zerstören, obwohl diese korrekt aussehen.

Diese Limits wiegen schwerer, als die meisten erwarten. Bei einem Scan von 5.499.028 Domains aus der Tranco-Liste am 27. Februar 2026 stellte DMARCguard fest, dass 56,0 % einen SPF-Record veröffentlichen - mehr als DMARC (30,4 %) und DKIM (22,7 %) - dass aber 4,8 % dieser SPF-Records, also 148.655 Domains, die in RFC 7208 festgelegte Obergrenze von zehn DNS-Abfragen überschreiten und damit bei der Auswertung komplett scheitern.

Die drei Bestandteile jedes SPF-Records

Jeder gültige Record ist gleich aufgebaut:

v=spf1  ip4:203.0.113.10  include:_spf.google.com  -all
  |            |                    |               |
Version    Mechanismus         Mechanismus      Auffangregel

1. Das Versions-Tag. v=spf1 muss der erste Term sein und exakt übereinstimmen. Alles andere bedeutet, dass der Eintrag gar kein SPF-Record ist.
2. Die Mechanismen. Sie werden strikt von links nach rechts ausgewertet. Der erste Mechanismus, der auf die verbindende IP passt, entscheidet das Ergebnis, und die Auswertung bricht sofort ab - die Reihenfolge ist keine Kosmetik.
3. Die Auffangregel. Ein all-Mechanismus als letzter Term. Alles, was nach all veröffentlicht wird, wird ignoriert.

Ein Punkt, bei dem Präzision lohnt: SPF prüft den Envelope-Absender aus dem SMTP-Befehl MAIL FROM (den Return-Path) sowie die HELO-Identität. Es prüft nicht den From:-Header, den Ihr Empfänger tatsächlich sieht. Diese Lücke zu schließen ist Aufgabe von DMARC, weshalb beide immer gemeinsam ausgerollt werden. Wenn Sie das Gesamtbild noch sortieren, erklärt unser Leitfaden zur DNS-Sicherheitskonfiguration, wie SPF, DKIM, DMARC und DNSSEC zusammenspielen.

SPF hatte einmal einen eigenen DNS-Ressourcentyp (Typ 99). RFC 7208 §3.1 hat ihn im April 2014 ausgemustert - veröffentlichen Sie SPF ausschließlich als TXT-Record.

SPF-Mechanismen: die vollständige Referenz

Eine Feinheit, über die viele stolpern: include: ist kein Text-Einfügen. Es führt eine vollständige, eigenständige SPF-Auswertung gegen die eingebundene Domain durch und trifft nur zu, wenn diese Auswertung pass zurückgibt. Ein -all innerhalb eines eingebundenen Records weist Ihre Mail also nicht ab - es sorgt lediglich dafür, dass der include: nicht zutrifft, und die Auswertung geht zu Ihrem nächsten Mechanismus weiter.

Qualifizierer: vier Zeichen, die das Urteil bestimmen

Jeder Mechanismus kann ein Qualifizierer-Präfix tragen. RFC 7208 §4.6.2 definiert genau vier, Standardwert ist +.

Veröffentlichen Sie niemals +all. Das erlaubt dem gesamten Internet, in Ihrem Namen zu senden, und ist strikt schlechter als gar kein SPF-Record.

Modifizierer: redirect und exp

Modifizierer sind Name-Wert-Paare statt Mechanismen und dürfen jeweils nur einmal vorkommen.

• redirect=example.com ersetzt das Ergebnis Ihres Records vollständig durch das SPF-Ergebnis der Zieldomain. Es kostet eine DNS-Abfrage und wird komplett ignoriert, wenn ein all-Mechanismus vorhanden ist - beide sollten daher nicht zusammen auftreten.
• exp=explain.example.com verweist auf einen TXT-Record mit einem lesbaren Erklärungstext, der bei einem Fail zurückgegeben wird. Er kostet zur Auswertungszeit keine Abfrage.

Die Limits, die ansonsten gültige Records zerstören

Hier stecken die meisten realen SPF-Fehler. Alles Folgende stammt direkt aus RFC 7208 §3.4 und §4.6.4:

• Zehn DNS-abfragende Terme. Die Mechanismen include, a, mx, ptr und exists sowie der Modifizierer redirect verbrauchen je einen. Mehr als zehn MUSS permerror ergeben - ein harter Fehler, keine Warnung. all, ip4, ip6 und exp sind kostenlos.
• Zwei Leerabfragen. Eine Abfrage, die NXDOMAIN oder eine leere Antwort liefert, heißt "void lookup". Implementierungen sollten diese auf zwei begrenzen; ein Überschreiten ergibt ebenfalls permerror. Vergessene include:-Einträge für abgeschaltete Dienste sind der übliche Verursacher.
• Zehn Adress-Records pro mx oder ptr. Zusätzlich zum Gesamtbudget ist jeder einzelne MX-Host auf zehn A/AAAA-Records begrenzt.
• Nur ein Record pro Domain. Liefert eine Abfrage mehr als einen v=spf1-Record, lautet das Ergebnis permerror. Führen Sie sie zu einem Record zusammen; veröffentlichen Sie nie zwei.
• 255 Zeichen pro String, insgesamt 450 Oktette empfohlen. Ein TXT-Record kann mehrere Strings enthalten, die ohne Leerzeichen zusammengefügt werden. RFC 7208 §3.4 empfiehlt, die gesamte DNS-Antwort unter 450 Oktetten zu halten, damit sie in ein UDP-Paket passt.
• Ein Zeitbudget von zwanzig Sekunden. Empfänger sollten mindestens 20 Sekunden zulassen und danach temperror zurückgeben.

Wohin Ihre zehn Abfragen tatsächlich fließen

Jeder zusätzliche Drittanbieter kostet mindestens eine Abfrage, manche mehr, weil ihre eigenen Records weitere Includes verschachteln.

Sechs oder sieben Dienste, und Sie sind an der Grenze. Die Gegenmaßnahmen, nach Priorität: Includes für abgeschaltete Dienste entfernen, Absender auf eigene Subdomains mit eigenen SPF-Records verlagern, und erst danach erwägen, Includes zu buchstäblichen ip4:-Bereichen zu flatten - Flattening beseitigt Abfragen, verlagert aber die Pflege der Anbieter-IP-Änderungen zu Ihnen.

Anteil der Domains mit veröffentlichtem SPF-Record, nach Top-Level-Domain. Quelle: DMARCguard, "State of Email Authentication 2026", Scan von 5.499.028 Tranco-Domains, 27. Februar 2026.

Fünf Syntaxfehler, die PermError auslösen

1. Zwei v=spf1-Records auf demselben Namen. Häufig nach einer Migration. Zusammenführen, nicht stapeln.
2. Ein Qualifizierer an all, der der Absicht widerspricht - ?all wirkt vorsichtig, sagt Empfängern aber nichts, sodass gefälschte Mails ungehindert durchgehen.
3. Terme nach all. Alles rechts von all ist toter Text.
4. Übrig gebliebenes ptr. Seit 2014 abgeraten, langsam, und es verbrennt eine Abfrage ohne Gegenwert.
5. Includes für abgeschaltete Anbieter. Sie kosten je eine Abfrage und können zu Leerabfragen werden, sobald der Anbieter seinen Record entfernt.

So prüfen Sie Ihren eigenen Record

Lesen Sie Ihren Record mit einer einzigen Abfrage direkt aus dem DNS:

dig +short TXT example.com

Unter Windows lautet das Äquivalent nslookup -type=TXT example.com. Suchen Sie nach genau einem String, der mit v=spf1 beginnt, und zählen Sie die abfragenden Terme von Hand - einschließlich derer, die in jedem include: versteckt sind.

Seit Februar 2024 verlangen Google und Yahoo von Massenversendern (etwa ab 5.000 Nachrichten pro Tag), sich mit SPF und DKIM zu authentifizieren und einen DMARC-Record mit mindestens p=none zu veröffentlichen. Ein permerror aus einem defekten SPF-Record gefährdet diese Konformität, es lohnt sich also zu prüfen statt anzunehmen.

Führen Sie einen kostenlosen 60-Sekunden-Scan von FortifyNet durch - wir prüfen Ihren SPF-Record zusammen mit DKIM, DMARC, Ihrer TLS-Konfiguration, den Security-Headern und der Dark-Web-Exposition, ganz ohne Registrierung.

Häufige Fragen

Kann eine Domain zwei SPF-Records haben? Nein. Liefert eine Abfrage mehr als einen v=spf1-Record, verlangt RFC 7208 §4.5 vom Empfänger ein permerror, womit SPF vollständig scheitert. Kombinieren Sie die Mechanismen in einem Record.

Sollte ich -all oder ~all verwenden? Beginnen Sie mit ~all, während Sie bestätigen, dass alle legitimen Absender gelistet sind, und wechseln Sie dann zu -all. -all ist das stärkere Signal gegen Spoofing, aber erst, wenn Ihre Absenderinventur wirklich vollständig ist.

Zählen ip4:-Einträge gegen das Limit von zehn Abfragen? Nein. ip4:, ip6:, all und exp lösen zur Auswertungszeit keine DNS-Abfragen aus und sind ausgenommen. Nur include, a, mx, ptr, exists und redirect zählen.

Verhindert SPF allein Spoofing? Nein. SPF validiert den Envelope-Absender, nicht den From:-Header, den ein Empfänger liest. Ein Angreifer kann SPF auf einer eigenen Domain bestehen und dabei Ihre anzeigen. DMARC verknüpft beide Identitäten - und genau das schließt die Lücke.

Wie lang darf ein SPF-Record sein? Jeder einzelne String eines TXT-Records ist auf 255 Zeichen begrenzt, mehrere Strings werden aber zusammengefügt. RFC 7208 empfiehlt, die gesamte DNS-Antwort unter 450 Oktetten zu halten, damit sie im UDP-Paket überlebt.

Verwandte Leitfäden

• SPF-Record-Checker: SPF-Eintrag testen, lesen und reparieren
• DMARC einrichten Schritt für Schritt
• Was ist DKIM? DomainKeys Identified Mail erklärt

---

Quellen: RFC 7208, Sender Policy Framework (SPF) Version 1, IETF, April 2014 (§3.1, §3.4, §4.5, §4.6.2, §4.6.4, §5.5, §6.1, §6.2) · DMARCguard, "State of Email Authentication 2026", Scan von 5.499.028 Tranco-Domains, 27. Februar 2026 · Anforderungen von Google und Yahoo an Massenversender, gültig seit Februar 2024.