SPF-Eintrag: die komplette Referenz

Die Syntax eines SPF-Eintrags

Ein SPF-Eintrag ist eine Folge von Mechanismen, jeweils optional mit vorangestelltem Qualifikator, gegebenenfalls ergänzt um Modifikatoren. Ein repräsentatives Beispiel für ein Unternehmen, das über eine Office-Suite und einen eigenen Anwendungsserver versendet:

beispiel.de.  IN TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

Die Mechanismen

Mechanismus	Aufgabe	Kosten in DNS-Lookups
ip4:	Autorisiert eine IPv4-Adresse oder einen CIDR-Block (ip4:203.0.113.0/24)	0
ip6:	Autorisiert eine IPv6-Adresse oder einen CIDR-Block	0
a	Autorisiert die IPs der A/AAAA-Einträge der Domain (oder einer anderen: a:mail.beispiel.de)	1
mx	Autorisiert die IPs der Empfangsserver (MX-Einträge) der Domain	1 (+ Auflösung jedes MX-Namens)
include:	Importiert die SPF-Richtlinie einer anderen Domain — der Delegationsmechanismus für Anbieter	1 + die Lookups der eingebundenen Domain
exists:	Trifft zu, wenn der (meist per Makros) konstruierte Name zu einem A-Eintrag auflöst — fortgeschrittene Nutzung	1
all	Trifft immer zu; an letzter Stelle entscheidet er über alles, was oben nicht aufgeführt ist	0

Ein achter Mechanismus, ptr, existiert im Standard, wird dort aber ausdrücklich abgeraten: teuer und unzuverlässig, er sollte in keinem aktuellen Eintrag mehr auftauchen.

Die Qualifikatoren

Jedem Mechanismus kann ein Qualifikator vorangestellt werden, der das Ergebnis bei einem Treffer bestimmt:

Qualifikator	Ergebnis bei Treffer	Typische Verwendung
+ (Standard)	pass	Implizit: include: zu schreiben entspricht +include:
-	fail	-all: jeder nicht gelistete Absender wird abgelehnt
~	softfail	~all: verdächtig, angenommen, aber markiert
?	neutral	Keine Aussage — selten gerechtfertigt

In der Praxis sieht man den Qualifikator fast nur bei all, wo seine Wahl die gesamte Richtlinie festlegt — wir kommen bei den Best Practices darauf zurück.

Die Modifikatoren

Modifikator	Aufgabe
redirect=	Ersetzt die Auswertung vollständig durch die der angegebenen Domain (zählt als 1 Lookup). Nützlich, um die Richtlinie mehrerer Domains an einer Stelle zu zentralisieren.
exp=	Verweist auf einen TXT-Eintrag, dessen Text bei einem Fehlschlag als Erklärungsnachricht dient. Nur wenige Empfänger zeigen ihn tatsächlich an.

redirect= unterscheidet sich von include: in einem wesentlichen Punkt: include: importiert eine Richtlinie zusätzlich zum Rest des Eintrags, während redirect= ihn vollständig ersetzt (er greift außerdem nur, wenn kein Mechanismus getroffen hat, und macht ein lokales all überflüssig).

Ein letztes, oft übersehenes Syntaxdetail: Eine TXT-Zeichenkette ist auf 255 Zeichen begrenzt. Ein längerer Eintrag muss in mehrere Zeichenketten innerhalb desselben TXT-Eintrags aufgeteilt werden — Empfänger verketten sie. Verboten ist dagegen, zwei getrennte SPF-Einträge zu veröffentlichen, wie wir noch sehen werden.

Das Limit von 10 DNS-Lookups und seine Auswege

Die RFC 7208 setzt eine harte Grenze: Die Auswertung eines SPF-Eintrags darf nicht mehr als 10 DNS-Auflösungen auslösen. In dieses Budget zählen die Mechanismen include:, a, mx, ptr und exists: sowie der Modifikator redirect= — und die Zählung ist rekursiv: Ein include:, das drei weitere enthält, verbraucht allein vier Lookups. Die Mechanismen ip4:, ip6: und all kosten nichts. Der Standard begrenzt außerdem die Leer-Lookups (Abfragen ohne Ergebnis) auf 2 — eine weniger bekannte zweite Obergrenze mit denselben Symptomen.

Jenseits des Limits liefert der Empfänger einen permerror: Der Eintrag gilt als ungültig, und SPF scheitert vollständig, als existierte es nicht. Die Gefahr liegt darin, dass der Ausfall lautlos und verzögert eintritt: Der Eintrag funktioniert monatelang unterhalb der Grenze, dann überschreitet sie ein weiterer Anbieter, und legitime Post beginnt zu scheitern, ohne dass irgendjemand eine Fehlermeldung erhält. Unser Leitfaden zum SPF-Lookup-Limit erläutert die genauen Zählregeln und die Diagnose Schritt für Schritt.

Die Auswege, in der Reihenfolge der Präferenz:

1. Inventur machen und ausdünnen. Die meisten aufgeblähten Einträge enthalten include:-Einträge von Anbietern, die seit Jahren nicht mehr genutzt werden. Jeder Mechanismus sollte einem realen, aktuellen Versender entsprechen.
2. ip4:/ip6: für Server mit stabilen IPs bevorzugen. Ein hauseigener Anwendungsserver braucht kein include:: Sein direkt veröffentlichter Adressblock kostet null Lookups.
3. Nach Subdomains segmentieren. Marketing-Mails von news.beispiel.de und Rechnungen von billing.beispiel.de zu versenden gibt jeder Subdomain einen eigenen Eintrag — also ein eigenes Budget von 10 Lookups — und trennt zugleich die Reputationen.
4. Flattening als letztes Mittel. Beim Flattening werden include:-Einträge durch die IP-Blöcke ersetzt, zu denen sie auflösen. Der Gewinn ist sofort da, aber das Risiko ist real: Anbieter ändern ihre IP-Bereiche ohne Vorwarnung, und ein ungepflegter geglätteter Eintrag lehnt irgendwann legitime Post ab. Die Technik, ihre automatisierten Varianten und ihre Fallstricke behandelt unser Leitfaden zum SPF-Flattening.

Ein noch fortgeschrittenerer Weg — der Mechanismus exists: kombiniert mit Makros — validiert eine IP mit einem einzigen Lookup; er ist mächtig, aber komplex und lohnt sich vor allem in sehr großen Versandinfrastrukturen.

Die SPF-Ergebnisse: pass, fail, softfail und die anderen

Die SPF-Auswertung liefert eines der folgenden Ergebnisse, das der Empfänger in der Kopfzeile Received-SPF (oder Authentication-Results) der Nachricht vermerkt:

Ergebnis	Bedeutung	Übliche Behandlung
pass	Die sendende IP ist durch den Eintrag autorisiert	Die Nachricht läuft weiter; SPF ist für DMARC nutzbar
fail	Die IP ist nicht autorisiert, die Richtlinie ist strikt (-)	Ablehnung oder starke Filterstrafe
softfail	Die IP ist nicht autorisiert, nachsichtige Richtlinie (~)	Angenommen, aber markiert; belastet den Spam-Score
neutral	Die Domain äußert keine Meinung (?)	Behandelt etwa wie das Fehlen von SPF
temperror	Vorübergehender DNS-Fehler (Timeout, Server nicht erreichbar)	Späterer Neuversuch, meist folgenlos
permerror	Ungültiger Eintrag: Syntax, Duplikat, Lookup-Überschreitung	SPF unbrauchbar — oft schlimmer als gar keins

Ein siebter Fall, none, bedeutet schlicht, dass für die Domain kein SPF-Eintrag gefunden wurde.

Zwei dieser Ergebnisse verdienen besondere Wachsamkeit. softfail bleibt oft unbegrenzt stehen, obwohl es nur als Übergangsphase gedacht war — es schwächt die Haltung, ohne dass irgendetwas das erfordert. Und permerror ist das heimtückischste: Es stammt nie von einem Angreifer, sondern immer von einem Konfigurationsfehler auf Seiten der Domain — doppelter Eintrag, Syntaxfehler, Lookup-Überschreitung. Unser eigener Artikel zum SPF-Permerror katalogisiert die realen Ursachen und ihre Behebung, Fall für Fall.

SPF allein reicht nicht: das DMARC-Alignment

Zurück zur eingangs getroffenen Unterscheidung: SPF validiert die Umschlag-Domain, nie das sichtbare From:. Ein Angreifer kann also für seine eigene Domain einen tadellosen SPF-Eintrag veröffentlichen, von seinen ordnungsgemäß autorisierten Servern senden — SPF zeigt pass — und Ihre Domain in das From: schreiben, das sein Opfer lesen wird. SPF bemerkt nichts: Es hat diese Adresse nie angesehen.

Es ist DMARC, das diese Lücke schließt, indem es das Alignment verlangt: Damit SPF in den Augen von DMARC zählt, muss die validierte Umschlag-Domain zur Domain des sichtbaren From: passen. Im Modus relaxed (dem Standard) genügt eine Übereinstimmung auf Ebene der Organisationsdomain — bounces.beispiel.de aligniert mit beispiel.de; im Modus strict (aspf=s) muss die Übereinstimmung exakt sein. Die vollständige Funktionsweise von Richtlinien und Berichten behandelt unsere DMARC-Referenzseite.

Diese Abhängigkeit legt die Achillesferse von SPF offen: die Weiterleitung. Wenn ein zwischengeschalteter Server eine Nachricht weiterleitet — Postfach-Weiterleitung, Aliasse, Verteilerlisten —, sendet er sie von seiner eigenen IP neu aus, die selbstverständlich nicht im SPF-Eintrag der Ursprungsdomain steht: SPF scheitert. Umschreibeverfahren wie SRS (Sender Rewriting Scheme) „reparieren" SPF, indem sie die Domain des Weiterleitenden in den Umschlag einsetzen — aber diese Domain aligniert nicht mehr mit dem ursprünglichen From:, und der Fehlschlag ändert nur seine Natur.

Die Schlussfolgerung ergibt sich von selbst: SPF sollte die Authentifizierung nie allein tragen. DKIM, dessen kryptografische Signatur in der Nachricht reist und die meisten Weiterleitungen übersteht, übernimmt genau dort, wo SPF bricht — unsere DKIM-Referenzseite erläutert die Funktionsweise im Detail. Eine richtig geschützte Domain kombiniert beide und lässt DMARC verlangen, dass mindestens eines von beiden aligniert besteht.

SPF-Rezepte: Microsoft 365 und Google Workspace

Die beiden großen Versand-Suiten decken die überwiegende Mehrheit der Unternehmens-E-Mail ab; hier sind ihre kanonischen Einträge.

Microsoft 365 veröffentlicht sämtliche Versand-IPs hinter einem einzigen Include:

v=spf1 include:spf.protection.outlook.com -all

Google Workspace verfährt genauso:

v=spf1 include:_spf.google.com -all

In beiden Fällen verbraucht das Include des Anbieters allein mehrere Lookups (es zerfällt in Unter-Includes): Das Budget von 10 ist nicht halb aufgebraucht, aber auch nicht mehr unangetastet. Ein Unternehmen in Koexistenz — laufende Migration, getrennte Einheiten — kombiniert beide in einem einzigen Eintrag:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Das ist legitim und verbreitet, aber das verbleibende Lookup-Budget schrumpft entsprechend: Jeder zusätzliche Anbieter (Marketing, Rechnungsstellung, CRM, Support) muss darin noch Platz finden. Die Sonderfälle — dedizierte Subdomains, Konnektoren, hybrides Routing, die genaue Lookup-Zählung jeder Suite — behandelt unser Leitfaden SPF für Microsoft 365 und Google Workspace.

Zwei Regeln, die für alle Anbieter gelten: Fügen Sie nur das vom Anbieter offiziell dokumentierte Include hinzu (in Foren aufgeschnappte Varianten sind die Hauptquelle für Duplikate und tote Mechanismen), und fügen Sie es in den bestehenden Eintrag ein — nie als zweiten Eintrag.

Best Practices für ein dauerhaft solides SPF

Ein SPF-Eintrag pro Domain, und nur einer. Die Regel ist absolut: Existieren zwei TXT-Einträge, die mit v=spf1 beginnen, liefern die Empfänger permerror, und beide werden ignoriert. Dieses Duplikat entsteht fast immer durch einen hastig hinzugefügten Anbieter: Jemand legt eine neue Zeile an, statt die bestehende zu erweitern. Jeder neue Mechanismus wird in den einen Eintrag hineinfusioniert.

Zielen Sie auf -all, dulden Sie ~all im Übergang. Der abschließende Qualifikator ist Ihre Richtlinienerklärung: -all besagt, dass die Liste vollständig ist und alles andere abgelehnt werden soll; ~all sagt „wahrscheinlich illegitim, aber markiert durchlassen". Softfail ist ein Baustellenzustand, nützlich, solange die Inventur der Versender abgesichert wird — kein Ziel. +all wiederum autorisiert den gesamten Planeten, für Ihre Domain zu senden, und muss korrigiert werden, sobald es entdeckt wird. Die Nuancen zwischen diesen Varianten seziert SPF -all oder ~all: der Unterschied.

Decken Sie auch die Domains ab, die nichts versenden. Eine geparkte Domain schützt man mit der leeren Richtlinie v=spf1 -all: Kein Server ist autorisiert, und jede Fälschung wird sofort erkennbar.

Überwachen statt vermuten. Ein SPF-Eintrag lebt: Anbieter wechseln, Teams fügen neue hinzu, IPs ziehen um. DMARC-Aggregatberichte sind der einzige Weg zu sehen, wer tatsächlich im Namen der Domain versendet und wo SPF scheitert; eine regelmäßige Überprüfung des Eintrags in ihrem Licht verhindert die stille Erosion. Bei akutem Zweifel dauert es nur wenige Minuten, den SPF-Eintrag zu überprüfen, und unser kostenloser SPF-Check zählt die Lookups, erkennt Duplikate und benotet die gesamte Haltung der Domain in Sekunden.

Denken Sie an Zustellbarkeit, nicht nur an Sicherheit. Die großen Postfachanbieter verlangen inzwischen eine korrekte Authentifizierung, um Post in großem Volumen anzunehmen, und ein wackliges SPF wirkt sich direkt auf die Inbox-Platzierung aus. Landen Ihre legitimen Nachrichten trotz gültigem SPF im Spam, liegen die Ursachen oft anderswo — Reputation, Volumen, Engagement —, wie unsere Diagnose E-Mails im Spam trotz SPF und DKIM und unser Gmail-Zustellbarkeitsleitfaden erläutern.

FAQ

Wie lange dauert es, bis eine SPF-Änderung greift?

So lange wie die DNS-Propagation: der TTL-Wert des TXT-Eintrags, oft zwischen 5 Minuten und 24 Stunden. Server, die die alte Version im Cache haben, verwenden sie weiter, bis sie abläuft. Senken Sie vor einer heiklen Änderung (Wechsel zu -all, Entfernen eines Includes) vorübergehend die TTL, um schnell zurückrollen zu können.

Gilt SPF automatisch für Subdomains?

Nein. Anders als DMARC wird SPF nicht vererbt: Jede Subdomain, die Post versendet — oder in einer HELO-Identität auftaucht — braucht einen eigenen Eintrag. Eine Subdomain ohne SPF liefert none, was der Fälschung freie Bahn lässt. Daher der Wert, auf Subdomains, die nie etwas senden, v=spf1 -all zu veröffentlichen.

Was passiert, wenn meine Domain gar keinen SPF-Eintrag hat?

Das Ergebnis ist none: Der Empfänger hat nichts, wonach er urteilen könnte, und die meisten großen Postfachanbieter bestrafen oder verweigern heute nicht authentifizierte Massenpost. Vor allem aber kann DMARC ohne SPF oder DKIM nichts validieren: Der Schutz der Domain ist inexistent. Einen SPF-Eintrag zu veröffentlichen ist der erste Schritt, nie der letzte.

Kann ich zwei SPF-Einträge auf derselben Domain haben?

Nein — das ist der klassische Fehler. Zwei TXT-Einträge, die mit v=spf1 beginnen, erzeugen einen permerror und entwerten beide. Wenn ein Anbieter Sie bittet, „sein SPF hinzuzufügen", muss sein Mechanismus in den bestehenden Eintrag fusioniert werden, auf ein und derselben logischen Zeile.

Verschlüsselt oder signiert SPF meine E-Mails?

Auch nicht. SPF ist eine reine Autorisierungsliste für IP-Adressen: Es verschlüsselt nichts, signiert nichts und garantiert nicht die Integrität des Inhalts. Der kryptografische Nachweis, dass eine Nachricht nicht verändert wurde, gehört zu DKIM, und die Übereinstimmung mit der sichtbaren Adresse zu DMARC — die drei ergänzen sich, sie ersetzen sich nicht.

-all oder ~all: was nimmt man in der Praxis?

~all während der Inventurphase, -all im Regelbetrieb. Wenn Ihr Eintrag vollständig ist und über mehrere Wochen DMARC-Berichte ohne falschen Negativbefund bestätigt wurde, rechtfertigt nichts das Verharren im Softfail: -all macht Ihre Richtlinie durchsetzbar und nimmt Fälschern die Grauzone.