SPF-Eintrag erstellen und prüfen: Schritt für Schritt

Die Zeile ist in einer Minute getippt:

v=spf1 include:_spf.beispielanbieter.de include:versand.beispiel-dienst.de ip4:198.51.100.25 ~all

Vollständig ist sie erst, wenn wirklich jeder Weg bekannt ist, über den im Namen der Domain Mails hinausgehen. Die Arbeit an einem SPF-Eintrag liegt deshalb nicht im Schreiben, sondern im Sammeln. Und wer schon einen Eintrag hat, liest ihn vor der ersten Änderung einmal so, wie ein Empfänger ihn liest: von links nach rechts, mit Zählung der DNS-Abfragen. Beides steht hier, erst das Erstellen, dann das Prüfen.

Zuerst die vollständige Liste der Versender#

Ein SPF-Eintrag ist eine Erlaubnisliste, und jede Lücke darin trifft die eigenen Mails. Zu erfassen ist alles, was einliefert: der Postfachanbieter, das Newsletter-Werkzeug, das CRM, der Shop, das Rechnungs- und das Ticketsystem, Terminbuchungen, Überwachungsmeldungen von Servern und der Formularversand der eigenen Website.

Zwei Quellen helfen beim Zusammentragen. Die erste sind die laufenden Abonnements und Rechnungen: Was bezahlt wird, versendet meistens auch. Die zweite und deutlich zuverlässigere sind die DMARC-Sammelberichte, die man mit p=none und einer rua-Adresse einige Wochen einsammelt, bevor man den Eintrag scharf stellt. Diese Berichte nennen die tatsächlichen Absender statt der erinnerten.

Jeder externe Dienst dokumentiert, was einzutragen ist. Übernommen wird der vom Anbieter genannte include-Ausdruck, niemals dessen IP-Adressen, denn die ändern sich ohne Ankündigung.

Den Eintrag zusammensetzen#

Der Eintrag ist ein TXT-Eintrag auf der Domain, deren Envelope-Adresse beim Versand verwendet wird. Er beginnt mit der Version, listet die Mechanismen durch Leerzeichen getrennt und endet mit all.

Es darf je Domain nur einen Eintrag mit v=spf1 geben. Bei mehreren endet die Auswertung laut RFC 7208 in permerror. Kommt ein Dienst hinzu, wird ein weiteres include in die bestehende Zeile eingefügt, keine zweite Zeile angelegt.

Für die einzelnen Bausteine gilt: include bindet fremde Dienste ein. ip4 und ip6 decken eigene Server mit fester Adresse ab. a und mx gehören nur hinein, wenn der Webserver beziehungsweise die eingetragenen Mailserver tatsächlich selbst versenden; sonst kosten sie unnötig eine DNS-Abfrage. ptr bleibt draußen, der Standard sagt, es soll nicht mehr veröffentlicht werden.

Die Zahl der Abfragen ist der eigentliche Kostenfaktor: RFC 7208 erlaubt bei der Auswertung höchstens zehn DNS-Abfragen, und jedes include bringt die Abfragen der eingebundenen Domain mit. Der SPF-Generator zählt sie beim Zusammensetzen mit. So sieht er am 03.10.2026 aus, mit beispiel.at und einem Google-Workspace-Include:

Zwei Sonderfälle werden gern vergessen. Versendet eine Unterdomain mit eigener Envelope-Adresse, braucht sie einen eigenen Eintrag, denn geerbt wird nichts. Und Domains, über die gar nicht versendet wird, bekommen v=spf1 -all, die kürzeste sinnvolle Regel überhaupt.

~all oder -all#

~all ist softfail: Der Empfänger nimmt die Mail in der Regel an und vermerkt den Fehlschlag. -all ist fail: Der Empfänger darf ablehnen. Beide Varianten sind zulässig, sie unterscheiden sich im Risiko der Übergangszeit.

Für den Start ist ~all die vernünftige Wahl. Es liefert über die Berichte dieselben Erkenntnisse wie -all, ohne dass ein vergessener Dienst gleich unsichtbar ausfällt. Sobald die Berichte über mehrere Wochen keine legitime Quelle mehr als Fehlschlag ausweisen, ist der Wechsel auf -all fällig.

?all und +all haben in einem produktiven Eintrag nichts zu suchen. Neutral heißt praktisch: keine Aussage.

Ein Argument gegen übereilte Härte sind Weiterleitungen. Reicht ein fremder Server eine Mail weiter, ohne den Envelope-Absender zu ersetzen, liefert er aus einer Adresse ein, die im SPF-Eintrag nicht steht. Die Prüfung schlägt fehl, obwohl die Mail echt ist. Nur wo Absender-Umschreibung eingesetzt wird, ist das entschärft. Deshalb sollte DKIM parallel eingerichtet sein, bevor -all gesetzt wird.

Die Reihenfolge der Inbetriebnahme#

1. Liste vervollständigen. Erst danach lohnt der erste Tastendruck.

2. TTL des TXT-Eintrags kurz setzen, einige Stunden vor der Änderung. Dann wirken Korrekturen schnell statt über einen halben Tag.

3. Eintrag mit ~all veröffentlichen und unmittelbar danach direkt beim autoritativen Namensserver nachsehen, ob genau eine Zeile mit v=spf1 zurückkommt. Ohne Kommandozeile tut das der E-Mail-Check.

4. DMARC mit p=none und rua einrichten, falls noch nicht geschehen, und die Berichte auswerten.

5. Fehlende Dienste nachtragen, bis in den Berichten nur noch Fremde scheitern.

6. Auf -all wechseln und die TTL wieder heraufsetzen.

Einen bestehenden Eintrag auslesen#

dig cyberscale.io TXT +short

"v=spf1 mx include:_spf.meinehp.at ~all"
"google-site-verification=0ypeVV4NRpUrOhxOVd_iiZhEWkrxHwwwpQJoarpwqX4"

Das ist die Antwort für die Domain dieses Magazins am 03.10.2026, abgefragt per DNS-over-HTTPS (dasselbe, was dig +short zeigt, nur ohne die Kommandozeile). Zwei TXT-Einträge, einer davon SPF. Ein SPF-Eintrag lässt sich in fünf Sekunden abfragen und in fünf Minuten falsch verstehen: Er ist ein gewöhnlicher TXT-Eintrag nach RFC 7208 und beantwortet genau eine Frage: welche Server im Namen dieser Domain Mails einliefern dürfen.

SPF hat keinen eigenen Satztyp. Gesucht ist der TXT-Eintrag der Domain, der mit v=spf1 beginnt. Unter Windows:

nslookup -type=TXT beispiel.de

Zwischen den Ergebnissen stehen üblicherweise Bestätigungscodes fremder Dienste, oben die Google-Bestätigung. Relevant ist allein die Zeile mit v=spf1 am Anfang. Steht dort nichts, existiert keine SPF-Regel für diese Domain, und jeder beliebige Server darf in ihrem Namen einliefern, ohne dass die Prüfung anschlägt.

Wichtig ist außerdem, welche Domain man abfragt. SPF wird auf der Domain des Envelope-Absenders ausgewertet. Versendet ein System mit rechnung@sub.beispiel.de als Envelope-Adresse, ist der Eintrag von sub.beispiel.de maßgeblich; Unterdomains erben nichts von der Hauptdomain.

Wie ein SPF-Eintrag gelesen wird#

Die Mechanismen werden von links nach rechts geprüft, und die erste Übereinstimmung entscheidet. Was danach steht, wird nicht mehr betrachtet.

ip4 und ip6 nennen einzelne Adressen oder Netzbereiche direkt. a trifft auf die Adressen aus dem A- oder AAAA-Eintrag der Domain zu, mx auf die Adressen der eingetragenen Mailserver. include übernimmt die Regel einer fremden Domain: Passt der einliefernde Server dort, gilt er auch hier als erlaubt. Ein Nichttreffer im include führt dagegen nicht zum Fehlschlag, sondern nur zur nächsten Regel. ptr gilt als überholt und soll laut RFC 7208 nicht mehr verwendet werden.

Der letzte Mechanismus ist all, und er trifft immer zu. Entscheidend ist sein Vorzeichen: ~all bedeutet softfail, -all bedeutet fail, ?all bedeutet neutral, +all erlaubt jedem alles. Ein Eintrag, der auf ?all oder +all endet, ist praktisch wirkungslos, auch wenn davor eine lange, saubere Liste steht.

Was SPF nicht prüft: den From:-Header, den der Empfänger im Postfach sieht. Geprüft wird nur der Envelope-Absender aus MAIL FROM. Ein sauberes spf=pass sagt deshalb nichts darüber aus, ob der sichtbare Absender echt ist; diese Lücke schließt erst DMARC, erklärt in DMARC einrichten. Wie eine echte Zustellung ausgegangen ist, steht im Kopf der empfangenen Mail in Authentication-Results, samt der Domain, auf die sich das Ergebnis bezieht.

Wie funktioniert SPF? Grundlagen einfach erklärt! – E-Mail Security 01 – Video abspielen (lädt YouTube)

Die Grenze von zehn DNS-Abfragen#

RFC 7208 begrenzt die Zahl der DNS-Abfragen, die bei der Auswertung eines Eintrags anfallen dürfen, auf zehn, nicht auf zehn include. Mit: include, a, mx, ptr, exists und redirect. Ohne: ip4, ip6 und all, denn die kosten keine Abfrage.

Die Falle steckt in der Rekursion. Ein einziges include kann intern mehrere weitere Abfragen auslösen, weil die eingebundene Domain ihrerseits include verwendet. Zählen lässt sich das nur, indem man jede eingebundene Domain selbst abfragt und weiterverfolgt:

dig _spf.beispielanbieter.de TXT +short

Wird die Grenze überschritten, ist das Ergebnis PermError. Das ist kein Pass mit Schönheitsfehler, sondern ein Auswertungsfehler: Die Prüfung liefert kein verwertbares Ergebnis, und der Schutz fällt aus. Abhilfe schaffen das Entfernen ungenutzter Dienste sowie das Ersetzen von a und mx durch feste ip4-Angaben, wo die Adressen stabil sind.

Einen Eintrag von Hand zählen#

Noch einmal der Eintrag von oben:

cyberscale.io.  TXT  "v=spf1 mx include:_spf.meinehp.at ~all"

mx kostet eine Abfrage. Zwischenstand 1.

include:_spf.meinehp.at kostet eine Abfrage für den TXT-Eintrag der eingebundenen Domain. Zwischenstand 2. Deren Eintrag:

_spf.meinehp.at.  TXT  "v=spf1 ip4:80.77.17.0/26 ip4:80.77.31.0/26 ip4:78.47.60.206 ip4:78.47.60.220 ip4:31.47.234.146 ip4:94.247.40.131 ip4:45.144.208.64/26 ~all"

Darin stehen nur ip4 und all, also keine weitere Abfrage. Endstand 2 von 10.

Das ~all am Ende des eingebundenen Eintrags zählt nicht für cyberscale.io. Ein include liefert nur „trifft zu“ oder „trifft nicht zu“; was bei Nichttreffer passiert, entscheidet das Vorzeichen im eigenen Eintrag, hier ebenfalls ~all.

Dieselbe Zählung macht der Prüfteil des SPF-Generators, wenn man den Eintrag hineinkopiert. Er sieht nur den Eintrag selbst und zählt deshalb „mindestens 2“; was in _spf.meinehp.at steckt, löst er nicht auf. Das tut der E-Mail-Check.

Was in echten Einträgen steht#

Wie Einträge draußen aussehen, habe ich an 149 Tiroler Domains nachgesehen. In eigener Sache: 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, abgefragt per DNS-over-HTTPS am 27. und 29.09.2026, veröffentlicht nur als Summen. 135 haben einen SPF-Eintrag, 14 keinen, und zwei haben zwei, womit sie nach RFC 7208 in permerror laufen.

Die Mehrheit stellt scharf: 96 Einträge enden mit -all, 35 mit ~all, 4 mit ?all. Bei den vieren sagt das Ende, dass alles davor keine Aussage trifft. Die 14 ohne Eintrag sind der Fall aus dem Abschnitt zum Auslesen: Jeder Server darf in ihrem Namen einliefern, ohne dass eine Prüfung anschlägt.

Welche Mechanismen in den 135 Einträgen vorkommen:

66 Einträge zahlen eine Abfrage für mx und 55 eine für a. Bei vielen davon versendet weder der Mailserver selbst noch der Webserver, die Abfrage ist dann verschenkt. Die 26 Einträge mit vier oder mehr include sind die Kandidaten für den PermError von oben, weil jedes include die Abfragen seiner Domain mitbringt. Der Eintrag dieses Magazins kommt mit zwei Abfragen von zehn aus, nachgezählt im Abschnitt davor.

Die häufigsten Fehler#

1. Zwei SPF-Einträge. Je Domain darf nur ein TXT-Eintrag mit v=spf1 existieren. Sind es zwei, gewinnt nicht der bessere, sondern die Auswertung endet in einem PermError. Der Fall entsteht fast immer beim Hinzufügen eines zweiten Dienstes, der seine eigene Zeile mitbringt. Richtig ist ein Eintrag mit mehreren include. In der Tiroler Zählung oben betraf das 2 von 149 Domains.

2. Ein Versandweg fehlt. Newsletter-Werkzeug, CRM, Shop, Rechnungsprogramm, Ticketsystem, Formularversand vom Webserver: Jedes System, das im Namen der Domain einliefert, muss abgedeckt sein. Welche Quellen tatsächlich versenden, verraten die DMARC-Sammelberichte, nicht das Gedächtnis der Beteiligten.

3. Zu scharf gestellt, ohne die Liste zu kennen. -all lässt Empfänger ablehnen. Fehlt ein legitimer Dienst, verschwinden dessen Mails, und zwar leise.

4. Ein zerschnittener Eintrag. Eine einzelne Zeichenkette im TXT-Eintrag darf höchstens 255 Zeichen lang sein; längere Einträge bestehen aus mehreren Teilen, die der Resolver wieder zusammensetzt. Manche Verwaltungsoberflächen machen daraus zwei getrennte Einträge, und damit ist Fehler eins wieder da.

5. Keine Regel für Domains ohne Mailversand. Wer eine Domain nur geparkt hat, sollte dort v=spf1 -all hinterlegen. Sonst bleibt sie eine bequeme Absenderadresse für Fremde.

Die Zählung der zehn Abfragen, mehrfache Einträge und den Abschluss mit all prüft der E-Mail-Check von selbst, zusammen mit DKIM und DMARC. Die fertige Zeile mit Zählung erzeugt der SPF-Generator.

Warum SPF allein nicht reicht#

SPF prüft den Envelope-Absender aus dem SMTP-Befehl MAIL FROM, nicht den From:-Header, den der Empfänger im Postfach sieht. Ein Angreifer kann also eine eigene, sauber per SPF gedeckte Domain im Umschlag verwenden und im sichtbaren From: trotzdem deine Adresse eintragen. Erst DKIM und DMARC schließen diese Lücke; warum, steht in DMARC einrichten. Woran du eine solche Mail im Header erkennst, zeigt E-Mail-Spoofing.

Häufige Fragen#

Stand 05.10.2026. An diesem Tag hat der Beitrag den bisherigen Beitrag „SPF-Eintrag prüfen und richtig lesen“ aufgenommen; dessen Adresse leitet hierher. Quellen abgerufen, eigener Eintrag nachgezählt und Werkzeug-Screenshots vom 03.10.2026.