SPF-Eintrag nicht gefunden: Ursachen und Lösung

Ein Prüftool meldet „no SPF record found“, oder im Header einer Nachricht steht spf=none. Beide Meldungen bedeuten dasselbe: Der Resolver hat die TXT-Einträge zu einem bestimmten Namen abgefragt, und keiner begann mit v=spf1. Mit Ihrem Mailserver ist nichts falsch. Die Frage ist, warum die Antwort leer war, und meist liegt es daran, dass am falschen Namen geprüft oder veröffentlicht wurde.

Dieser Beitrag ist der Diagnoseweg für diese leere Antwort. Wenn Ihr Problem ein Eintrag ist, der zwar existiert, aber fehlerhaft ist, lesen Sie stattdessen die Beiträge zu zu vielen DNS-Abfragen und zum Limit von 10 Abfragen.

Was „nicht gefunden“ tatsächlich bedeutet

SPF steht in einem gewöhnlichen TXT-Eintrag. Ein Empfänger entnimmt die Domain der Nachricht (normalerweise der Envelope-Absender, auch Bounce- oder Return-Path-Adresse genannt), fragt deren TXT-Einträge ab und behält nur die, deren Text mit v=spf1 beginnt. Ist diese gefilterte Liste leer, lautet das Ergebnis none. Das ist kein Syntaxfehler, sondern das Fehlen einer Richtlinie.

Das unterscheidet sich von den beiden anderen Situationen, mit denen es oft verwechselt wird. Jede hat ihr eigenes Ergebnis und ihre eigene Lösung.

Ursache 1: Der Eintrag liegt am falschen Namen

SPF wird an der in der Mail verwendeten Domain abgefragt und nirgendwo sonst. Er wird nicht von einer übergeordneten Domain geerbt und nicht auf www gesucht. Ein Eintrag bei www.example.com nützt nichts für Mails von @example.com, und ein Eintrag bei example.com nützt nichts für Mails von @news.example.com.

Der klassische Fehler passiert in DNS-Oberflächen. Für einen Eintrag am Apex (der reinen Domain ohne Subdomain) lautet das Host-Feld meist @, manche Oberflächen verlangen aber ein leeres Feld oder die vollständige Domain. Lesen Sie den Hinweistext der Oberfläche und prüfen Sie dann per Abfrage, statt dem Formular zu vertrauen.

• Eintrag bei www oder mail: richtiger Text, falscher Host. Verschieben Sie ihn an den Apex, wenn Sie von @example.com senden.
• Doppelte Domain: Eine Oberfläche, die die Zone automatisch anhängt, macht aus example.com den Namen example.com.example.com. Fragen Sie diesen Namen ab, und Sie finden Ihren Eintrag dort.
• Falsche Absenderdomain: Sie haben example.com geprüft, der Envelope-Absender ist aber bounce.example.net oder mail.example.com. Der Empfänger hat diesen Namen angesehen, nicht Ihren.

Ursache 2: Sie prüfen eine andere Domain als die, die die Mail verwendet

Die Adresse, die Leute im From-Header sehen, ist eine Sache. Der Envelope-Absender, den SPF auswertet, kann eine andere sein. Viele E-Mail-Dienstleister nutzen eine eigene Bounce-Domain, manche standardmäßig ihre eigene Domain. Dann wird SPF an diesem Namen ausgewertet, und Ihr eigener Eintrag wird für die Prüfung gar nicht herangezogen.

Der Nachrichten-Header zeigt, welche Domain ausgewertet wurde (siehe unten). Ist es eine Subdomain von Ihnen, braucht diese Subdomain einen eigenen Eintrag, selbst wenn die übergeordnete Domain einen perfekten hat. Eine Subdomain, die nie sendet, kann v=spf1 -all veröffentlichen.

Ursache 3: Der Text ist keine gültige SPF-Zeichenfolge

Das Prüftool ist beim Anfang des Werts streng. Der Text muss mit v=spf1 beginnen, mit Gleichheitszeichen und ohne Leerzeichen darin. Diese knappen Fehlversuche führen alle zu „nicht gefunden“:

• spf1 include:_spf.example.net ~all (das v= fehlt)
• v=spf include:_spf.example.net ~all (die Version muss spf1 lauten)
• v = spf1 ... (Leerzeichen um das Gleichheitszeichen)
• Text mit geschwungenen „intelligenten“ Anführungszeichen, kopiert aus einem Dokument oder Chat

Anführungszeichen verdienen einen Hinweis. Die meisten gehosteten DNS-Oberflächen setzen die geraden doppelten Anführungszeichen für Sie, sodass selbst getippte als Literalzeichen gespeichert werden können. Zeigt eine dig-Antwort zwei Schichten Anführungszeichen, entfernen Sie die selbst getippten.

Ursache 4: Die bearbeitete Zone ist nicht die aktive

Das täuscht selbst erfahrene Leute. Sie können in einer DNS-Oberfläche einen perfekten TXT-Eintrag anlegen und trotzdem im öffentlichen DNS nichts sehen, weil diese Oberfläche nicht die ist, die das Internet abfragt. Der übliche Grund ist die Delegation.

• Registrar versus DNS-Host: Die Domain ist bei einer Firma registriert, ihre Nameserver zeigen aber auf eine andere (ein CDN, einen Hoster, einen separaten DNS-Anbieter). Nur die Zone bei den delegierten Nameservern ist aktiv. Einträge, die auf der DNS-Seite des Registrars oder in einer übrig gebliebenen Zone bei einem früheren Anbieter angelegt wurden, werden ignoriert.

Ermitteln Sie die delegierten Nameserver mit der NS-Abfrage und bearbeiten Sie die Zone genau bei diesem Anbieter. Das erklärt „Ich habe ihn vor einer Stunde angelegt und er ist immer noch nicht da“ oft besser als die Propagierung.

Ursache 5: Veralteter Eintragstyp, Cache oder Zeitverzug

Frühe SPF-Entwürfe nutzten einen eigenen Eintragstyp (Nummer 99, Name SPF). Dieser Typ ist veraltet, und Empfänger werten TXT-Einträge aus; ein nur als Typ SPF veröffentlichter Eintrag ist für moderne Prüfungen daher unsichtbar. Veröffentlichen Sie einen TXT-Eintrag, auch wenn Ihr DNS-Anbieter noch einen SPF-Typ anbietet.

Der Zeitverzug ist der letzte und schwächste Verdächtige. Hat ein Resolver bereits erfahren, dass der Name keinen TXT-Eintrag hat, kann er diese leere Antwort weiter ausliefern, für eine Dauer, die an die Negative-Caching-Einstellungen der Zone gebunden ist. Eine direkte Abfrage beim autoritativen Nameserver beseitigt den Zweifel. Unser Beitrag Wie lange dauert die DNS-Propagierung erklärt die Mechanik.

Prüfen, was das DNS wirklich zurückgibt

Stellen Sie dem DNS vor jeder Änderung dieselbe Frage wie der Empfänger. Unter Linux oder macOS:

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Eine leere Antwort, oder Antworten, die nur Dinge wie Site-Verifizierungs-Token enthalten, bestätigen „nicht gefunden“. Um den Cache Ihres eigenen Resolvers zu umgehen, fragen Sie einen Nameserver direkt: dig TXT example.com @ns1.example.net +short, mit einem Nameserver aus der NS-Abfrage. Liefert das den Eintrag und Ihre normale Abfrage nicht, liegt es am Caching. Liefert keine von beiden ihn, ist der Eintrag nicht in der aktiven Zone.

Der SPF-Checker auf dieser Seite fragt die TXT-Einträge der eingegebenen Domain ab, behält die mit v=spf1 am Anfang und meldet „No SPF record“, wenn er keinen findet. Findet er einen, folgt er außerdem den Includes und zählt die Abfragen. Die TXT-Abfrage zeigt alle TXT-Werte an einem Namen, was hilft, wenn der Eintrag vorhanden, aber fehlerhaft ist, weil Sie den Rohtext sehen.

Den Header einer fehlgeschlagenen Nachricht lesen

Öffnen Sie den Originalquelltext einer zugestellten Nachricht und suchen Sie den vom empfangenden Server hinzugefügten Header Authentication-Results. Der SPF-Teil nennt das Ergebnis und meist die ausgewertete Domain. Die Formulierung variiert je nach Empfänger; verstehen Sie die Beispiele daher als Muster, nicht als exaktes Format.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: kein Eintrag an der ausgewerteten Domain. Nutzen Sie diesen Beitrag.
• spf=fail oder softfail: Ein Eintrag existiert, aber die sendende IP ist nicht autorisiert. Fügen Sie den Absender hinzu oder korrigieren Sie die Richtlinie.
• spf=permerror: Der Eintrag ist defekt, entweder durch zwei Einträge oder zu viele Abfragen.

Notieren Sie die Domain von smtp.mailfrom (oder Return-Path). Diese, nicht die From-Adresse, hat SPF ausgewertet. Wie man Header vollständig liest, steht in So verfolgen Sie den ursprünglichen Absender einer E-Mail.

Einen minimalen, sicheren Eintrag veröffentlichen

Veröffentlichen Sie einen TXT-Eintrag an dem Namen, der im Envelope-Absender verwendet wird. Ein Eintrag ist eine Liste von Mechanismen, die von links nach rechts gelesen wird und mit einem Standardwert für alle anderen endet.

• ip4 / ip6: autorisiert eine Adresse oder einen Bereich, zum Beispiel ip4:203.0.113.25. Kostet keine DNS-Abfrage.
• include: autorisiert, was der SPF-Eintrag einer anderen Domain autorisiert, zum Beispiel include:_spf.example.net. Kostet eine Abfrage.
• a: autorisiert die IP-Adressen im A- (oder AAAA-)Eintrag der Domain selbst. Kostet eine Abfrage.
• mx: autorisiert die in den MX-Einträgen der Domain genannten Hosts. Kostet eine Abfrage; falsch, wenn Ihr eingehender Host nicht der ist, der sendet.
• ~all, -all, ?all: der Standardwert. ~all ist softfail, -all ist fail, ?all ist neutral.

Beginnen Sie mit ~all, während Sie bestätigen, dass jeder Absender aufgeführt ist, und erwägen Sie -all, sobald Sie sicher sind. ?all trifft keine Aussage und ist meist ein Übergang. Eine korrekte Liste ist wichtiger als das Ende, da Empfänger SPF zusammen mit DKIM und DMARC gewichten.

Kurze Hinweise zu gängigen Plattformen

Die Menüs unterscheiden sich und ändern sich, aber die Fehlermuster wiederholen sich. Prüfen Sie diese Punkte bei jeder Art von Einrichtung.

• Microsoft 365 und Google Workspace: Beide stellen ein Include bereit, das Sie aus der Admin-Konsole oder der Einrichtungsanleitung kopieren. Ein „nicht gefunden“ bedeutet dort meist, dass der Eintrag beim falschen DNS-Anbieter oder am falschen Host gelandet ist.
• GoDaddy und andere Registrare: Wurden die Nameserver auf ein CDN oder einen Hoster umgestellt, ist die DNS-Seite des Registrars nicht mehr autoritativ. Bearbeiten Sie die Einträge bei dem Anbieter, den die NS-Abfrage zeigt.
• Cloudflare: Nutzt die Domain Cloudflare-Nameserver, legen Sie den TXT-Eintrag im DNS-Tab von Cloudflare an.

Was Empfänger tun, wenn es keinen SPF gibt

SPF none ist keine automatische Ablehnung. Der Standard überlässt die Entscheidung der lokalen Richtlinie des Empfängers, daher fallen die Ergebnisse unterschiedlich aus. Mail ohne SPF und ohne DKIM oder DMARC als Ausgleich wirkt eher verdächtig, und einige Anbieter veröffentlichen Authentifizierungsanforderungen für Massenversender. Prüfen Sie die aktuellen Regeln der Anbieter, an die Sie senden.

SPF prüft den Envelope-Absender und verhindert daher allein nicht, dass jemand Ihre sichtbare From-Adresse fälscht; das ist die Aufgabe von DMARC. Siehe SPF, DKIM und DMARC erklärt und So prüfen Sie einen SPF-Eintrag.