SPF-Eintrag erstellen und prüfen: Aufbau, Grenzen, Fehler

Mit einem SPF-Eintrag sagst du der Welt, welche Server E-Mails für deine Domain einliefern dürfen. Empfangende Mailserver lesen ihn aus dem DNS und vergleichen ihn mit der IP-Adresse des Servers, der ihnen gerade eine Mail anbietet. Der Eintrag ist schnell geschrieben, aber er hat Regeln, die viele erst bemerken, wenn Mails abgewiesen werden. Die wichtigste ist die Grenze von zehn DNS-Abfragen. Wie SPF mit DKIM und DMARC zusammenarbeitet, steht unter SPF, DKIM und DMARC im Zusammenspiel.

Aufbau eines SPF-Eintrags

SPF wird als TXT-Eintrag veröffentlicht. Einen eigenen Eintragstyp gibt es dafür nicht mehr ^[1]. Der Text beginnt immer genau mit "v=spf1", danach folgen durch Leerzeichen getrennte Angaben ^[1]. Ein typischer Eintrag für eine Domain mit eigenem Server und einem Mailanbieter sieht so aus:

"v=spf1 ip4:192.0.2.10 ip6:2001:db8::10 include:_spf.example.net ~all"

Der empfangende Server liest die Angaben von links nach rechts. Passt eine davon zur IP-Adresse des einliefernden Servers, steht das Ergebnis fest, und der Rest wird nicht mehr geprüft. Die wichtigsten Mechanismen sind diese ^[1]:

• ip4 und ip6 nennen einzelne Adressen oder ganze Netze, etwa ip4:192.0.2.0/24.
• a erlaubt die Adressen, die im A- oder AAAA-Eintrag eines Namens stehen, ohne Angabe die der eigenen Domain.
• mx erlaubt die Server, die im MX-Eintrag stehen.
• include übernimmt das Ergebnis des SPF-Eintrags einer anderen Domain. So binden Mailanbieter und Newsletterdienste ihre Server ein.
• all passt immer und steht deshalb am Ende als Regel für alle übrigen Server.

Den Mechanismus ptr soll man nicht mehr veröffentlichen. RFC 7208 überschreibt ihn mit "do not use" ^[1]. Zum Mechanismus exists und zu Makros braucht eine normale Website nichts zu wissen.

~all, -all und die anderen Qualifier

Vor jedem Mechanismus kann ein Zeichen stehen, das das Ergebnis festlegt ^[1]. Fehlt es, gilt das Plus.

Am Ende steht meist ~all oder -all. Bei softfail soll ein Empfänger die Mail laut RFC 7208 nicht allein deshalb ablehnen, darf sie aber genauer prüfen ^[1]. Google empfiehlt für Google Workspace den Eintrag "v=spf1 include:_spf.google.com ~all" ^[2]. Mit -all erklärst du dagegen alle nicht genannten Server klar für unzulässig. Das passt, wenn du sicher bist, dass deine Liste vollständig ist. Lässt du all ganz weg, endet die Prüfung bei nicht genannten Servern mit neutral, als stünde ?all am Ende. RFC 7208 rät, das Ende ausdrücklich anzugeben ^[1].

Nur ein SPF-Eintrag je Domain

Eine Domain darf nur einen einzigen SPF-Eintrag haben ^[1]. Findet der Empfänger zwei TXT-Einträge, die mit "v=spf1" beginnen, ist das Ergebnis permerror, also ein dauerhafter Fehler, den nur eine Änderung im DNS behebt ^[1]. Das passiert oft, wenn ein neuer Dienst in seiner Anleitung "Lege diesen SPF-Eintrag an" schreibt und du ihn zusätzlich zum alten anlegst. Richtig ist, die neue include-Angabe in den vorhandenen Eintrag aufzunehmen.

Der Eintrag gilt nur für genau den Namen, unter dem er steht. Subdomains erben ihn nicht. Google weist darauf hin, dass jede Subdomain, die Mails versendet, einen eigenen SPF-Eintrag braucht ^[2]. Andere TXT-Einträge auf derselben Domain, etwa ein Prüfwert für die Search Console, stören SPF nicht, denn nur Einträge, die mit "v=spf1" beginnen, zählen als SPF-Eintrag ^[1].

Die Grenze von zehn DNS-Abfragen

Damit eine SPF-Prüfung das DNS nicht unbegrenzt belastet, zählt der Empfänger mit. Die Mechanismen include, a, mx, ptr und exists sowie der Zusatz redirect lösen jeweils eine DNS-Abfrage aus. Zusammen dürfen es während einer Prüfung höchstens zehn sein ^[1]. Wird die Grenze überschritten, lautet das Ergebnis permerror ^[1]. Die Mechanismen ip4, ip6 und all zählen nicht, weil sie keine Abfrage brauchen ^[1].

Die Falle liegt in den include-Angaben. Ein include zählt selbst als eine Abfrage, und alle Angaben im eingebundenen Eintrag zählen mit, denn die Grenze gilt für die gesamte Prüfung. Bindet ein Anbieter in seinem eigenen SPF-Eintrag drei weitere Einträge ein, verbraucht dein einzelnes include schon vier der zehn Abfragen. Wer einen Mailanbieter, einen Newsletterdienst, ein Ticketsystem und ein Rechnungsprogramm einbindet, kommt so schnell über zehn, ohne es dem eigenen Eintrag anzusehen.

Zwei weitere Grenzen kommen hinzu. Ein mx-Mechanismus darf höchstens zehn Adressabfragen für die Mailserver auslösen ^[1]. Und Abfragen, die ins Leere laufen, weil es den Namen nicht gibt oder er keine Antwort liefert, soll der Empfänger auf zwei begrenzen ^[1]. Ein include auf einen gelöschten Eintrag eines früheren Dienstleisters kostet also nicht nur eine Abfrage, er kann die Prüfung auch scheitern lassen.

So bleibst du unter zehn

• Streiche include-Angaben von Diensten, die du nicht mehr nutzt.
• Ersetze a und mx durch ip4 und ip6, wenn sich die Adressen deiner Server selten ändern. RFC 7208 empfiehlt die sparsameren Mechanismen, solange Änderungen nicht häufig sind ^[1].
• Lass Dienste wie Newsletter mit einer eigenen Subdomain als Umschlagabsender senden. Diese Subdomain bekommt einen eigenen SPF-Eintrag mit eigenem Budget von zehn Abfragen.
• Sei vorsichtig mit Werkzeugen, die alle include-Angaben in feste IP-Adressen auflösen. Ändert ein Anbieter seine Server, stimmt dein Eintrag nicht mehr, und du merkst es erst an abgewiesenen Mails ^[1].

Ein Beispiel Schritt für Schritt

Angenommen, deine Domain verschickt Mails über drei Wege: einen eigenen Server mit der Adresse 192.0.2.10, einen Postfachanbieter und einen Newsletterdienst. Der Postfachanbieter nennt in seiner Anleitung eine include-Angabe, der Newsletterdienst ebenfalls. Du beginnst mit "v=spf1", hängst ip4:192.0.2.10 an, dann die beiden include-Angaben, und schließt mit ~all. Das ergibt einen einzigen Eintrag mit zwei Abfragen aus deiner Hand. Wie viele die beiden Anbieter in ihren eigenen Einträgen hinzufügen, siehst du erst, wenn du deren TXT-Einträge abfragst und nachzählst.

Wer viele Domains mit derselben Regel betreibt, kann auf den Zusatz redirect zurückgreifen. Er verweist auf den SPF-Eintrag einer anderen Domain, der dann allein entscheidet ^[1]. Steht im selben Eintrag ein all, wird redirect ignoriert. Hat die Zieldomain keinen SPF-Eintrag, endet die Prüfung mit permerror ^[1].

Länge und Aufteilung des Eintrags

Ein einzelner Textbaustein in einem TXT-Eintrag darf höchstens 255 Zeichen lang sein. Längere SPF-Einträge werden deshalb in mehrere Bausteine in Anführungszeichen aufgeteilt, die der Empfänger ohne Leerzeichen zusammensetzt ^[1]. Die Verwaltungsoberflächen vieler Anbieter erledigen das selbst. Achte darauf, dass an der Trennstelle das Leerzeichen zwischen zwei Angaben erhalten bleibt, sonst verschmelzen sie zu einer ungültigen Angabe. RFC 7208 rät außerdem, die gesamte Antwort so klein zu halten, dass sie in 512 Bytes passt ^[1]. Auch das spricht für einen kurzen Eintrag.

Domains, die keine Mails verschicken

Für Domains ohne Mailversand ist ein SPF-Eintrag laut RFC 7208 bewährte Praxis. Er lautet "v=spf1 -all" und erklärt jeden Server für unzulässig ^[1]. Das gilt auch für Namen wie www, die nur eine Website tragen. Wer viele Domains besitzt, etwa Tippfehler-Varianten der Hauptdomain, sollte dort ebenfalls diesen Eintrag setzen.

Den SPF-Eintrag prüfen

Nach dem Speichern kann es dauern, bis der neue Eintrag überall ankommt. Google nennt für die SPF-Prüfung bis zu 48 Stunden ^[2]. Den Grund dafür erklärt die Seite TTL bei DNS. Prüfen kannst du auf drei Wegen:

1. Frag den TXT-Eintrag direkt ab, etwa mit dem DNS-Check oder auf der Kommandozeile mit "nslookup -type=txt deine-domain.de" ^[3]. Es darf genau ein Ergebnis mit "v=spf1" erscheinen.
2. Zähle die Abfragen: jedes include, a, mx, ptr, exists und redirect, auch in den eingebundenen Einträgen.
3. Schick eine Testmail an ein Postfach bei einem großen Anbieter und sieh dir den Quelltext an. Empfänger halten das Ergebnis in Kopfzeilen wie Received-SPF oder Authentication-Results fest ^[1]. Dort sollte spf=pass stehen.

Typische Fehler

• Zwei SPF-Einträge auf derselben Domain, oft nach dem Wechsel des Mailanbieters.
• Mehr als zehn Abfragen durch verschachtelte include-Angaben.
• Ein vergessener Absender wie das Kontaktformular der Website oder ein Shop, der Bestellbestätigungen verschickt.
• Ein Tippfehler in "v=spf1", etwa ein Leerzeichen zu viel oder eine falsche Versionsnummer. RFC 7208 behandelt einen Eintrag mit "v=spf10" nicht als SPF ^[1].
• Angaben hinter all. Sie werden nie geprüft ^[1].

SPF allein schützt nicht die Absenderadresse, die deine Empfänger sehen. Dafür brauchst du zusätzlich DKIM und DMARC. Landen deine Mails trotz korrektem Eintrag im Spam, findest du weitere Ursachen unter Eigene E-Mails landen im Spam. Wie Empfänger gefälschte Absender erkennen, beschreibt betrug.domain-root.de unter Gefälschte Absender erkennen.

1. Gesetz RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF, S. Kitterman. Stand April 2014. abgerufen am 29.10.2026
2. Organisation SPF einrichten. Google Workspace-Hilfe. Stand 2026. abgerufen am 29.10.2026
3. Organisation nslookup. Microsoft Learn, Windows-Befehle. Stand 08.09.2023. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.