SPF fehlgeschlagen: Ursachen und Lösungen

Was bedeutet „SPF fehlgeschlagen“ (SPF failed)?

Mit SPF (Sender Policy Framework) veröffentlicht der Inhaber einer Domain einen DNS-TXT-Eintrag, der die Hosts auflistet, die für diese Domain E-Mails versenden dürfen. Kommt Ihre Nachricht an, nimmt der empfangende Server die IP-Adresse der Verbindung und fragt den SPF-Eintrag der Domain ab, die im SMTP-Befehl MAIL FROM angegeben ist (und später in den Return-Path-Header geschrieben wird). Danach arbeitet er die Mechanismen des Eintrags von links nach rechts ab. Passt die IP zu einem davon, lautet das Ergebnis pass. Passt nichts, entscheidet der Qualifier vor dem abschließenden „all“: -all ergibt fail, ~all ergibt softfail.

Ein Detail lassen die meisten Anleitungen weg: SPF schaut sich die sichtbare Absenderadresse im From-Feld nie an. Eine Nachricht kann Ihre Domain im From zeigen und trotzdem gegen den Eintrag einer anderen Domain geprüft werden, etwa gegen die Bounce-Domain Ihres E-Mail-Dienstes. Bevor Sie also irgendetwas im DNS ändern, finden Sie heraus, welche Domain tatsächlich geprüft wurde. Umgangssprachlich heißt jedes Ergebnis außer pass „SPF failed“ oder „SPF fehlgeschlagen“. In Bounce-Nachrichten taucht das oft als Ablehnung mit 550 5.7.1 und „SPF fail“ im Text auf. Der Artikel von Mailtester.com zu SPF-Fehlern vom Oktober 2026 beschreibt diesen Code als direktes Zeichen dafür, dass die Authentifizierung gescheitert ist.

SPF-Ergebnisse: none, neutral, softfail, fail, temperror, permerror

Ergebnis	Was das Ergebnis bedeutet	Typische Ursache	Was zu tun ist
pass	Die IP ist für die geprüfte Domain autorisiert	Die IP passte zu einem IP-Adress-, a-, mx- oder include-Mechanismus	Für SPF nichts, aber das DMARC-Alignment trotzdem prüfen
none	Für die geprüfte Domain wurde kein SPF-Eintrag gefunden	Es gibt keinen TXT-Eintrag mit v=spf1, oder er liegt auf dem falschen Host bzw. der falschen Subdomain	Einen Eintrag auf genau der Domain veröffentlichen, die in MAIL FROM steht
neutral	Die Domain macht zu dieser IP keine Aussage	Der Eintrag endet auf ?all	?all durch ~all oder -all ersetzen, sobald alle Absender eingetragen sind
softfail	Die IP ist wahrscheinlich nicht autorisiert	Die IP ist nicht aufgeführt und der Eintrag endet auf ~all	Das fehlende include oder die fehlende IP des Absenders ergänzen
fail	Die IP ist ausdrücklich nicht autorisiert	Die IP ist nicht aufgeführt und der Eintrag endet auf -all	Den fehlenden Absender ergänzen oder herausfinden, wer Ihre Domain nutzt
temperror	Während der Prüfung trat ein vorübergehender DNS-Fehler auf	Ein DNS-Timeout oder ein nicht erreichbarer Nameserver	Die Nameserver prüfen. Der Empfänger versucht es eventuell erneut
permerror	Der Eintrag lässt sich nicht auswerten	Zwei SPF-Einträge, ein Syntaxfehler oder zu viele DNS-Lookups	Den Eintrag zusammenführen, korrigieren oder flatten

Warum schlägt SPF fehl?

• Ein neuer Versanddienst fehlt im Eintrag. Sie haben ein CRM, ein Helpdesk oder einen E-Mail-Dienst angebunden, aber dessen include nie ergänzt, also passen dessen IPs nicht.
• Auf einer Domain liegen zwei SPF-Einträge. Eine Domain darf nur einen TXT-Eintrag mit v=spf1 haben. Bei zweien liefert die Prüfung permerror, selbst wenn jeder Eintrag für sich korrekt ist. Das passiert meist, wenn die Einrichtungsanleitung eines zweiten Dienstes sagt, man solle einen Eintrag „hinzufügen“, statt ihn in den bestehenden einzuarbeiten.
• Der Eintrag braucht zu viele DNS-Lookups. Der SPF-Leitfaden von Valimail und der Leitfaden von PowerDMARC zu SPF-Authentifizierungsfehlern nennen beide ein Limit von 10 DNS-Lookups pro Prüfung, verschachtelte includes eingeschlossen. includes, a, mx und redirects zählen mit, reine IP-Adressen nicht. Wer das Limit überschreitet, bekommt permerror.
• includes verweisen auf tote Domains. Ein include, dessen Domain nicht mehr existiert, liefert keine Antwort. Das kostet trotzdem einen Lookup, und Empfänger tolerieren nur wenige leere Lookups, bevor sie die Prüfung abbrechen.
• Syntaxfehler, zum Beispiel ein fehlendes v=spf1 am Anfang, ein Leerzeichen nach „include:“, ein fehlerhafter IP-Bereich oder Text, der mit typografischen Anführungszeichen eingefügt wurde.
• Der Eintrag liegt auf dem falschen Host. SPF wird nicht vererbt. Nutzt Ihr Dienst bounce.example.com als MAIL-FROM-Domain, wird der Eintrag auf example.com nie geprüft.
• Weiterleitungen und Mailinglisten. Ein Forwarder stellt Ihre Nachricht von seiner eigenen IP zu, die Ihr Eintrag nicht enthält, also schlägt SPF beim endgültigen Empfänger fehl. Nur DKIM übersteht eine Weiterleitung, die die Nachricht nicht verändert.
• DNS-Probleme während der Abfrage, die zu temperror führen. Ein Thread in Microsoft Q&A vom Oktober 2024 beschreibt temperror-Ergebnisse, die nur beim Versand an Outlook-Empfänger in Unternehmen auftraten.

SPF und DKIM prüfen: So gehen Sie vor

1. 1 Schicken Sie eine Testnachricht an ein Postfach, auf das Sie Zugriff haben, und öffnen Sie den Quelltext. In Gmail zeigt „Original anzeigen“ ganz oben die Ergebnisse für SPF, DKIM und DMARC.
2. 2 Suchen Sie den Header Authentication-Results. Notieren Sie spf= und smtp.mailfrom= (die Domain, die SPF tatsächlich geprüft hat), dann dkim= und header.d= (die Domain, die die Nachricht signiert hat).
3. 3 Fragen Sie den SPF-Eintrag mit dig TXT example.com +short ab. Zählen Sie die Antworten, die mit v=spf1 beginnen. Sind es mehr als eine, haben Sie die Ursache für Ihren permerror.
4. 4 Fragen Sie DKIM ab. Nehmen Sie den Wert s= (den Selector) aus dem Header DKIM-Signature und führen Sie dig TXT selector._domainkey.example.com +short aus. Eine leere Antwort bedeutet, dass unter diesem Host kein öffentlicher Schlüssel veröffentlicht ist.
5. 5 Vergleichen Sie beide Domains mit Ihrer From-Domain. DMARC verlangt, dass mindestens eine davon zu ihr passt.
6. 6 Zählen Sie die Lookups. Check MX in der Google Admin Toolbox und der SPF-Lookup von MxToolbox lösen beide verschachtelte includes auf. Beide lesen das öffentliche DNS, ein Eintrag, den Sie vor ein paar Minuten geändert haben, ist dort also eventuell noch nicht sichtbar. Das hängt von der TTL des Eintrags ab.

Eine ausführlichere Erklärung aller drei Einträge aus Sicht von Cold-Outreach-Versendern finden Sie in unserem Leitfaden zu SPF, DKIM und DMARC für Cold E-Mails.

Wie lautet Googles SPF-Eintrag für Workspace, G Suite und Gmail?

Die Admin-Hilfe von Google Workspace zur SPF-Fehlerbehebung nennt für Domains, die über Google senden, genau einen Wert: einen TXT-Eintrag auf der Stammdomain mit dem Inhalt v=spf1 include:_spf.google.com ~all. Jede Zeile der Tabelle unten beantwortet eine Variante dieser Frage. Die vollständige DNS-Einrichtung inklusive MX-Einträgen steht in unserem Artikel zu den DNS-Einträgen für Google Workspace: MX, SPF und DKIM.

Frage	Antwort
SPF-Eintrag für Google Workspace	Ein TXT-Eintrag auf Ihrer Stammdomain: v=spf1 include:_spf.google.com ~all. Senden weitere Dienste für dieselbe Domain, ergänzen Sie deren includes in genau diesem Eintrag, vor ~all. Veröffentlichen Sie keinen zweiten Eintrag.
SPF-Eintrag für G Suite	G Suite ist der frühere Name von Google Workspace, der Eintrag ist unverändert: v=spf1 include:_spf.google.com ~all. Einrichtungsanleitungen, die noch von G Suite sprechen, gelten weiterhin.
SPF-Eintrag für Gmail	Für eine private Gmail-Adresse können Sie SPF weder veröffentlichen noch ändern, weil Google das DNS von gmail.com verwaltet. E-Mails, die eine Gmail-Adresse im From zeigen, aber über die Server eines anderen Dienstes rausgehen, sind nicht auf gmail.com aligned. Outreach sollte von einer Domain aus versendet werden, die Ihnen gehört.
Google-SPF-Einträge: einer oder mehrere?	Einer. Googles include enthält weitere includes, und jedes davon zählt zum Lookup-Limit. Prüfen Sie die Gesamtzahl, nachdem Sie weitere Dienste ergänzt haben.
SPF- und DKIM-Einträge bei Google	SPF gehört in den oben genannten TXT-Eintrag auf der Stammdomain. DKIM erzeugen Sie in der Admin-Konsole unter Apps > Google Workspace > Gmail > E-Mails authentifizieren, veröffentlichen es als TXT-Eintrag unter google._domainkey (dem Standard-Selector) und aktivieren es anschließend mit Authentifizierung starten.

Signiert auch Brevo E-Mails für dieselbe Domain, zeigt unsere Anleitung zur DKIM-Einrichtung für G Suite, wie Sie die Schlüssel von Google und die von Brevo sauber auseinanderhalten.

Was passiert ohne SPF-Eintrag?

Ohne Eintrag lautet das SPF-Ergebnis none. Das ist für sich genommen keine Ablehnung, denn was damit passiert, entscheidet der empfangende Server. Große Postfachanbieter erwarten heute aber authentifizierte E-Mails. Googles Absenderrichtlinien für Gmail verlangen von jedem Absender SPF oder DKIM, von Bulk-Versendern beides plus DMARC. Ohne SPF hat Ihre Domain außerdem keine veröffentlichte Liste erlaubter Absender, Empfänger können eine gefälschte Nachricht also gegen nichts prüfen. Ein Eintrag ist in wenigen Minuten angelegt. Veröffentlichen Sie nur kein -all, bevor alle legitimen Absender eingetragen sind, sonst schlagen Ihre eigenen E-Mails fehl. Der Hard-Fail-Leitfaden von Sendmarc vom September 2026 beschreibt die Reihenfolge in drei Schritten: Absender erfassen, schrittweise ausrollen, dann durchsetzen.

Was bedeutet DMARC fail, wenn SPF fehlschlägt?

DMARC besteht, wenn SPF oder DKIM besteht und die bestehende Domain zur Domain im sichtbaren From-Header passt (Alignment). Ein SPF fail bedeutet also nicht automatisch ein DMARC fail, denn eine passende DKIM-Signatur reicht aus. Auch der umgekehrte Fall überrascht viele: SPF kann auf der Bounce-Domain Ihres E-Mail-Dienstes bestehen, während DMARC fehlschlägt, weil diese Domain nicht Ihre ist. Ein DMARC fail heißt, dass keine der beiden Prüfungen ein aligned pass ergeben hat. Was dann passiert, hängt von Ihrer Policy ab: p=none meldet nur, p=quarantine und p=reject sagen dem Empfänger, wie er mit der Nachricht umgehen soll. Unsere Anleitung zur DMARC-Einrichtung erklärt den Eintrag, seine Tags und die Aggregate Reports, die zeigen, welche Quellen fehlschlagen.

SPF fehlgeschlagen beheben: Schritt für Schritt

1. 1 Lesen Sie zuerst den Header. Notieren Sie das Ergebnis und die smtp.mailfrom-Domain. Eine Korrektur an der falschen Domain ändert nichts.
2. 2 Listen Sie jeden Dienst auf, der mit Ihrer Domain versendet: Ihren Postfachanbieter, Brevo, Rechnungsversand, Helpdesk, CRM.
3. 3 Führen Sie alle in einem TXT-Eintrag pro Domain zusammen: v=spf1, dann die includes und IPs, am Ende ein einziger all-Mechanismus.
4. 4 Zählen Sie die Lookups. Liegen Sie über dem Limit, entfernen Sie Dienste, die Sie nicht mehr nutzen, oder ersetzen Sie ein include durch die IP-Bereiche, die der Dienst dokumentiert. Geflattete Bereiche müssen Sie jedes Mal neu prüfen, wenn der Anbieter seine IPs ändert.
5. 5 Beginnen Sie mit ~all. Wechseln Sie erst zu -all, wenn Ihre DMARC-Reports zeigen, dass keine legitime Quelle mehr fehlschlägt.
6. 6 Prüfen Sie DKIM zusammen mit SPF. DKIM übersteht Weiterleitungen und ist der übliche Weg zum DMARC-Alignment, wenn Ihr E-Mail-Dienst eine eigene Bounce-Domain nutzt.
7. 7 Sobald die TTL des Eintrags abgelaufen ist, schicken Sie eine neue Testnachricht.

Wie EmailFlow OS versendet und was das für SPF bedeutet

Mit EmailFlow OS nehmen Sie ein einziges Video auf und laden es hoch, verbinden Ihr eigenes Brevo-Konto und Ihre Versanddomain und importieren Ihre Prospect-Liste in EmailFlow OS. EmailFlow OS erstellt dann aus dieser einen Aufnahme für jeden Empfänger eine eigene personalisierte Version, nicht nur eine pro Unternehmen, und versendet jede davon aus Ihrem eigenen Postfach, über Ihr Brevo-Konto und Ihre Domain. Ein gemeinsamer Plattform-Absender steht nicht dazwischen. Die SPF-, DKIM- und DMARC-Ergebnisse, die ein Empfänger festhält, gehören also zu Ihrer Domain und Ihrem Brevo-Setup, und die DNS-Einträge bleiben unter Ihrer Kontrolle. Das heißt auch: Ein SPF-Fehler ist Ihrer und wird in Ihrem eigenen DNS behoben. Wo eine Nachricht landet, entscheidet der empfangende Server, nicht EmailFlow OS. Auf der Startseite von EmailFlow OS zu personalisierten Video-E-Mails sehen Sie, wie die Versandseite zusammenspielt.

Vor dem ersten Versand können Sie Ihre Domain durch den SPF DKIM DMARC Checker laufen lassen, ein Tool von EmailFlow OS. Er liest Ihre veröffentlichten Einträge aus, sodass ein doppelter SPF-Eintrag oder ein fehlender DKIM-Schlüssel früh auffällt.

Häufige Fragen

? Sollte ich im SPF-Eintrag -all oder ~all verwenden?

Mit -all bekommen nicht aufgeführte IPs fail, mit ~all softfail. DMARC wertet beides als SPF-Nicht-Pass, der Unterschied zählt also vor allem bei Empfängern, die allein auf SPF reagieren. Nutzen Sie ~all, solange Sie noch dabei sind, alle Absender zu erfassen. Wechseln Sie zu -all, sobald Ihre DMARC Aggregate Reports zeigen, dass jede legitime Quelle besteht.

? Darf eine Domain zwei SPF-Einträge haben?

Nein. Die SPF-Spezifikation erlaubt pro Domainname nur einen TXT-Eintrag mit v=spf1. Ein zweiter lässt die gesamte Prüfung mit permerror enden, was die meisten Empfänger als Fehlschlag werten. Führen Sie die includes in einem Eintrag zusammen. Eine Subdomain wie mail.example.com gilt als eigener Name und kann einen eigenen Eintrag haben.

? Warum schlägt SPF fehl, obwohl die sendende IP in meinem include steht?

Meist gibt es drei mögliche Gründe. Die Zahl der Lookups liegt über dem Limit, sodass die Prüfung mit permerror abbricht, bevor sie Ihr include erreicht. Oder die geprüfte Domain ist nicht die mit dem include, weil MAIL FROM eine Subdomain oder die Bounce-Domain des Dienstes verwendet hat. Oder es gibt einen zweiten SPF-Eintrag. Welcher Fall vorliegt, verrät der Header Authentication-Results.

? Übersteht SPF eine E-Mail-Weiterleitung?

In der Regel nicht. Ein Forwarder versendet Ihre Nachricht von seiner eigenen IP-Adresse, die nicht in Ihrem SPF-Eintrag steht, also sieht der endgültige Empfänger fail oder softfail. Eine DKIM-Signatur übersteht die Weiterleitung, solange der Forwarder die signierten Header und den Inhalt unverändert lässt. Deshalb ist eine passende DKIM-Signatur für DMARC so wichtig.