Defaults.Exposed › Behebungen › Guides

„SPF Record Not Found“ — obwohl Sie einen haben? Die 5 echten Ursachen (2026)

Veröffentlicht 2026-07-08

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.

Wenn ein Checker „SPF record not found“ sagt, Sie aber sicher sind, einen veröffentlicht zu haben, ist der Eintrag meist unsichtbar statt fehlend: 1.013.416 Domains — etwa eine von 138 unter denen, die SPF versuchen — veröffentlichen zwei oder mehr SPF-Einträge, ein PermError (RFC 7208 §3.2), den viele Checker als nicht gefunden melden, laut dem Defaults.Exposed-Zensus über 261 Millionen Domains.

Es gibt fünf echte Ursachen, alle in einer Sitzung behebbar: falscher Host, doppelter Eintrag, falscher DNS-Typ oder verstümmelte Anführungszeichen, inkonsistente Nameserver, oder eine Längen-/CNAME-Kollision. Im Folgenden: der 60-Sekunden-Test für jede, in der Reihenfolge, in der Sie sie prüfen sollten, dann die Lösungsschritte.

Sind Sie sicher, dass der Eintrag wirklich existiert?

Beginnen Sie mit der unschmeichelhaften Möglichkeit, denn sie ist mit Abstand die häufigste: Von den 261.086.232 im Defaults.Exposed-Zensus bewerteten Domains haben 121.145.609 — 46,4% — überhaupt keinen SPF-Eintrag. Viele „aber ich habe das eingerichtet“-Fälle entpuppen sich als Eintrag, der zu einer Staging-Zone oder einem alten DNS-Anbieter hinzugefügt wurde, der nicht mehr autoritativ ist. Prüfen Sie beim DNS-Anbieter, auf den Ihre Nameserver tatsächlich zeigen (oft nicht Ihr Registrar), nach einem TXT-Eintrag, der mit v=spf1 beginnt. Ist er wirklich nicht da, überspringen Sie die Detektivarbeit und gehen Sie direkt zu Ihren SPF-Eintrag reparieren.

Wie prüft man einen SPF-Eintrag richtig?

Web-Checker fragen DNS über ihren eigenen zwischenspeichernden Resolver ab. Um die Wahrheit zu sehen, fragen Sie den autoritativen Nameserver Ihrer Domain direkt:

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Unter Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Zwei Interpretationsregeln. Erstens: Zählen Sie die mit v=spf1 beginnenden Zeilen — die Anzahl zählt genauso viel wie der Inhalt. Zweitens: Prüfen Sie, ob Sie den richtigen Namen abgefragt haben: Empfänger bewerten SPF gegen die Domain im Return-Path (RFC5321.MailFrom, das „envelope from“) — nicht die From-Adresse, die Empfänger sehen. Bounct Ihr Newsletter-Tool Mail über bounce.ihredomain.com, ist ein perfekter Eintrag am Apex nicht der Eintrag, den Empfänger nachschlagen.

Was sind die fünf echten Ursachen?

Datenstand: 2026-06-29.

1. Steht der Eintrag beim falschen Host?

Der Klassiker: SPF wurde bei mail.ihredomain.com hinzugefügt, während Mail vorgibt, von ihredomain.com zu kommen — oder umgekehrt. SPF vererbt sich nicht nach unten — ein Eintrag am Apex sagt nichts über Subdomains, und umgekehrt. Veröffentlichen Sie genau bei dem Namen in Ihrem Return-Path. Ein Anbieter, der von seiner eigenen Bounce-Subdomain sendet, braucht einen Eintrag auf dieser Subdomain — meist einen vom Anbieter bereitgestellten CNAME oder TXT (der GoDaddy-SPF-Einrichtungsleitfaden zeigt, wo diese Felder liegen).

2. Haben Sie zwei SPF-Einträge?

Die Hauptursache, und die irreführendste Fehlermeldung in der E-Mail-Authentifizierung. RFC 7208 §3.2 ist unmissverständlich: Eine Domain muss genau einen SPF-Eintrag haben. Zwei oder mehr sind ein PermError — Empfänger behandeln Ihr SPF als ungültig. Manche Checker melden diesen Zustand korrekt („mehrere Einträge gefunden“); andere melden den Nettoeffekt: kein gültiger SPF-Eintrag gefunden. Sie sehen einen Eintrag in Ihrem Panel und schließen, der Checker sei kaputt. Ist er nicht — Sie haben einen Eintrag zu viel.

Der Zensus fand 1.013.416 Domains mit zwei oder mehr SPF-Einträgen — etwa eine von 138 der Domains, die SPF versuchen — jede mit effektiv abgeschaltetem SPF. Es passiert meist bei einem Anbieterwechsel: Der Assistent des neuen Anbieters fügt einen frischen Eintrag hinzu, statt den alten zu bearbeiten. Die Lösung ist ein Zusammenführen, nie ein zweiter Eintrag: Kombinieren Sie alles zu einer einzigen v=spf1 … ~all-Zeile und löschen Sie den Rest. Unser Datenbericht zwei SPF-Einträge ergeben keinen schlüsselt auf, wie eine Million Domains hierhin kamen; begann es nach einer Migration, siehe SPF funktioniert nach Anbieterwechsel nicht mehr. Beim Zusammenführen sollten Sie nicht blind jeden include: aneinanderreihen — jeder kostet DNS-Lookups gegen SPFs harte Grenze von 10 und tauscht Nicht-gefunden gegen einen PermError: too many DNS lookups.

3. Haben Sie den falschen Eintragstyp veröffentlicht — oder hat die Oberfläche ihn verstümmelt?

Frühes SPF hatte einen eigenen DNS-Eintragstyp (Typ 99, wortwörtlich „SPF“ genannt). Er wurde verworfen: RFC 7208 verlangt TXT, und Empfänger fragen Typ 99 nicht ab. Manche DNS-Panels bieten „SPF“ im Eintragstyp-Dropdown noch an; wählen Sie es, und Ihr Eintrag ist real, wohlgeformt und unsichtbar. Prüfen Sie die Typ-Spalte und veröffentlichen Sie erneut als TXT.

Das subtilere Geschwister sind Anführungszeichen. Einen in Anführungszeichen eingefassten Wert in ein Feld einzufügen, das eigene Anführungszeichen hinzufügt, erzeugt ""v=spf1 …"" — das nicht mehr mit v=spf1 beginnt, also für einen Verifizierer nicht existiert. Ihre dig-Ausgabe zeigt die Wahrheit; das DNS-Panel verbirgt sie oft kosmetisch.

4. „Verbreitet sich” es wirklich noch?

„Geben Sie ihm 24–48 Stunden zum Verbreiten“ ist der am meisten überstrapazierte Rat im DNS. Verbreitung ist nur ablaufende Caches: Sobald die TTL des Eintrags verstrichen ist (typischerweise 1 Stunde, selten mehr als 24), sieht jeder Resolver die neue Antwort. Immer noch nicht gefunden nach 24 Stunden? Verbreitung ist nicht die Ursache.

Die zwei echten Übeltäter: Negatives Caching — ein Resolver, der Sie bevor Sie den Eintrag hinzugefügt haben, nachgeschlagen hat, speichert die Antwort „kein solcher Eintrag“ zwischen, bis die negative TTL abläuft — und inkonsistente Nameserver nach einer Migration, bei der die Domain noch die Nameserver des alten Anbieters neben den neuen listet und die halbe Welt eine Zone liest, die Sie nicht mehr bearbeiten. Fragen Sie jeden gelisteten Nameserver direkt ab; unterscheiden sich die Antworten, haben Sie es gefunden. Reparieren Sie die NS-Delegation beim Registrar, sodass nur der Anbieter, den Sie tatsächlich bearbeiten, autoritativ ist.

5. Ist der Eintrag zu lang, oder von einem CNAME blockiert?

Ein einzelner String in einem TXT-Eintrag hat maximal 255 Zeichen. Längere SPF-Einträge sind legal, müssen aber in mehrere in Anführungszeichen gesetzte Strings innerhalb eines Eintrags aufgeteilt werden — und DNS-Anbieter-Oberflächen vermasseln die Aufteilung regelmäßig, kürzen den Wert oder brechen ihn mitten in einem Mechanismus, sodass er nicht mehr geparst wird. Ist Ihr Eintrag lang, prüfen Sie die dig-Ausgabe auf einen Wert, der abrupt endet.

Separat davon verbietet DNS einen TXT-Eintrag an einem Namen, der bereits einen CNAME hat. Ist mail.ihredomain.com ein CNAME zu Ihrem Anbieter, können Sie dort nicht auch SPF setzen — manche Panels akzeptieren es und liefern dann nur den CNAME aus. Setzen Sie den Eintrag dort, wohin der CNAME zeigt (falls Sie ihn kontrollieren), oder strukturieren Sie so um, dass der sendende Name nicht CNAME-belegt ist. Anbieter mit sauberer TXT-Handhabung machen beides leichter — siehe den Cloudflare-SPF-Einrichtungsleitfaden.

Wie beheben Sie es, Schritt für Schritt?

1. Führen Sie den kostenlosen Scan bei defaults.exposed durch — er liest Ihr live DNS und sagt Ihnen, in welchem der fünf Zustände Sie stecken, bevor Sie irgendetwas anfassen.
2. Bestätigen Sie, welche Nameserver autoritativ sind (dig NS) und dass sie alle übereinstimmen.
3. Fragen Sie TXT beim autoritativen Nameserver für die exakte Return-Path-Domain ab.
4. Zählen Sie die v=spf1-Zeilen: null → einen veröffentlichen; zwei oder mehr → zu einem zusammenführen.
5. Verifizieren Sie, dass der Typ TXT ist, der Wert exakt mit v=spf1 beginnt, und sich keine verirrten Anführungszeichen oder Abschneidungen eingeschlichen haben.
6. Warten Sie eine TTL ab, dann scannen Sie erneut, um zu bestätigen, dass er überall sauber auflöst.

Häufig gestellte Fragen

Warum sagt der Checker „not found“, obwohl ich den Eintrag in meinem DNS-Panel sehen kann? Meist Ursache 2 oder 4: Ein zweiter v=spf1-Eintrag macht beide ungültig — ein PermError, den manche Tools als nicht gefunden melden, der Zustand, in dem 1.013.416 Domains Stand 2026-06-29 stecken — oder Ihr Panel ist nicht das DNS, das tatsächlich autoritativ ist.

Wie lange dauert es, bis Checker meine Reparatur sehen? Eine TTL — typischerweise eine Stunde, höchstens 24. Danach ist „Verbreitung“ nicht die Erklärung; prüfen Sie erneut die fünf Ursachen, beginnend mit der Nameserver-Konsistenz.

Sollte ich den „SPF“-Eintragstyp nutzen, den mein DNS-Panel anbietet? Nein. Typ 99 ist veraltet; RFC 7208 verlangt ausschließlich TXT. Ein Typ-99-Eintrag ist für moderne Empfänger unsichtbar.

Der Eintrag wird jetzt gefunden — warum scheitert meine Mail trotzdem an SPF? Weil SPF gegen die Return-Path-Domain geprüft wird, nicht den From-Header, und der Eintrag tatsächlich die Server auflisten muss, die für Sie senden. Gefunden ist Schritt eins; der Leitfaden Ihren SPF-Eintrag reparieren behandelt das Bestehen.

Ist es wirklich so häufig, keinen SPF-Eintrag zu haben? Ja — 121.145.609 Domains, 46,4% der 261.086.232 im Defaults.Exposed-Zensus bewerteten (Stand 2026-06-29), veröffentlichen überhaupt kein SPF. Nicht gefunden ist der Standardzustand des Internets.

Senden Sie dem Inhaber den Bericht

Sobald der Eintrag sauber auflöst, führen Sie den Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber oder Kunden weiter, dessen Domain das ist. Er zeigt in klarer Sprache, was kaputt war, was Sie repariert haben und wo die Domain jetzt steht — genau der Beleg, nach dem bei Cyberversicherungs-Verlängerungen und Lieferanten-Sicherheitsfragebögen gefragt wird. Der Bericht ist die Quittung für die Arbeit.

Prüfen Sie Ihren SPF-Eintrag kostenlos

Sehen Sie, in welchem der fünf Nicht-gefunden-Zustände Ihre Domain steckt — privat und nur für den Inhaber.

Prüfen Sie Ihre Domain → · SPF reparieren → · SPF funktioniert nach Anbieterwechsel nicht mehr → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.