Was ist ein SPF Eintrag? Syntax, Grenzen und Fehlerquellen

Ein SPF Eintrag ist ein einzelner DNS-TXT-Eintrag auf Ihrer Domain. Er legt fest, welche Server E-Mails im Namen dieser Domain versenden dürfen. Der empfangende Server vergleicht die IP-Adresse des sendenden Servers mit dieser Liste und liefert ein Ergebnis wie pass, fail, softfail oder neutral. SPF prüft den Absenderpfad, nicht die Nachricht und nicht die From-Adresse, die ein Mensch im Posteingang liest. Genau diese Unterscheidung erklärt die meisten SPF-Probleme, die wir in Traces sehen.

Ein SPF Eintrag ist eine Allowlist im DNS

SPF steht für Sender Policy Framework und ist in RFC 7208 beschrieben. Der Eintrag ist ein TXT-Record an der Wurzel der Domain und beginnt mit v=spf1. Ein minimales Beispiel sieht so aus:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Lesen Sie den Eintrag von links nach rechts. Der Empfänger prüft jeden Term der Reihe nach und hört beim ersten Treffer auf. Der abschließende Term all fängt alles auf, was vorher nicht gepasst hat.

Geprüft wird nicht der From-Header. Geprüft wird die Domain aus dem SMTP-Befehl MAIL FROM, also der Envelope-Sender oder Return-Path. Ist dieser leer, etwa bei Bounces, greift der Empfänger auf den HELO-Namen zurück.

Jeder Term ist ein Mechanismus, optional mit einem Qualifier davor. Sechs Mechanismen decken fast jeden realen Eintrag ab:

• ip4: und ip6: prüfen eine feste Adresse oder einen CIDR-Bereich. Sie kosten keine Lookups.

• a prüft die A- und AAAA-Records einer Domain. Er kostet einen Lookup.

• mx prüft die Hosts aus den MX-Records der Domain. Er kostet einen Lookup plus einen pro Host.

• include: übernimmt, was der SPF-Eintrag einer anderen Domain erlaubt. Er kostet einen Lookup plus alles, was darin verschachtelt ist.

• exists: prüft, ob für einen gebildeten Namen ein A-Record existiert. Er kostet einen Lookup.

• ptr prüft den Reverse-DNS der verbindenden IP. Er kostet Lookups, und RFC 7208 rät davon ab.

Qualifier legen das Ergebnis fest, wenn ein Term greift. + steht für pass und ist der Standard, - für fail, ~ für softfail und ? für neutral. -all bedeutet also: alles ablehnen, was nicht aufgelistet ist. ~all bedeutet: annehmen, aber markieren.

Bevorzugen Sie ip4: und ip6:, wenn Sie die Adresse selbst kontrollieren. Diese Terme kosten keine Lookups und können nicht brechen, wenn sich fremde DNS-Einträge ändern.

Das Limit von 10 Lookups bricht reale Einträge

RFC 7208 begrenzt eine SPF-Auswertung auf 10 Terme, die DNS-Abfragen auslösen: include, a, mx, ptr, exists und den Modifier redirect. Verschachtelte Includes zählen mit. Darüber liefert der Empfänger permerror, und die Prüfung scheitert dauerhaft, statt auf einen Ersatz auszuweichen.

Es gibt eine zweite Grenze, die weniger Beachtung findet. Terme, die eine leere Antwort oder NXDOMAIN liefern, sind Void Lookups, und die Spezifikation verlangt, nach zwei davon abzubrechen. Ein veraltetes include:, das auf einen Anbieter zeigt, den Sie letztes Jahr abgeschafft haben, ist ein Void Lookup, den Sie trotzdem bezahlen.

So stoßen Teams an die Decke. Google Workspace braucht einen Include. Ein Transaktionsanbieter braucht einen. Eine Marketingplattform braucht einen und verschachtelt drei weitere darin. Ein Support-Desk, ein CRM und ein Abrechnungstool kommen mit vier dazu. Dann stehen Sie bei 11, ohne etwas Ungewöhnliches getan zu haben.

Der Fehler bleibt still. Mails werden weiter versendet, und manche Empfänger liefern sie trotzdem aus, aber SPF authentifiziert nichts mehr für Sie. Wenn Sie DMARC-Alignment über SPF nutzen, ist dieser Weg verloren, bis Sie den Eintrag abflachen oder Absender entfernen.

Drei Lösungen funktionieren, in dieser Reihenfolge:

1. Entfernen Sie Absender, die Sie nicht mehr nutzen. Prüfen Sie die Includes gegen die DMARC-Aggregatberichte der letzten 90 Tage.

2. Verlagern Sie Massenversand auf eine Subdomain wie mail.example.com. Sie bekommt einen eigenen SPF Eintrag und ein eigenes Budget von 10 Lookups.

3. Flachen Sie Includes in feste ip4:-Bereiche ab, aber nur mit Automatisierung. Anbieter rotieren ihre IPs, und ein von Hand abgeflachter Eintrag veraltet, ohne dass ein Alarm kommt.

Genau ein Eintrag pro Domain, und die Policy richtet sich nach Ihrer Sicht

Eine Domain darf nicht zwei SPF Einträge veröffentlichen. Findet ein Empfänger zwei TXT-Einträge, die mit v=spf1 beginnen, lautet das Ergebnis permerror, genau wie beim Lookup-Limit. Das passiert, wenn jemand einen Eintrag für ein neues Tool anlegt, während bereits einer existiert.

Die Lösung ist mechanisch. Führen Sie die Terme in einem einzigen Eintrag zusammen, mit einem v=spf1 am Anfang und einem all am Ende. Was die Dokumentation eines Anbieters verlangt, kommt als weiterer include: in den bestehenden Eintrag, nie als neuer TXT-Eintrag.

Zwei kleinere Fallen. Ein TXT-String über 255 Zeichen muss in mehrere Strings innerhalb desselben Eintrags aufgeteilt werden, was die meisten DNS-Anbieter für Sie erledigen. Und halten Sie die Antwort möglichst unter etwa 450 Byte, denn größere Antworten können von UDP auf TCP ausweichen, und manche Resolver gehen damit schlecht um.

Der all-Term ist eine Policy-Aussage, und der übliche Rat, immer -all zu setzen, lässt den entscheidenden Teil aus. Ein Hardfail ist nur sicher, wenn Sie jeden legitimen Absender kennen. Unsere Faustregel aus den Traces:

• ~all, solange Sie Absender noch inventarisieren oder Mails weiterleiten und den Weg nicht kontrollieren.

• -all, sobald DMARC-Berichte über einige Wochen zeigen, dass jede legitime Quelle besteht.

• Niemals +all, das das gesamte Internet autorisiert, und niemals ?all auf einer Produktionsdomain.

In der Praxis ist der Unterschied kleiner, als viele erwarten. Die meisten großen Empfänger behandeln SPF als ein Signal unter mehreren, und mit einer DMARC-Policy entscheidet das DMARC-Ergebnis. Trotzdem ist ein -all auf einem unvollständigen Eintrag der Weg, wie Sie Rechnungen verlieren.

SPF bricht bei Weiterleitungen, und das ist so gewollt

SPF prüft die IP, die sich mit dem empfangenden Server verbunden hat. Wird eine Nachricht weitergeleitet, über eine Mailingliste verteilt oder von einem Alias-Dienst gerelayt, ist die verbindende IP die des Weiterleiters und nicht Ihre. Der SPF-Check schlägt fehl, obwohl Sie nichts falsch gemacht haben.

Das lässt sich innerhalb von SPF nicht beheben. Deshalb gibt es DKIM neben SPF: Eine Signatur übersteht den Weg, eine IP-Liste nicht. Eine Domain, die sich allein auf SPF verlässt, sieht bei jeder weitergeleiteten Nachricht Authentifizierungsfehler.

Aus demselben Grund reicht SPF allein für weitergeleitete Mails nicht aus, um DMARC zu erfüllen. Planen Sie, dass DKIM diese Nachrichten trägt.

Bestehen heißt nicht passen: Alignment mit der From-Domain

Eine Nachricht kann SPF bestehen und trotzdem DMARC scheitern lassen. DMARC verlangt, dass die Domain, die SPF bestanden hat, also die Return-Path-Domain, zur sichtbaren From-Domain passt. Viele Sendedienste nutzen standardmäßig eigene Bounce-Domains. Dann besteht SPF für provider-mail.net und sagt nichts über example.com aus.

Prüfen Sie das in den Rohheadern. In der Zeile Authentication-Results sehen Sie smtp.mailfrom=. Steht dort nicht Ihre Domain oder eine Subdomain davon, besteht SPF, ohne Ihnen zu helfen.

Die Abhilfe ist ein eigener Return-Path auf einer Subdomain Ihrer Domain. Das unterstützen die meisten ernsthaften Absender. Postmark, Resend, Mailgun und SendGrid dokumentieren alle dieses Setup, auch wenn es nicht immer standardmäßig aktiv ist.

Posteingangsanbieter erwarten Authentifizierung von jedem Absender

Seit Februar 2024 verlangt Google von allen Absendern eine Authentifizierung mit SPF oder DKIM. Absender, die mehr als 5.000 Nachrichten pro Tag an Gmail schicken, brauchen SPF, DKIM und DMARC. Die Details stehen in den E-Mail-Absender-Richtlinien von Google. Yahoo hat zur gleichen Zeit ähnliche Regeln eingeführt.

Damit wurde SPF von einer Kür zur Voraussetzung für die Zustellung. Ein fehlender oder kaputter Eintrag zeigt sich heute als Ablehnung oder Spam-Platzierung, nicht nur als schlechterer Reputationswert.

Nach einigen Jahren Traces ist unser Eindruck: Die Regeln treffen vor allem Domains ohne jede Authentifizierung und Absender mit hohen Beschwerdequoten. Ein korrekter SPF Eintrag allein bringt Sie nicht in den Posteingang, aber ein fehlender hält Sie draußen.

So prüfen und korrigieren Sie einen SPF Eintrag in vier Schritten

Gehen Sie diese Schritte der Reihe nach durch und prüfen Sie nach jeder DNS-Änderung erneut.

1. Aktuellen Eintrag abrufen. Führen Sie dig +short TXT example.com aus und suchen Sie den Eintrag, der mit v=spf1 beginnt. Gibt es zwei, führen Sie sie zusammen.

2. Lookups zählen. Addieren Sie include, a, mx, exists, redirect und alles, was in den Includes verschachtelt ist. Liegen Sie bei 8 oder mehr, planen Sie die Bereinigung jetzt und nicht beim elften.

3. Echte Absender auflisten. Nutzen Sie DMARC-Aggregatberichte oder die Authentication-Results-Header aus Testversänden. Ergänzen Sie nur Quellen, die tatsächlich auftauchen.

4. Testmail senden und den Header lesen. Das Ergebnis sollte spf=pass lauten, mit smtp.mailfrom auf Ihrer Domain.

DNS-Änderungen brauchen Zeit, bis sie sich verbreitet haben. Die TTL Ihres aktuellen Eintrags bestimmt, wie lange alte Antworten gültig bleiben. Senken Sie sie einen Tag vor einer geplanten Änderung auf 300 Sekunden.

Ein Beispiel: Ein Produkt versendet über Google Workspace, einen Transaktionsanbieter und einen Support-Desk. Ein sauberer Eintrag sieht so aus:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Das sind drei Includes, und jeder versteckt eigene verschachtelte Lookups. Zählen Sie vor dem Veröffentlichen nach, denn die sichtbare Länge verrät nichts über das echte Budget. Ein Eintrag mit drei Includes kann schon bei 7 oder 8 Lookups liegen.

Trennen Sie dann nach Zweck. Die Post der Menschen bleibt auf der Hauptdomain. Produktbenachrichtigungen laufen über notify.example.com mit einem Eintrag, der nur den Transaktionsanbieter nennt. Der Haupteintrag bleibt kurz, die Subdomain bekommt ihr eigenes Budget von 10 Lookups, und ein Reputationsproblem in einem Strom zieht den anderen nicht mit.

Was SPF nicht leistet

SPF verhindert nicht, dass jemand Ihre From-Adresse fälscht, weil es diesen Header nie prüft. Es verschlüsselt nichts. Es sagt Ihnen nicht, warum eine Nachricht im Spam gelandet ist. Und es skaliert nicht über das Budget von 10 Lookups hinaus, ohne laufende Pflege.

Behandeln Sie SPF als einen von drei Einträgen, die Sie gemeinsam veröffentlichen: SPF für den Sendepfad, DKIM für die Integrität der Nachricht, DMARC für die Policy, die beides an Ihre From-Domain bindet. Haben Sie nur SPF und sonst nichts, ist der nächste konkrete Schritt ein DMARC-Eintrag mit p=none und zwei Wochen Lesen der Berichte.