Zuletzt geprüft: 02.11.2026

SPF (Sender Policy Framework)

Q: Wie prüfe ich meinen SPF-Eintrag?

Fragen Sie den TXT-Eintrag Ihrer Domain ab, etwa mit nslookup -type=TXT example.de, und zählen Sie: genau ein Eintrag mit v=spf1, höchstens zehn DNS-Abfragen insgesamt – einschließlich der Abfragen in eingebundenen Einträgen. Einen neuen Eintrag stellt der SPF-Baukasten zusammen; er fragt selbst kein DNS ab.

Kurz gesagt: SPF ist ein TXT-Eintrag im DNS einer Domain, in dem der Inhaber aufzählt, welche Server E-Mails mit dieser Domain im Umschlag verschicken dürfen. Der empfangende Server vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste und kommt zu einem Ergebnis wie „pass“ oder „fail“ (RFC 7208).

Wie SPF arbeitet

Bei jeder Zustellung nennt der sendende Server im SMTP-Dialog eine Rücklaufadresse, den sogenannten Envelope-From oder „MAIL FROM“ (RFC 5321). Der Empfänger nimmt¹ die Domain dieser Adresse, fragt deren SPF-Eintrag ab und prüft, ob die einliefernde IP-Adresse darin vorkommt. Geprüft wird also nicht die Absenderadresse, die Leser im Postfach sehen, sondern die Adresse im Umschlag.

RFC 7208 kennt sieben Ergebnisse: pass, fail, softfail, neutral, none, temperror und permerror (Abschnitt 2.6). Was der Empfänger mit dem Ergebnis macht, legt SPF selbst nicht fest.²

Zwei Grenzen aus dem Standard verursachen in der Praxis die meisten Fehler:

Nur ein Eintrag je Domain. Findet der Empfänger mehr als einen Eintrag, der mit v=spf1 beginnt, lautet das Ergebnis permerror (Abschnitt 4.5).
Höchstens zehn DNS-Abfragen. Die Angaben include, a, mx, ptr, exists und redirect lösen Abfragen aus; mehr als zehn führen ebenfalls zu permerror (Abschnitt 4.6.4). ip4, ip6 und all zählen nicht mit.

Abgrenzung zu DKIM und DMARC

Verfahren	was geprüft wird	wo es steht
SPF	ob der einliefernde Server für die Domain im Umschlag senden darf	TXT-Eintrag der Domain
DKIM	ob eine digitale Signatur im Kopf der E-Mail zur Domain passt und der Inhalt unverändert ist	Signatur im Kopf, Schlüssel im DNS
DMARC	ob die sichtbare Absenderdomain zu einer bestandenen SPF- oder DKIM-Prüfung passt, und was bei Fehlschlag geschehen soll	TXT-Eintrag unter `_dmarc.`

SPF allein sagt nichts über die sichtbare Absenderadresse. Erst DMARC verknüpft beides: Die Domain im Umschlag muss dafür zur Domain im „From:“ passen (RFC 9989). Gmail verlangt von allen Absendern SPF oder DKIM, von Massenversendern beides und dazu DMARC.³

Verwechslungsgefahr

Lichtschutzfaktor: Im Englischen steht SPF auch für „Sun Protection Factor“, den Lichtschutzfaktor auf Sonnenschutzmitteln. Mit E-Mail hat diese Bedeutung nichts zu tun.
~all und -all: Die Tilde ergibt softfail, eine schwache Aussage, dass der Server wahrscheinlich nicht berechtigt ist; das Minus ergibt fail. RFC 9989 weist darauf hin, dass ein -all dazu führen kann, dass eine Nachricht schon vor der DMARC-Auswertung abgelehnt wird, auch wenn sie über DKIM bestanden hätte (Abschnitt 7.1).⁴
Weiterleitungen: Leitet ein Postfach eine E-Mail weiter, liefert ein anderer Server ein. Die SPF-Prüfung kann dann scheitern, obwohl die Nachricht echt ist (RFC 7208, Anhang D).²

Quellen

RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, IETF / RFC Editor, Abschnitte 2.1, 3.2, 4.5, 4.6.2, 4.6.4, 5.5 und Beispiele in Abschnitt 3 und Anhang (Abruf rfc-editor.org/rfc/rfc7208.txt, 18.10.2026); Abschnitte 2.6, 10.1.1, 10.1.2, Anhang D (Begriffsseite SPF) (abgerufen am 02.11.2026)
RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF / RFC Editor, Abschnitt 4.7 (Tags np, sp, t, fo, ruf), 4.10 (mehrere DMARC-Einträge werden verworfen), 5.1.4–5.1.7 (Einführung: p=none mit rua, Berichte auswerten, dann über Enforcement entscheiden), 11.6 (externe Berichtsadressen), 9.3 (Registry), Anhang A.6 (Wegfall pct); Abschnitte 4.4, 4.5, 7.1, Anhang A.6 und B.2 (Begriffsseiten) (abgerufen am 02.11.2026)

Beispiel

Drei Einträge mit der Beispieldomain example.de. Die erste und die dritte Zeile folgen Beispielen aus RFC 7208 (Abschnitte 10.1.1 und 10.1.2), die mittlere zeigt die übliche Form mit einem Versanddienst:

example.de.       TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
example.de.       TXT  "v=spf1 mx include:_spf.versanddienst.example -all"
www.example.de.   TXT  "v=spf1 -all"

Die erste Zeile erlaubt genau zwei IP-Adressen und lehnt alle anderen ab; RFC 7208 führt diese Form im Vergleich mehrerer Varianten als beste („Best record“), denn sie kommt ohne weitere DNS-Abfragen aus. Die zweite erlaubt die Mailserver der Domain und alle Server, die der Versanddienst in seinem eigenen SPF-Eintrag nennt. Die dritte gehört zu einem Namen, der keine E-Mails verschickt; einen solchen Eintrag für Domains ohne Versand nennt RFC 7208 eine bewährte Praxis.

Häufige Fragen

Wie prüfe ich meinen SPF-Eintrag? Fragen Sie den TXT-Eintrag Ihrer Domain ab, etwa mit nslookup -type=TXT example.de, und zählen Sie: genau ein Eintrag mit v=spf1, höchstens zehn DNS-Abfragen insgesamt – einschließlich der Abfragen in eingebundenen Einträgen. Einen neuen Eintrag stellt der SPF-Baukasten zusammen; er fragt selbst kein DNS ab.

Reicht SPF allein? Für Gmail reicht bei kleinen Mengen SPF oder DKIM. Wer mehr als 5.000 Nachrichten am Tag an Gmail-Konten schickt, braucht laut Gmail-Hilfe SPF, DKIM und DMARC.

Was bedeutet include:? Damit übernimmt der Eintrag die erlaubten Server aus dem SPF-Eintrag einer anderen Domain, meist der des Versanddienstes. Jedes include zählt als eine Abfrage, dazu alle Abfragen im eingebundenen Eintrag (RFC 7208, Abschnitt 4.6.4).

Passendes Werkzeug

SPF-Baukasten: stellt einen Eintrag nach RFC 7208 zusammen und zählt die DNS-Abfragen.