Beliebte Tools

Design

SPF-Check — SPF-Eintrag prüfen

Der SPF-Check liest den SPF-Eintrag jeder Domain so, wie es empfangende Mailserver tun: jeden include mit seinen eigenen DNS-Lookup-Kosten, die laufende Summe gegen das Limit von 10, Void-Lookups und das Ergebnis für jede sendende IP, samt dem Term, der entschieden hat.

Quellen: die TXT-Einträge der Domain und jeder include, über Google Public DNS (dahinter Cloudflare 1.1.1.1) · RFC 7208 check_host, ausgeführt auf unserem Server · nichts wird gespeichert

Genau der Name, den Sie eingeben: SPF kennt keine Vererbung, daher braucht mail.example.com einen eigenen Eintrag.

Beispiel

Was ist ein SPF-Eintrag?

Ein SPF-Eintrag ist ein TXT-Eintrag, der die Server auflistet, die für eine Domain Mails senden dürfen. Er beginnt mit v=spf1, nennt dann Term für Term die Absender und endet damit, was Empfänger von allen anderen halten sollen (RFC 7208, April 2014, weiterhin der gültige Standard).

Empfänger prüfen ihn gegen die Adresse des Servers, der sich verbindet, und die Domain im Envelope-Absender, dem MAIL FROM oder Return-Path, nicht gegen die From:-Zeile, die ein Leser sieht. SPF mit From: zu verknüpfen ist Aufgabe von DMARC.

Ein Eintrag deckt nur genau den Namen ab, bei dem er steht: SPF kennt keine Vererbung, daher braucht mail.example.com einen eigenen Eintrag. Eine Domain, die keine Mails sendet, sollte v=spf1 -all veröffentlichen.

Ein SPF-Eintrag, Term für Termgoogle.com · TXT · aufgezeichnet am 24. Oktober 2026 · TTL 5 Minuten
v=spf1Versioninclude:_spf.google.comMechanismus · 1 Lookup~allQualifier ~ · Mechanismus all

Der include zeigt auf _spf.google.com · 8 Bereiche, keine weiteren Lookups

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

VersionGenau v=spf1, an erster Stelle: Ein Eintrag, der anders beginnt, ist kein SPF-Eintrag.
Mechanismeninclude, a, mx, ip4, ip6, exists, ptr und all, von links nach rechts geprüft: Der erste Treffer entscheidet.
Qualifier+ pass (der Standard), - fail, ~ softfail, ? neutral, vor einen Mechanismus geschrieben.
Modifierredirect= übergibt die Prüfung an einen anderen Eintrag; exp= erklärt ein fail.
Der ganze Eintrag von google.com besteht aus drei Termen: Ein Empfänger holt den include, gleicht die sendende IP mit dessen Bereichen ab oder erreicht ~all. Aufgezeichnet über Google Public DNS am 24. Oktober 2026.

SPF-Eintrag prüfen: So geht's

Geben Sie oben eine Domain ein, und der SPF-Check liest ihre TXT-Einträge, wählt den aus, der mit v=spf1 beginnt, und folgt dann jedem include und redirect, so wie es ein empfangender Server tut, wobei er jeden DNS-Lookup mitzählt.

Von Hand fragen Sie die TXT-Einträge ab: dig TXT example.com +short oder nslookup -type=TXT example.com. Die Antwort enthält jeden TXT-Eintrag beim Namen; der SPF-Eintrag ist der, der mit v=spf1 beginnt, und ein langer kommt als mehrere Strings in Anführungszeichen, die SPF ohne Leerzeichen zusammenfügt. Jeder include ist eine weitere Abfrage, und Sie müssten sie selbst zählen.

Um zu sehen, ob ein bestimmter Server senden darf, wechseln Sie zu IP testen: Es führt dieselbe Prüfung für diese Adresse aus und zeigt den Term, der gegriffen hat.

dig TXT example.com +short

Jeder TXT-Eintrag beim Namen, so wie Ihr Resolver ihn hat; der SPF-Eintrag ist der, der mit v=spf1 beginnt. Führen Sie es für jeden include erneut aus.

Was dig zeigt und was nichtgithub.com · dig TXT · aufgezeichnet am 24. Oktober 2026
Terminal1 von 24 TXT-Einträgen
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# dann jeder include, eine Abfrage nach der anderen:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Ein Eintrag beginnt mit v=spf1. Daneben stehen 23 weitere TXT-Einträge (Verifizierungs-Token und Ähnliches): Das zählt für SPF nicht, nur für die Größe der Antwort.
  2. 2 Strings, ohne Leerzeichen zusammengefügt. Die Teilung bei 255 Bytes fällt in ip4:62.253.227.114: Empfänger fügen die Strings wieder zusammen, das ist also in Ordnung.
  3. TTL 5 Minuten. Wie lange Resolver diese Kopie nach einer Änderung behalten dürfen. Der eigene Server der Zone nennt 5 Minuten; ein Resolver zeigt, was von seiner Kopie übrig ist.
  4. Jeder include ist eine eigene Abfrage. Dem Eintrag von github.com zu folgen, braucht 10 Lookups, verschachtelte eingeschlossen. dig zeigt immer einen Namen: Die Zählung bis 10 müssen Sie selbst addieren.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# jeder TXT-Eintrag beim Namen, von Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Diese Seite
/de/spf-checker?domain=github.com
Die TXT-Antwort von github.com vom eigenen Nameserver: Der SPF-Eintrag kommt als zwei Strings, ohne Leerzeichen zusammengefügt, zwischen den anderen TXT-Einträgen der Domain.

Das Ergebnis lesen: der include-Baum

Der Befund sagt, was Empfänger für einen Absender erhalten, den der Eintrag nicht listet: gültig mit seinem Abschluss (softfail bei ~all, fail bei -all), oder ein permerror mit seiner Ursache, oder „nicht prüfbar“, wenn DNS nicht geantwortet hat.

Die dunkelblaue Spalte ist das Lookup-Budget: eine Zelle pro DNS-Lookup, eingefärbt nach dem include, der ihn verbraucht, die laufende Summe gegen 10 und Void-Lookups als Ringe. Ab dem 10. werden die Zellen rot, und der Zweig, an dem Empfänger abbrechen, ist markiert.

Die Baumansicht listet die Befunde auf, Fehler zuerst, jeder mit seinem RFC-Abschnitt und der Lösung, dann jeden Lookup in der Reihenfolge, in der ein Empfänger fragt.

SPF-Check von github.com: 10 von 10 DNS-Lookups, ein Void, die Kosten jedes include im Lookup-BudgetSPF-Check von github.com: 10 von 10 DNS-Lookups, ein Void, die Kosten jedes include im Lookup-BudgetDer BefundWas Empfänger für einen Absender erhalten, den der Eintrag nicht listet, und der Abschluss, der es entscheidet.Der Eintrag, Term für TermJeder Term nach Art eingefärbt; ein include trägt das Zeichen seines Inhabers und seine eigenen Lookup-Kosten.Die BefundeEin Eintrag, gültige Syntax, Lookups, Voids, der Abschluss, ptr, DMARC: Fehler zuerst, jeder mit seiner Lösung.Das Lookup-BudgetJeder DNS-Lookup als Zelle, eingefärbt nach dem include, der ihn verbraucht, gegen das Limit von 10.Die Kosten jedes includeEin Zweig pro include: seine eigenen Zellen, was er verschachtelt und die laufende Summe.Die Void-LookupsRinge für Abfragen, die leer zurückkamen; die dritte beendet die Prüfung.
Ein SPF-Check von github.com: der Befund, der Eintrag in seine Terme zerlegt, die Befunde und das Lookup-Budget mit den eigenen Kosten jedes include. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Das 10-Lookup-Limit und „too many DNS lookups“ (permerror)

Empfänger zählen jeden Term, der eine DNS-Abfrage braucht, include, a, mx, ptr, exists und redirect, durch jeden verschachtelten include, und hören bei 10 auf. Der 11. ergibt permerror (RFC 7208 §4.6.4). ip4, ip6, all und exp kosten nichts.

Es ist ein permerror, kein fail: Was ein Empfänger damit macht, entscheidet er selbst, aber unter DMARC zählt ein permerror nie als Pass. Und weil die Prüfung beim ersten Treffer endet, besteht ein Eintrag über dem Limit für früh gelistete Absender weiterhin und bricht nur für spät gelistete.

Die Kosten verstecken sich in den includes: include:_netblocks.mimecast.com verbraucht allein 9, der von Yandex 360 8, der von Freshdesk 7, der von Mailgun 5. Die includes von Google und Microsoft 365 kosten je 1. Um unter 10 zu kommen, streichen Sie Absender, die Sie nicht mehr nutzen, und verlegen Sie einen Massenversender auf eine Subdomain mit eigenem Eintrag.

Wer die 10 Lookups verbrauchtKosten gemessen am 24. Oktober 2026 · ein ausgedachter Eintrag mit echten includes

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

17 Lookups nötig
Innerhalb der ersten 10 Lookups gelistet: passMicrosoft 3651Mimecast2–10
Nach Lookup 10 gelistet: permerrorMailgun11–15Twilio SendGrid16–17

Alle anderen erhalten ebenfalls permerror, nicht das fail von -all im Eintrag: Empfänger brechen ab, bevor sie es erreichen.

Was ein include kostetDer dokumentierte include jedes Anbieters · gemessen am 24. Oktober 2026
  • _netblocks.mimecast.comMimecast9 Lookups
  • _spf.yandex.netYandex 3608 Lookups
  • email.freshdesk.comFreshdesk7 Lookups
  • mailgun.orgMailgun5 Lookups
  • icloud.comiCloud+5 Lookups
  • spf.titan.emailTitan Email4 Lookups
  • secureserver.netGoDaddy3 Lookups
  • _spf.google.comGoogle Workspace1 Lookup
  • spf.protection.outlook.comMicrosoft 3651 Lookup
Lookups gezählt wie in RFC 7208 §4.6.4: der include selbst plus alles darin. Die Live-Zahlen auf dieser Seite stammen immer aus dem Durchlauf, nicht aus dieser Tabelle.

Was sind Void-Lookups?

Ein Void-Lookup ist eine Abfrage, die ohne Einträge zurückkommt: Der Name existiert nicht (NXDOMAIN) oder existiert ohne den abgefragten Eintrag. Empfänger sollten zwei zulassen; der dritte ist permerror (RFC 7208 §4.6.4).

Ein Term, der auf einen nicht mehr vorhandenen Host zeigt, a:old.example.com, ist für sich kein Fehler: Er greift nur nicht und zählt einen Void. Dasselbe gilt für exists:%{i}._spf.mta.salesforce.com bei jedem Absender, den Salesforce nicht listet, weshalb die Reihenfolge der includes zählt.

Ein Serverfehler oder eine Zeitüberschreitung ist kein Void: Es ist ein temperror, und Empfänger versuchen es meist später erneut.

Vier Antworten, drei ErgebnisseRFC 7208 §4.6.4

Der eigene Eintrag von salesforce.com für 192.0.2.1, aufgezeichnet am 24. Oktober 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Void-Lookups2 / 2ein dritter: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · Lookup 3 · in _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · Lookup 4 · in salesforce.com

Ergebnis: softfail, beide erlaubten Voids verbraucht

Der Name existiert, der Eintrag nichta:mail.example.com für einen Namen, der noch da ist, aber keine Adresse mehr hat: NOERROR ohne Antwort. Kein Treffer, ein Void, und die Prüfung geht weiter.NODATAVoid
Der Name existiert nichtexists:%{i}._spf.mta.salesforce.com bildet aus jeder sendenden IP einen Namen; für eine Adresse, die Salesforce nicht listet, lautet die Antwort NXDOMAIN: jedes Mal ein Void.NXDOMAINVoid
Der dritte Voidmx:shop.example.com, ein Name, den es nicht mehr gibt, nachdem bereits 2 Voids verbraucht sind: Empfänger brechen hier ab.NXDOMAINpermerror
Gar keine AntwortSERVFAIL oder eine Zeitüberschreitung für include:_spf.vendor.example: DNS ist ausgefallen, daher zählt nichts als Void.SERVFAILtemperror, kein Void

Der include include:spf.bmv.jp von blastmail beginnt mit zwei solchen exists-Termen: Für eine Adresse, die er nicht listet, verbraucht er beide erlaubten Voids allein.

Nur eine leere Antwort zählt als Void. Ein Ausfall ist ein temperror, und die Prüfung wird später erneut versucht.

SPF-Flattening: wann es hilft und wann es bricht

Flattening ersetzt einen include durch die Adressen, die er listet, damit der Eintrag weniger Lookups kostet. Das funktioniert für Bereiche, die sich selten ändern, und schlägt fehl, wenn ein Anbieter einen Server ergänzt, den Sie nie kopiert haben: Mails davon fallen dann bei SPF durch.

Microsoft sagt, include:spf.protection.outlook.com nicht zu flatten, und die includes von Google und Microsoft kosten ohnehin je einen Lookup. Einen Massenversender auf eine Subdomain wie news.example.com zu verlegen, gibt ihm einen eigenen Eintrag und eigene 10 Lookups.

Ein include, geflattetmailgun.org · aufgezeichnet am 24. Oktober 2026

Vorher

include:mailgun.org

Lookups
5
Abgerufene Einträge
5
Bytes in Ihrem Eintrag
19
Mailgun ändert einen Bereich
sofort übernommen

Nachher

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 weitere

Lookups
0
Bytes in Ihrem Eintrag
450
Nötige TXT-Strings
2
Mailgun ändert einen Bereich
Ihre Kopie ist veraltet

Das Risiko der veralteten Kopie. Sie kopieren heute 22 Bereiche; ergänzt Mailgun einen, fallen Mails davon bei SPF durch, bis jemand es bemerkt und den Eintrag aktualisiert.

  1. kopiert
  2. Mailgun ergänzt einen Bereich
  3. Mails davon fallen bei SPF durch
Flatten nur Bereiche, die sich selten ändern, etwa die Adressen Ihrer eigenen Server.
Nicht flatten Microsoft 365: Microsoft sagt, dass sich seine Sendeadressen oft ändern, behalten Sie also den include.
Besser eine Subdomain pro Massenversender: Jeder erhält einen eigenen Eintrag und eigene 10 Lookups.
Flattening tauscht Lookups gegen Pflegeaufwand: Die Kopie stimmt nur, bis der Anbieter seine Bereiche ändert.

~all vs -all (und DMARC)

Der letzte Term sagt, was mit jedem nicht gelisteten Absender geschieht. -all ist fail, die stärkste Aussage; ~all ist softfail, „wahrscheinlich nicht“; ?all ist neutral, was Empfänger wie gar kein SPF behandeln; +all lässt jeden bestehen und sollte nie veröffentlicht werden.

Zwischen ~all und -all gibt es keine falsche Antwort. Google dokumentiert ~all für Google Workspace und Microsoft -all für Microsoft 365. Mit DMARC im Enforcement lässt ~all DMARC anhand von DKIM entscheiden: Manche Empfänger lehnen bei -all ab, bevor DMARC eine bestandene DKIM-Signatur sieht, daher können weitergeleitete Mails zurückkommen (RFC 9989 §7.1).

Die vier AbschlüsseRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail„Wahrscheinlich nicht autorisiert“: Empfänger sollten allein deswegen nicht ablehnen.
Dokumentiert vonGoogle WorkspaceMailguniCloud+
-all
failDie stärkste Aussage: Ein Empfänger darf die Nachricht schon in SMTP ablehnen.
Dokumentiert vonMicrosoft 365ZendeskGoDaddy
?all
neutralGar keine Aussage: Empfänger behandeln es genau wie kein SPF.
Dokumentiert vonFastmailDie includes von IONOS und OVHcloud enden ebenfalls auf ?all: dort harmlos, da nur ein Pass in einem include greift.
+all
pass für jedenJeder Server im Internet besteht als die Domain.
Nie veröffentlichen

-all mit DMARC bei p=reject

  1. SPF: fail
  2. in SMTP abgelehnt
  3. DKIM nie geprüft

Manche Empfänger handeln zuerst nach SPF, daher kann eine weitergeleitete Nachricht mit gültiger DKIM-Signatur abgelehnt werden, bevor DMARC läuft, und der Verlust zeigt sich nie in DMARC-Berichten.

~all mit DMARC bei p=reject

  1. SPF: softfail
  2. DMARC prüft DKIM
  3. DKIM passt: pass

DMARC entscheidet. Ohne DKIM-Signatur wird DMARC laut Microsoft bei ~all-Fehlschlägen jedoch faktisch ignoriert, und Microsoft empfiehlt deshalb -all.

~all und -all sind beide gültige Entscheidungen; ?all sagt nichts, und +all lässt jeden bestehen.

Häufige SPF-Fehler und ihre Lösung

Die meisten defekten Einträge entstehen durch drei Fehler: einen zweiten SPF-Eintrag neben dem ersten, statt sie zusammenzuführen, einen include für einen Anbieter, den es nicht mehr gibt, und einen aus der Doku kopierten Wert mit einem Tippfehler.

Anbieter-Dokus drucken manche davon selbst: Mimecast schreibt –all mit Halbgeviertstrich, Postmark include: spf.mtasv.net mit Leerzeichen, Twilio SendGrid führt einen aaaa-Mechanismus auf, den es nicht gibt. Jeder Syntaxfehler macht den ganzen Eintrag zum permerror. Ein abschließender Punkt hinter einer Domain ist dagegen gültig.

Acht Einträge, acht ErgebnisseAusgedachte Beispiele echter Fehler

Zwei SPF-Einträgepermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Lösung: zu einem zusammenführen: ein v=spf1, jeder include einmal, ein Abschluss.

Mehr als 10 Lookupspermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 Lookups

Lösung: Absender streichen, die Sie nicht mehr nutzen, oder einem Massenversender eine eigene Subdomain geben.

Ein dritter Void-Lookuppermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 Voids

Lösung: Terme löschen, deren Namen es nicht mehr gibt, und exists-includes ans Ende setzen.

Ein include ohne SPF-Eintrag dahinterpermerror

v=spf1 include:spf.retired-vendor.example -all

Lösung: den Namen korrigieren oder den Anbieter entfernen, den Sie verlassen haben.

Ein Halbgeviertstrich in –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

So gedruckt in der eigenen Dokumentation von Mimecast

Lösung: ein einfacher Bindestrich: -all.

Ein Leerzeichen nach include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

So gedruckt in der eigenen Dokumentation von Postmark

Lösung: include:spf.mtasv.net

Ein aaaa-Mechanismuspermerror

v=spf1 aaaa:example.com ~all

So gedruckt in der eigenen Dokumentation von Twilio SendGrid

Lösung: a:example.com; a greift bereits auf die AAAA-Einträge von IPv6-Absendern.

Ein abschließender Punktgültig

v=spf1 include:spf.protection.outlook.com. -all

Gültig: RFC 7208 §7.3 sagt, ihn nicht zu veröffentlichen, aber Empfänger müssen ihn akzeptieren.

Die Hilfe von Zendesk sagt außerdem „redirect: syntax is supported“: Der Modifier wird redirect= geschrieben (RFC 7208 §6.1).

Jeder Eintrag ist ein ausgedachtes Beispiel; die Fehler sind die, die Empfänger am häufigsten sehen.

Was Gmail, Yahoo und Microsoft verlangen

Seit Februar 2024 verlangen Gmail und Yahoo von jedem Absender, SPF oder DKIM einzurichten. Massenversender brauchen beides, einen DMARC-Eintrag von mindestens p=none und eine From:-Domain, die zu einem von beiden passt. Outlook.com verlangt von Absendern mit hohem Volumen SPF und DKIM beide und lehnt solche ohne sie seit dem 5. Mai 2025 ab.

Die Schwelle von Gmail liegt bei mehr als 5.000 Nachrichten pro Tag an persönliche Konten; Yahoo veröffentlicht keine. SPF allein macht Mails nie „aligned“: Die MAIL-FROM-Domain muss Ihre sein, nicht die Bounce-Domain des Anbieters.

Die Regeln der drei PostfachanbieterAuf den eigenen Seiten jedes Anbieters gelesen, 24. Oktober 2026
GmailYahooOutlook.com
Schwelle für MassenversandGmailmehr als 5.000 Nachrichten pro Tag an persönliche Gmail-Konten, pro Primärdomain gezähltYahookeine veröffentlicht: „We will not specify a volume threshold“Outlook.commehr als 5.000 pro Tag (Microsofts Blog); 5.000 oder mehr von einer From:-Domain (sein Support-Artikel)
Alle AbsenderGmailSPF oder DKIM, dazu Forward- und Reverse-DNS, TLS und eine Spam-Rate unter 0,3 %YahooSPF oder DKIM, dazu Forward- und Reverse-DNS und eine Spam-Rate unter 0,3 %Outlook.comkeine feste Regel
MassenversenderGmailSPF und DKIM, DMARC (p=none genügt), From: passend zu SPF oder DKIM, Abmeldung mit einem Klick für Marketing-MailsYahooSPF und DKIM, DMARC mindestens p=none und bestanden, From: passend zu SPF oder DKIM, Abmeldung mit einem KlickOutlook.comSPF muss bestehen und DKIM muss bestehen, DMARC mindestens p=none, passend zu SPF oder DKIM
In Kraft seitGmail1. Februar 2024; Ablehnungen ab November 2025 verstärktYahooFebruar 2024Outlook.com5. Mai 2025 (Ablehnung)
SPF-Fehlschlag zeigt sich alsGmail4.7.275.7.27Yahoofür SPF nicht dokumentiertOutlook.com550 5.7.515

Japan: Die strengste Einstellung von NTT docomo, 「全て拒否する」, weist Mails ab, deren sendende IP der SPF-Eintrag der Domain nicht autorisiert, und Mails von Domains, die gar keinen SPF-Eintrag veröffentlichen. docomo.ne.jp

Quellensupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Die Regeln jedes Anbieters, wie seine eigenen Seiten sie am 24. Oktober 2026 nennen.

SPF-Lookup vs. dig und nslookup

dig und nslookup zeigen die TXT-Einträge, wie Ihr Resolver sie hat: den SPF-Eintrag und alles andere, was beim Namen steht. Sie folgen keinen includes, zählen keine Lookups oder Voids und sagen nicht, was ein Empfänger entscheiden würde.

Ein SPF-Lookup wie dieser durchläuft den ganzen Eintrag, daher stimmen die Zahlen mit dem überein, was ein empfangender Server berechnet. Nutzen Sie dig für einen Namen, diesen Checker für den Befund.

Drei Arten, SPF anzusehenWas jede zeigt
Dieser Checkerdig TXTnslookup -type=TXT
Zeigt die TXT-EinträgeDieser CheckerJain Terme zerlegtdig TXTJanslookup -type=TXTJa
Fügt die Strings eines langen Eintrags zusammenDieser CheckerJawie Empfängerdig TXTNeinzeigt jeden String einzelnnslookup -type=TXTNeinzeigt jeden String einzeln
Folgt jedem includeDieser CheckerJader ganze Baumdig TXTNeinein Name pro Abfragenslookup -type=TXTNeinein Name pro Abfrage
Zählt Lookups bis 10Dieser CheckerJaeine laufende Summe, pro includedig TXTNeinvon Handnslookup -type=TXTNeinvon Hand
Zählt Void-LookupsDieser CheckerJamit den Namendig TXTNeinnslookup -type=TXTNein
Sagt: zwei Einträge = permerrorDieser CheckerJadig TXTNeingibt beide ausnslookup -type=TXTNeingibt beide aus
Testet eine sendende IPDieser CheckerJacheck_host und der passende Termdig TXTNeinnslookup -type=TXTNein
Fragt Ihren eigenen ResolverDieser CheckerNeinGoogle Public DNS, von unserem Serverdig TXTJanslookup -type=TXTJa
Dieselbe Frage auf drei Arten gestellt: dig und nslookup zeigen, was Ihr eigener Resolver hat, der Checker, was ein Empfänger berechnet.

SPF-Check: häufige Fragen

Was ist ein SPF-Check?

Ein SPF-Check liest den SPF-Eintrag einer Domain, den TXT-Eintrag, der mit v=spf1 beginnt, und durchläuft ihn wie ein empfangender Mailserver: Jeder include und redirect wird verfolgt, jeder DNS-Lookup gegen das Limit von 10 gezählt und jede leere Antwort gegen das Limit von 2. Am Ende steht, was Empfänger für einen nicht gelisteten Absender erhalten, oder der permerror samt Ursache.

Wie teste ich, ob eine IP-Adresse E-Mails für meine Domain senden darf?

Wählen Sie „IP testen“, geben Sie die Domain und die Adresse des sendenden Servers ein, IPv4 oder IPv6, und optional die MAIL-FROM-Adresse und den HELO-Namen. Der Checker führt check_host für diese Adresse aus und zeigt pass, fail, softfail, neutral oder permerror, den Term, der gegriffen hat, seinen Qualifier und die Kette der includes, die dorthin führte.

Was bedeutet „SPF too many DNS lookups“?

Es bedeutet, dass die Prüfung des Eintrags mehr als 10 DNS-Lookups braucht, das Limit in RFC 7208. Jeder include, a, mx, ptr, exists und redirect kostet einen, auch die in includes verschachtelten. Empfänger brechen beim 11. mit permerror ab, daher bestehen Absender, die danach gelistet sind, SPF nicht mehr. Entfernen Sie unbenutzte includes oder verlegen Sie einen Absender auf eine Subdomain mit eigenem Eintrag.

Was ist ein SPF-permerror?

Ein permerror ist das SPF-Ergebnis „dieser Eintrag lässt sich nicht auswerten“. Er entsteht durch mehr als 10 DNS-Lookups, mehr als 2 Void-Lookups, zwei SPF-Einträge bei einem Namen, einen include eines Namens ohne SPF-Eintrag oder einen Syntaxfehler. Es ist kein fail: Empfänger entscheiden selbst, was sie damit tun, aber unter DMARC zählt er nie als Pass.

Was ist ein Void-Lookup bei SPF?

Ein Void-Lookup ist eine DNS-Abfrage für einen SPF-Term, die leer zurückkommt: Der Name existiert nicht (NXDOMAIN) oder hat keinen Eintrag des abgefragten Typs. RFC 7208 sagt, Empfänger sollten zwei zulassen; der dritte ist permerror. Ein Serverfehler oder eine Zeitüberschreitung ist kein Void-Lookup, sondern ein temperror, den Empfänger meist später erneut versuchen.

Sollte mein SPF-Eintrag mit ~all oder -all enden?

Beides ist gültig. -all (fail) ist die stärkste Aussage und wird von Microsoft für Microsoft 365 dokumentiert; ~all (softfail) dokumentiert Google für Google Workspace. Mit DKIM-Signatur und DMARC bei quarantine oder reject ist ~all oft der sicherere Abschluss, weil manche Empfänger bei -all ablehnen, bevor DMARC eine bestandene DKIM-Signatur akzeptieren kann.

Kann eine Domain zwei SPF-Einträge haben?

Nein. Hat ein Name zwei TXT-Einträge, die mit v=spf1 beginnen, können Empfänger keinen auswählen, und die Prüfung endet vor jedem Lookup in einem permerror, für jeden Absender (RFC 7208 §4.5). Das passiert meist, wenn der Eintrag eines neuen Anbieters neben den alten gesetzt wird. Führen Sie sie zu einem Eintrag mit einem v=spf1, jedem include einmal und einem einzigen Abschluss zusammen.

Was ist SPF-Flattening, und sollte ich es nutzen?

Flattening ersetzt includes durch die IP-Bereiche, die sie listen, damit der Eintrag weniger DNS-Lookups braucht. Es hilft bei Bereichen, die sich selten ändern, aber eine geflattete Kopie veraltet, sobald der Anbieter Server ergänzt, und Mails davon fallen dann bei SPF durch. Besser sind das Entfernen unbenutzter includes oder eine eigene Subdomain für einen Massenversender; flatten Sie nie den include von Microsoft 365.

Braucht eine Subdomain einen eigenen SPF-Eintrag?

Ja. SPF kennt keine Vererbung: Ein Eintrag deckt nur genau den Namen ab, bei dem er veröffentlicht ist, daher braucht mail.example.com oder news.example.com einen eigenen Eintrag, wenn sie in MAIL FROM oder HELO vorkommt. Das unterscheidet sich von DMARC, das auf die Organisationsdomain zurückfällt. Eine Subdomain, die keine Mails sendet, kann v=spf1 -all veröffentlichen.

Warum besteht SPF hier, fällt aber bei Gmail durch?

Meist, weil Gmail eine andere Domain oder Adresse geprüft hat. SPF wird für die MAIL-FROM-Domain (Return-Path) und die IP des verbindenden Servers ausgewertet, und das kann die Bounce-Domain Ihres Anbieters sein, nicht Ihre. Auch Weiterleitung bricht SPF, da die IP des Weiterleiters nicht in Ihrem Eintrag steht. Prüfen Sie den Authentication-Results-Header einer echten Nachricht und testen Sie diese IP und Domain hier.

Was ist der Unterschied zwischen SPF, DKIM und DMARC?

SPF listet die Server auf, die für eine Domain senden dürfen, und wird gegen den Envelope-Absender geprüft. DKIM signiert jede Nachricht mit einem in DNS veröffentlichten Schlüssel, daher übersteht die Signatur eine Weiterleitung. DMARC verknüpft beides mit der From:-Adresse, die ein Leser sieht: Eine Nachricht besteht DMARC, wenn SPF oder DKIM für eine zu From: passende Domain besteht, und die Richtlinie sagt, was sonst geschehen soll.

Wie lange dauert es, bis eine Änderung am SPF-Eintrag wirkt?

So lange, wie Resolver den alten Eintrag behalten: bis zu seiner TTL, die die Domain festlegt (300 Sekunden bei google.com und github.com, eine Stunde bei microsoft.com, als wir geprüft haben). Empfänger fragen ihren Resolver, daher zeigt sich eine Änderung, sobald jede Kopie im Cache abläuft. Dieser Checker zeigt die TTL, wie der eigene Nameserver der Domain sie ausliefert; prüfen Sie nach dieser Zeit erneut.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen

Verwandte E-Mail- und DNS-Tools