SPF (Sender Policy Framework, RFC 7208) legt per DNS fest, welche Server für eine Domain E-Mails versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain steht. Steht sie nicht drin, wird die Mail je nach Policy abgewiesen oder markiert.

Aufbau eines SPF-Records

Ein SPF-Record ist ein TXT-Record im DNS der Domain. Ein typisches Beispiel:

kernel-error.de.  IN  TXT  "v=spf1 ip4:148.251.30.205 ip6:2a01:4f8:262:4716::25 mx -all"

Wichtig: Der alte DNS-Record-Typ IN SPF ist seit RFC 7208 (2014) abgeschafft. Nur IN TXT verwenden.

Mechanismen

Jeder Mechanismus definiert eine Regel, gegen die die IP des sendenden Servers geprüft wird:

ip4:148.251.30.205Diese IPv4-Adresse darf senden. Auch Netze möglich: ip4:148.251.30.0/24
ip6:2a01:4f8:...Diese IPv6-Adresse darf senden
mxAlle IP-Adressen der MX-Records der Domain dürfen senden
aDie IP-Adresse des A/AAAA-Records der Domain darf senden
a:smtp.example.deDie IP-Adresse eines bestimmten Hosts darf senden
include:example.deDie SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)
redirect=example.deGesamte SPF-Policy von einer anderen Domain übernehmen

Nicht mehr verwenden: Der ptr-Mechanismus ist seit RFC 7208 explizit nicht empfohlen. Er erzeugt unnötige Reverse-DNS-Abfragen und ist fehleranfällig.

Qualifier: Was passiert bei einem Treffer?

Vor jedem Mechanismus kann ein Qualifier stehen, der bestimmt, was mit der Mail passiert:

+ (Pass)Erlaubt (Standard, wenn kein Qualifier angegeben)
- (Fail)Nicht erlaubt — Mail soll abgewiesen werden
~ (SoftFail)Nicht erlaubt, aber nicht hart ablehnen — Mail markieren
? (Neutral)Keine Aussage — wie kein SPF

Hardfail oder Softfail?

Am Ende des SPF-Records steht der Catch-All-Mechanismus all mit einem Qualifier:

  • -all (Hardfail) — alle Server die nicht explizit gelistet sind, dürfen nicht senden. Empfänger soll ablehnen.
  • ~all (Softfail) — alle nicht gelisteten Server sind verdächtig, aber nicht definitiv verboten. Mail wird zugestellt, aber markiert.

In der Praxis: -all ist die klare Empfehlung, wenn man weiß, welche Server für die Domain senden. ~all war lange der konservative Ansatz, weil manche Empfänger SPF-Fails zu aggressiv behandelten. Seit DMARC den Umgang mit SPF-Ergebnissen standardisiert hat, ist das kein Argument mehr. Wer DMARC einsetzt, sollte -all verwenden.

Das 10-Lookup-Limit

RFC 7208 erlaubt maximal 10 DNS-Abfragen pro SPF-Prüfung. Jeder include, mx, a und redirect zählt als Lookup. ip4 und ip6 verursachen keine Abfrage, die stehen direkt im Record.

Das wird schnell zum Problem, wenn man externe Dienstleister einbindet. Ein include:_spf.google.com zieht allein schon 3-4 weitere Lookups nach sich. Wer Office 365, Google Workspace und einen Newsletter-Dienst kombiniert, sprengt das Limit leicht. Die Fehlermeldung:

PermError SPF Permanent Error: Too many DNS lookups

Lösung: Den SPF-Record so schlank wie möglich halten. Wo möglich ip4/ip6 statt include verwenden, das verbraucht keine Lookups. Externe Dienstleister nach IP-Ranges fragen statt blind deren Include-Ketten zu übernehmen.

SPF-Record testen

# SPF-Record abfragen
dig TXT kernel-error.de +short

# Ergebnis prüfen — sollte den v=spf1 Record zeigen
# Mehrere TXT-Records sind normal (SPF, DMARC, DKIM Policy etc.)

Für einen vollständigen Check mit Lookup-Zählung eignen sich Online-Tools wie kitterman.com/spf oder mxtoolbox.com. Die zeigen auch verschachtelte Includes auf und warnen bei Überschreitung des 10-Lookup-Limits.

SPF allein reicht nicht

SPF prüft die IP-Adresse gegen den Envelope-From (die Adresse aus dem SMTP-MAIL FROM-Kommando), nicht gegen den From:-Header, den der Empfänger sieht. Ein Angreifer kann also eine Mail mit gefälschtem From:-Header senden, solange der Envelope-From eine Domain ist, die er kontrolliert. Der Empfänger sieht den gefälschten Absender, SPF sagt trotzdem „Pass“.

Genau dieses Problem löst DMARC: Es prüft, ob die Domain im From:-Header mit der SPF-Domain (Alignment) oder der DKIM-Signatur übereinstimmt. Erst SPF + DKIM + DMARC zusammen ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.