Ein SPF-Eintrag zu veröffentlichen schützt gar nichts, wenn dieser Eintrag eine Schwelle überschreitet, die kaum jemand kontrolliert. Die häufigste Ursache für einen SPF-Fehler liegt selten in seinem völligen Fehlen. Sie stammt von einem schlecht aufgebauten Eintrag, der die von der RFC 7208 festgelegte Grenze von 10 DNS-Abfragen überschreitet, ohne dass der Absender vor dem Vorfall gewarnt wird. Ein gültiger SPF-Eintrag enthält die Liste der Server, die zum Versand von E-Mails für eine Domain berechtigt sind; ab mehr als 10 zur Auswertung nötigen DNS-Abfragen liefert der empfangende Server einen PermError zurück, der die Authentifizierung für sämtliche Nachrichten der Domain ungültig macht, nicht nur für den überzähligen Absender.
Was ein SPF-Eintrag tatsächlich erlaubt
Ein SPF-Eintrag (Sender Policy Framework) ist ein DNS-Eintrag vom Typ TXT, der für eine Domain veröffentlicht wird und die IP-Adressen auflistet, die berechtigt sind, in ihrem Namen E-Mails zu versenden. Ein empfangender Server, etwa Gmail oder Outlook, fragt diesen DNS-Eintrag ab und vergleicht die verbindende IP mit dieser Liste. SPF prüft genau genommen den MAIL FROM, auch Return-Path genannt, die technische Adresse für Rückläufer und Unzustellbarkeitsmeldungen, nicht die im Feld „Von:“ des Mail-Clients angezeigte Adresse. Diese Unterscheidung lässt eine Lücke für visuelles Spoofing offen.
Die Mechanismen, aus denen der SPF-Eintrag besteht
Die SPF-Syntax beruht auf einer Reihe von Mechanismen, die aneinandergereiht festlegen, wer zum Versand berechtigt ist. ip4: und ip6: deklarieren direkt einen Adressbereich, ohne den DNS ein zweites Mal abzufragen. a und mx prüfen, ob die sendende IP mit dem A-Eintrag oder den MX-Servern der genannten Domain übereinstimmt. include: delegiert die Prüfung an den SPF-Eintrag einer anderen Domain, typischerweise die eines Versanddienstleisters (ESP, CRM, Rechnungstool). ptr führt eine umgekehrte Auflösung durch, die heute von der RFC 7208 selbst wegen ihrer Langsamkeit nicht mehr empfohlen wird. exists prüft die Existenz eines dynamisch erzeugten A-Eintrags. Der Modifikator redirect wird nicht zur Liste hinzugefügt: Er ersetzt die gesamte Auswertung durch die eines anderen Eintrags, ähnlich einer HTTP-Weiterleitung, angewandt auf den DNS. Jeder dieser Mechanismen verbraucht, mit Ausnahme von ip4 und ip6, bei der Auswertung eine eigene DNS-Abfrage. Ein include: kann selbst weitere, verschachtelte include:-Einträge enthalten, ohne dass die sichtbare Zeile dies erahnen lässt. Auch die Reihenfolge zählt: Der empfangende Server wertet die Mechanismen von links nach rechts aus und stoppt beim ersten, der mit der sendenden IP übereinstimmt. Die am häufigsten genutzten internen Server an den Anfang des Eintrags zu stellen, ändert nichts am Endergebnis. Es beschleunigt lediglich die Auswertung bei Domains mit hohem Versandvolumen.
Die Qualifier -all, ~all, ?all: Was mit einer nicht konformen E-Mail passiert
Ein SPF-Eintrag endet immer mit einem Qualifier, der das Schicksal einer von einer nicht in der Liste enthaltenen IP gesendeten E-Mail festlegt. -all (Fail strict) fordert den empfangenden Server auf, die Nachricht abzulehnen. ~all (Softfail) fordert dazu auf, sie zu akzeptieren, aber als verdächtig zu markieren, oft mit Weiterleitung in den Spam-Ordner. ?all (Neutral) gibt keine klare Vorgabe, was darauf hinausläuft, jedem Mailbox Provider die Entscheidung selbst zu überlassen. Ein letzter Qualifier, +all, erlaubt ausdrücklich jeder beliebigen IP, im Namen der Domain zu versenden; er hat nur in der Testphase Sinn, um SPF bewusst zu deaktivieren, niemals im Produktivbetrieb. Gmail und Microsoft 365 behandeln Softfail mit einer Toleranz, die jedes Jahr sinkt. Eine Domain, die vorsichtshalber noch auf ~all konfiguriert ist, wandert häufig zu -all, sobald DKIM und DMARC eingerichtet sind; ohne diesen Schritt suggeriert SPF nur Misstrauen, statt es eindeutig zu klären.
Ein SPF-Eintrag, Zeile für Zeile kommentiert
Nehmen wir ein repräsentatives Beispiel einer Domain, die sowohl von eigenen Servern als auch über einen externen ESP versendet:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx -all
v=spf1 deklariert die Protokollversion, immer identisch. ip4:203.0.113.10 autorisiert direkt den internen Mailserver des Unternehmens, ohne Lookup-Kosten. include:_spf.google.com delegiert die Berechtigung an die Server von Google Workspace, hier für die E-Mails der Mitarbeitenden genutzt. include:sendgrid.net macht dasselbe für über SendGrid versandte Kampagnen. mx fügt automatisch die MX-Server der Domain zur Liste gültiger Absender hinzu. -all schließt den Eintrag im Fail-strict-Modus ab: Jede IP, die nicht in dieser Liste steht, sieht ihre Nachricht abgelehnt. Dieser Eintrag verbraucht bereits 3 der 10 erlaubten Lookups (die beiden include: und das mx), ohne zu berücksichtigen, dass jedes include: selbst mehrere Unterabfragen auslösen kann, sobald es aufgelöst wird.
Die Grenze von 10 DNS-Lookups und der PermError
Die RFC 7208, Abschnitt 4.6.4, legt zwei unterschiedliche Obergrenzen für die Auswertung eines SPF-Eintrags fest. Die erste, bekannteste, begrenzt auf 10 die Anzahl der DNS-Abfragen, die durch die Mechanismen include, a, mx, ptr, exists und den Modifikator redirect ausgelöst werden; ip4 und ip6 kosten keine, da die Adresse bereits im Eintrag steht. Die zweite, weniger dokumentierte Obergrenze begrenzt auf 2 die Anzahl der tolerierten „Void Lookups“: eine DNS-Abfrage, die ohne Antwort zurückkommt (NXDOMAIN), meist verursacht durch ein include:, das auf eine falsch geschriebene Domain oder einen gekündigten Dienstleister verweist, dessen Eintrag gelöscht wurde (AutoSPF, März 2026). Wird eine der beiden Grenzen überschritten, ist das Ergebnis dasselbe: PermError. Der empfangende Server bricht dann die Auswertung ab und behandelt die Authentifizierung als gescheitert, für sämtliche Nachrichten der Domain, einschließlich derer, die von einer vollkommen legitimen und drei Zeilen weiter oben im Eintrag dokumentierten IP versendet wurden.
Die SPF-Flattening genannte Technik löst diese Überschreitung, indem sie jedes include: durch die reine Liste der von ihm bezeichneten IP-Adressen ersetzt. Die Auswertung kostet dann nur noch einen einzigen Lookup, unabhängig davon, wie viele Versanddienstleister ursprünglich genannt waren. Auf Zustellbarkeit spezialisierte Anbieter wie dmarcian oder PowerDMARC dokumentieren diese Technik und bieten Dienste an, die den Eintrag bei jeder IP-Änderung seitens des Dienstleisters neu berechnen. Das Verfahren hat seine eigene Obergrenze: Eine DNS-TXT-Zeichenkette ist auf 255 Zeichen pro Segment begrenzt. Ein geflatteter Eintrag, der Dutzende IP-Adressen direkt auflistet, kommt dieser Grenze manchmal gefährlich nahe, was eine Aufteilung in mehrere verkettete Zeichenketten erfordert.
Das erklärt ein klassisches Szenario im Growth-Team: Kampagnen landen im Spam, ohne dass eine Erklärung von der genutzten Emailing-SaaS-Lösung kommt, die dennoch „SPF konfiguriert“ anzeigt. Das Dashboard prüft die Existenz und Syntax des Eintrags. Es berechnet niemals die Anzahl der Lookups neu, sobald alle include:-Einträge kaskadenartig aufgelöst sind. Eine Domain, die Google Workspace, einen transaktionalen ESP, ein Marketing-Automation-Tool und ein CRM angesammelt hat, kann die Grenze überschreiten, ohne dass eine dieser Integrationen für sich genommen verdächtig erscheint.
Den eigenen SPF-Eintrag prüfen, bevor er bricht
Den eigenen SPF-Eintrag zu prüfen erfordert kein kostenpflichtiges Tool. Die direkteste Methode läuft in drei Schritten ab:
- Den DNS per Kommandozeile mit
dig txt ihredomain.comabfragen (odernslookup -type=txt ihredomain.comunter Windows), um den Eintrag so zu lesen, wie er tatsächlich veröffentlicht ist, nicht wie er im Interface des Registrars eingegeben wurde. - Diesen Eintrag durch einen Online-SPF-Prüfer laufen lassen, der jedes verschachtelte
include:auflöst und die Gesamtzahl der Lookups anzeigt, statt die Mechanismen von Hand zu zählen. - Diese Kontrolle bei jedem neu hinzugefügten Versanddienst wiederholen (ESP, Rechnungstool, Recruiting-Plattform, die Bewerber-E-Mails versendet) und nicht nur bei der ursprünglichen Einrichtung.
Auf Gmail-Seite heißt dieses Werkzeug Google Postmaster Tools, bei Microsoft übernimmt SNDS das Tracking der IP-Reputation. Beide zeigen einen Authentifizierungsverlauf an. Keines von beiden meldet eine Lookup-Überschreitung, bevor sie bei einem realen Versand einen tatsächlichen PermError verursacht.
Der doppelte Eintrag und die häufigsten Fehler
Eine Domain darf nur einen einzigen SPF-Eintrag veröffentlichen. Zwei zu haben, oft weil eine Agentur ihren eigenen hinzugefügt hat, ohne den bereits vorhandenen zu entfernen, erzeugt einen neuen PermError: Die RFC 7208 sieht keine automatische Zusammenführung zweier TXT-Einträge vom Typ SPF vor. Der andere wiederkehrende Fehler besteht darin, einen externen Versanddienstleister in der Liste zu vergessen, ein Umfragetool oder eine Recruiting-Plattform, die im Namen der Domain transaktionale E-Mails versendet, ohne jemals zum Eintrag hinzugefügt worden zu sein. Diese Nachrichten scheitern lautlos, bis ein Kunde meldet, nichts erhalten zu haben.
Die E-Mail-Weiterleitung lässt SPF scheitern: Was SRS tut (und nicht tut)
Eine weitergeleitete E-Mail bricht fast immer den SPF-Check, konstruktionsbedingt. Der Server, der die Nachricht weiterleitet, erscheint nie im SPF-Eintrag der Ursprungsdomain, die Authentifizierung scheitert also beim Endempfänger. Das Sender Rewriting Scheme (SRS) korrigiert genau diesen Fall, indem es die MAIL-FROM-Adresse der Nachricht mit der Domain des Relay-Servers umschreibt, die in ihrem eigenen SPF durchaus autorisiert ist (Microsoft-Learn-Dokumentation, September 2025). Dieser Mechanismus hat einen von Microsoft selbst dokumentierten blinden Fleck: SPF validiert dann die Domain des Relays, während das für den Empfänger sichtbare Feld „From“ weiterhin die Ursprungsdomain anzeigt.
Die Microsoft-Dokumentation stellt es klar heraus: SRS löst nicht den Fall weitergeleiteter Nachrichten, die bei DMARC scheitern, da dieses Protokoll eine Übereinstimmung zwischen der per SPF (oder DKIM) validierten Domain und der im Feld From angezeigten Domain verlangt.
Eine Nachricht kann also dank SRS den SPF-Check bestehen und trotzdem bei DMARC reject scheitern, mangels Übereinstimmung zwischen den beiden geprüften Domains.
SPF, DKIM und die DMARC-Ausrichtung: der Mechanismus, der die Reputation wirklich schützt
SPF und DKIM sagen dem empfangenden Server nicht dasselbe. SPF validiert den MAIL FROM, DKIM signiert kryptografisch die gesamte Nachricht. DMARC fügt eine Ebene hinzu, die beide Protokolle allein außer Acht lassen: die Ausrichtung (Alignment), also die Prüfung, ob die per SPF oder DKIM authentifizierte Domain tatsächlich mit der im vom Nutzer gelesenen Feld „From“ angezeigten Domain übereinstimmt. Ohne diese Ausrichtung kann eine Nachricht SPF über einen externen ESP validieren und dabei eine völlig andere Absenderdomain anzeigen, genau das Muster eines Phishing-Angriffs durch Identitätsdiebstahl. Diese dreifache Kontrolle bestimmt die Complaint Rate und den Kampf gegen Spam und Phishing sowohl bei Gmail als auch bei Outlook.
Ein sauberer SPF-Eintrag gleicht keine Liste voller toter Adressen aus: Eine an nicht existierende Adressen versendete Kampagne lässt die Hard-Bounce-Rate steigen, was die Sender Reputation schädigt, die SPF und DKIM eigentlich schützen sollen, unabhängig davon, wie sorgfältig die DNS-Konfiguration ausgeführt wurde. Die Liste vor dem Versand zu prüfen, eine grundlegende Praxis der List Hygiene, kostet weniger Reputation als das nachträgliche Filtern der Enhanced Status Codes 5.1.1, die von den Zielservern gemeldet werden, nachdem die Kampagne bereits verschickt wurde. DMARC schließt den Kreis: Ohne DMARC bleiben SPF und DKIM zwei isolierte Prüfungen, ohne garantierte Verbindung zu der Adresse, die der Empfänger wirklich sieht.
Eine korrekt authentifizierte Domain fällt nie auf: Sie erscheint in keinem Incident-Report, gerade weil niemand Anlass hat, darüber zu sprechen.
