Die 6 häufigsten SPF-Fehler und wie Sie sie beheben

Ihre E-Mails sind authentifiziert, Ihr DNS sieht sauber aus, und Ihre Zustellbarkeit ist solide. Und dann, eines Tages, geht eine neue Marketingplattform live, jemand ändert einen DNS-Eintrag – und plötzlich landet die Hälfte Ihrer E-Mails im Spam. Kommt Ihnen das bekannt vor?

SPF-Fehler (Sender Policy Framework) sind eines der häufigsten E-Mail-Authentifizierungsprobleme, die wir bei den über 1.200 Organisationen sehen, die Red Sift OnDMARC einsetzen. Und im Jahr 2026 – mit den neuen Authentifizierungsvorgaben von Google, Yahoo und Microsoft für Massensender – führt ein defekter SPF-Eintrag nicht nur zu Zustellbarkeitsproblemen. Die Kommunikation mit Ihren Kunden wird komplett unterbrochen.

SPF ist eines von drei Kernprotokollen zur E-Mail-Authentifizierung, neben DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting, and Conformance). Über einen DNS-TXT-Eintrag wird veröffentlicht, welche IP-Adressen und Server berechtigt sind, E-Mails für Ihre Domain zu versenden. Wenn ein empfangender Mailserver eine Nachricht erhält, prüft er die sendende IP-Adresse gegen Ihren SPF-Eintrag. Gibt es keine Übereinstimmung, schlägt die Authentifizierung fehl.

Warum das jetzt besonders zählt: Seit Februar 2024 fordern Google und Yahoo von allen Massensendern (über 5.000 Nachrichten täglich) eine Authentifizierung per SPF und DKIM sowie die Veröffentlichung eines DMARC-Eintrags [1]. Microsoft folgte im Mai 2025 mit denselben Anforderungen für Outlook.com-, Hotmail.com- und Live.com-Adressen [2]. Zusammengenommen verarbeiten diese drei Anbieter etwa 90 % der typischen B2C-E-Mail-Listen. Ein defekter SPF-Eintrag kann die Zustellung an die überwiegende Mehrheit Ihrer Empfänger über Nacht blockieren.

Und es geht nicht nur um Zustellbarkeit: Im Internet Crime Report 2024 des FBI wurden 193.407 Phishing- und Spoofing-Fälle registriert – das häufigste Cybercrime-Segment. Die Gesamtschäden durch Internetkriminalität beliefen sich auf 16,6 Milliarden US-Dollar, ein Anstieg um 33 % gegenüber 2023 [3]. Allein Business E-Mail Compromise (BEC) verursachte Verluste von 2,77 Milliarden US-Dollar bei 21.442 Vorfällen [4]. Korrekt konfigurierte E-Mail-Authentifizierung – beginnend mit SPF – ist Ihre erste Verteidigungslinie gegen Domain-Imitation.

Nicht nur Postfachanbieter erhöhen den Druck: PCI DSS v4.0.1 schreibt ab März 2025 DMARC auf Quarantäne- oder Reject-Level für Unternehmen mit Kartenzahlungsabwicklung verpflichtend vor [5]. Die US-Richtlinie CISA BOD 18-01 fordert p=reject für US-Bundesdomains. Die britische NCSC, Australiens ASD und Kanadas CCCS schreiben DMARC ebenfalls für Regierungsdomains vor. Auch Cyber-Versicherer verlangen DMARC-Vollzug zunehmend als Voraussetzung für Policen. Einen vollständigen Überblick finden Sie in unserer Weltkarte der DMARC-Verpflichtungen und Leitlinien.

Fazit: SPF-Fehler im Jahr 2026 sind kein kleiner Stolperstein. Sie sind ein Problem für Zustellbarkeit, Compliance und Sicherheit zugleich.

Sehen wir uns die sechs häufigsten SPF-Fehler an – und wie Sie sie jeweils beheben.

Wie das aussieht: E-Mails von einem legitimen Versanddienst (CRM, Helpdesk-Tool oder HRP/ERP-System) scheitern an SPF, weil deren IP-Adressen nicht im SPF-Eintrag gelistet sind.

Warum das passiert: Das ist der häufigste SPF-Fehler und hat fast immer einen Grund: Jemand richtet einen neuen Versanddienst ein und vergisst, den DNS-Eintrag zu aktualisieren. Das Support-Team nutzt Zendesk für Kundenkommunikation, das Technik-Team integriert ein ERP für Transaktionsmails – und beide verwenden die Domain, ohne im SPF explizit autorisiert zu sein.

Mit der Zeit wächst das Problem: Unternehmen übernehmen andere Firmen mit unterschiedlichen Versandsystemen. Anbieter wechseln ihre IP-Adressen ohne Rückmeldung. Ein Testzugang für einen E-Mail-Service wird produktiv geschaltet, aber das DNS-Team wird nicht informiert. Besonders in Unternehmen mit Salesforce, SAP oder Zendesk neben der eigenen Infrastruktur ergeben sich schnell Lücken.

So beheben Sie das:

Starten Sie mit einem Audit aller Services, die E-Mails über Ihre Domain versenden. Schauen Sie in Ihre DMARC-Aggregatberichte – sie geben an, welche IPs in Ihrem Namen versenden und ob sie SPF bestehen oder nicht. Mit Red Sift OnDMARC erkennt die Plattform nicht autorisierte Absender automatisch und schlägt Maßnahmen vor.

Sobald alle legitimen Versandquellen feststehen, fügen Sie deren SPF-Mechanismen in Ihr SPF-Record ein. Jeder Anbieter stellt einen eigenen include-Mechanismus bereit, etwa include:spf.protection.outlook.com für Microsoft 365 oder include:_spf.google.com für Google Workspace.

Praxistipp: Sie nutzen Google Workspace und Zendesk? Dann sollte Ihr SPF-Eintrag so aussehen:

v=spf1 include:_spf.google.com include:mail.zendesk.com ~all

Profitipp: Planen Sie ein SPF-Audit pro Quartal ein. Aktualisieren Sie den DNS-Eintrag bei jedem neuen oder abgeschalteten Anbieter. DMARC-Berichte zeigen direkt, wer sendet und was fehlschlägt. Entfernen Sie auch SPF-Records, die aus Alignment-Gründen nicht mehr vorhanden sein sollten (mehr dazu weiter unten)!

Wie das aussieht: Ihr SPF-Record liefert einen PermError (permanenter Fehler) zurück und jede E-Mail Ihrer Domain besteht SPF nicht mehr. Wirklich jede, nicht nur einzelne.

Warum das passiert: RFC 7208 (die SPF-Spezifikation) begrenzt die SPF-Prüfung auf 10 DNS-Lookups pro Überprüfung [6]. Die Mechanismen include, a, mx und exists sowie der Modifier redirect zählen jeweils als ein Lookup. Die Mechanismen ip4 und ip6 werden nicht berücksichtigt, da sie statische Werte enthalten und keine weiteren DNS-Abfragen benötigen.

Das Limit ist schnell erreicht: Microsoft 365 benötigt zwei Lookups, Google Workspace vier, dazu etwa SendGrid (1), Salesforce (2), und schon mit einigen Anbietern sind Sie über dem Limit. Jedes include kann wiederum weitere include-Befehle enthalten – auch diese werden gezählt. Insgesamt dürfen es höchstens 10 DNS-Abfragen (einschließlich aller verschachtelten includes) sein.

Sind es mehr als 10 und ist die IP nach dem 11. Lookup immer noch nicht gefunden, meldet der empfangende Mailserver PermError und bricht ab. DMARC bewertet das als SPF fail [7]. Ihre Mails werden abgelehnt oder landen im Spam. Ohne konfigurierte DKIM-Signatur hilft dann auch DKIM oft nicht weiter.

Received-SPF: permerror (yourdomain.com: too many DNS lookups)
  client-ip=203.0.113.45;
  envelope-from=noreply@yourdomain.com;
  helo=mail.yourdomain.com;

So lesen Sie das: permerror bestätigt, dass der empfangende Server das 10-Lookup-Limit erreicht hat, bevor er einen autorisierten Absender gefunden hat – nicht, dass der Sender wirklich unautorisiert war. Die Begründung gibt den Grund in verständlichem Englisch an. client-ip und envelope-from sind die beiden Felder, die Sie jetzt mit Ihrem SPF-Record abgleichen sollten, um herauszufinden, welche include-Kette für das Limit verantwortlich ist.

Es gibt noch ein weniger bekanntes Limit: die 2-Void-Lookup-Regel. Sobald bei der SPF-Auswertung zwei DNS-Abfragen NXDOMAIN (Domain existiert nicht mehr) oder leere Antworten liefern, löst ein dritter void lookup einen PermError aus [8]. Das passiert etwa, wenn ein include auf einen Anbieter verweist, dessen SPF-Eintrag nicht mehr existiert (z. B. nach dessen Abschaltung).

So beheben Sie das:

Zählen Sie zuerst die aktuellen Lookups. Mit Red Sift Investigate prüfen Sie, wie viele DNS-Anfragen Ihr SPF-Record wirklich auslöst.

So reduzieren Sie die Zahl der Lookups:

• Nicht mehr genutzte Dienste entfernen. Wurde das Mailchimp-Konto gekündigt, aber das include steht noch im Record? Löschen Sie es! Ältere CRM-Systeme, Testaccounts und includes von ehemaligen Mitarbeitenden sind Klassiker.
• ptr-Mechanismen entfernen.ptr-Mechanismen entfernen. Die SPF-Spezifikation rät dringend davon ab – sie sind veraltet und verschwenden Lookups.
• Sendequellen auf Subdomains auslagern. Jede Subdomain bekommt ihren eigenen SPF-Record mit je 10 Lookup-Budget. Leiten Sie z. B. den Marketing-Mailversand über info.yourdomain.com und einen eigenen Eintrag – das verschlankt den Record auf der Hauptdomain.

Können Sie die Zahl der Lookups nicht manuell unter 10 bringen, löst Dynamic SPF von Red Sift OnDMARC das Problem automatisch: Ihr komplizierter SPF-Record wird durch ein einziges smartes include ersetzt, das jeweils nur auf aktuell sendende IPs auflöst. Die Verwaltung der Sendequellen erfolgt dann im OnDMARC-Portal und das Lookup-Limit bleibt immer eingehalten.

Wie das aussieht: SPF scheitert für alle E-Mails, oder der Record wird gar nicht erst als SPF erkannt. In DMARC-Reports erscheinen PermError oder None.

Warum das passiert: SPF-Einträge folgen strengen Formatregeln gemäß RFC 7208. Schon kleine Tippfehler machen den gesamten Eintrag ungültig. Häufige Syntaxfehler sind:

• Fehlendes oder falsches Versionstags. Jeder SPF-Eintrag muss mit v=spf1 beginnen. Tippfehler wie v=spf2 oder v=spf11 (oder ein Leerzeichen davor) machen alles zunichte.
• Fehlende Leerzeichen zwischen Mechanismen. Jeder Mechanismus muss mit einem Leerzeichen getrennt werden. Zum Beispiel include:_spf.google.cominclude:mail.zendesk.com (ohne Leerzeichen) zerstört die Auswertung.
• Falsches Mechanismen-Format. Die Mechanismen ip4 und ip6 erfordern einen Doppelpunkt vor dem Wert (ip4:192.168.1.1), kein Gleichheitszeichen oder Schrägstrich.
• Vertipper bei Mechanismen. incldue statt include oder ipv4 statt ip4 – beide Fehler machen das Element ungültig.
• Nutzung des veralteten ptr-Mechanismus.ptr-Mechanismus. Auch wenn technisch noch zulässig: ptr ist veraltet, von RFC 7208 explizit nicht empfohlen und verursacht unnötige DNS-Last.

Solche Fehler betreffen immer 100 % Ihrer E-Mails. Der empfangende Server stoppt mit PermError (bei teilweiser Verarbeitung) oder None (wenn der Record komplett ungültig ist).

So beheben Sie das:

Validieren Sie jeden SPF-Record, bevor Sie Änderungen veröffentlichen. Red Sift Investigate prüft auf Syntaxfehler, Lookup-Anzahl und andere Fehlkonfigurationen in Sekundenschnelle.

So sieht ein sauberer SPF-Eintrag aus:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Beachten Sie: v=spf1 am Anfang, Leerzeichen zwischen jedem Mechanismus, Doppelpunkte (keine Gleichheitszeichen) bei ip4, und ein einziges ~all am Schluss. Validieren Sie nach jeder Änderung, warten Sie ggf. bis zu 24 Stunden auf die DNS-Ausbreitung und prüfen Sie dann DMARC-Berichte auf unerwartete Fehler.

Wie das aussieht: SPF ergibt PermError und jede Authentifizierung über SPF schlägt fehl. Das ist ein Totalausfall, keine Teilstörung.

Warum das passiert: Die SPF-Spezifikation erlaubt pro Domain genau einen SPF-TXT-Eintrag [6]. Wenn es mehrere gibt, weiß der empfangende Server nicht, welchen er auswerten soll, und meldet PermError.

Oft liegt das daran, dass verschiedene Teams mit unterschiedlichen Tools SPF-Einträge anlegen: Die IT-Abteilung für Microsoft 365, das Marketing-Team für dessen Plattform, ein externer Berater für ein Deliverability-Projekt – und niemand prüft, ob bereits ein Eintrag existiert. So entstehen schnell drei SPF-Einträge, die gemeinsam nutzlos sind.

$ dig yourdomain.com TXT +short

"v=spf1 include:spf.protection.outlook.com ~all"
"v=spf1 include:_spf.google.com ~all"

So lesen Sie das: zwei Ketten, die jeweils mit v=spf1 beginnen. Der empfangende Server kann keinen auswählen – daher werden beide verworfen und PermError gemeldet. Das Ergebnis ist dasselbe wie bei zu vielen Lookups oben, hat aber die entgegengesetzte Ursache: zu viele Records statt zu vieler Lookups. Die Lösung ist das Zusammenführen zu einem einzigen Record (siehe weiter unten) und die Prüfung mittels dig-Befehl, dass wirklich nur noch ein v=spf1 im DNS steht.

Auch bei Migrationen tritt das auf: Sie wechseln von Google Workspace zu Microsoft 365 und vergessen, den alten Google-SPF-Record zu entfernen, wenn der neue veröffentlicht wird – und schon haben Sie zwei Einträge und eine defekte Konfiguration.

So beheben Sie das:

Prüfen Sie alle TXT-Records Ihrer Domain, die mit v=spf1 beginnen. Es darf nur einer existieren. Falls mehrere, führen Sie alle autorisierten Sendequellen in einem einzigen Record zusammen.

Beispiel:

Eintrag 1: v=spf1 include:spf.protection.outlook.com ~all Eintrag 2: v=spf1 include:_spf.google.com ~all

Merge zu:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

Löschen Sie dann die doppelten Einträge. Nach dem Zusammenführen validieren Sie, ob das Lookup-Limit noch eingehalten wird. Zentralisieren Sie das DNS-Management und fordern Sie Freigaben für Änderungen, um dies künftig zu vermeiden. Müssen mehrere Teams E-Mail-Infrastruktur steuern, nutzen Sie ein zentrales Tool wie Red Sift OnDMARC zur Verwaltung aller Quellen über eine Plattform.

Wie das aussieht: E-Mails bestehen SPF beim Direktversand, fallen aber durch, wenn sie weitergeleitet oder über Verteilerlisten zugestellt werden. Ihre DMARC-Berichte zeigen SPF-Fehler von IP-Adressen bekannter Weiterleiter (Unis, ISPs, Firmen-Mailserver).

Warum das passiert: Das ist eine grundsätzliche Einschränkung des SPF-Prinzips und der einzige Fehler auf dieser Liste, der nicht durch Fehlkonfiguration entsteht.

SPF prüft, ob die Absender-IP durch die Domain autorisiert ist. Wird eine Mail weitergeleitet, wird die Absender-IP durch die des Weiterleiters ersetzt. Der finale Server prüft diese gegen den SPF-Record – und findet keinen Treffer, weil die Weiterleitungs-IP nicht autorisiert ist. SPF schlägt fehl.

Mailinglisten verschärfen das Problem, da sie oft den Inhalt verändern (Footer, Header, Abmeldelinks etc.) und dadurch auch DKIM-Signaturen zerstören. Versagen SPF und DKIM gemeinsam, scheitert DMARC.

Das ist by Design: SPF funktioniert nur für direkte Versandwege, für Zwischenschritte ist das Protokoll nicht gedacht.

So beheben Sie das:

SPF für weitergeleitete E-Mails kann man technisch nicht „reparieren“, wohl aber Absicherung schaffen:

• Setzen Sie auf DKIM als Rückfall-Authentifizierung. DKIM ist inhaltsbasiert, nicht pfadbasiert: Bleibt der Mail-Inhalt beim Weiterleiten unverändert, bleibt die DKIM-Signatur gültig und DMARC besteht. Alle Versandservices Ihrer Domain sollten DKIM nutzen. Einen vollständigen Leitfaden finden Sie im Protokoll-Guide. Unser Konfigurations-Guide für E-Mail-Protokolle behandelt auch DKIM-Key-Verwaltung, Selector-Einrichtung und Fehlerdiagnose im Detail.
• Nutzen Sie ~all (Soft Fail), nicht -all (Hard Fail). Einige empfangende Server bewerten SPF vor DMARC. Mit -all wird die E-Mail dann schon auf SMTP-Ebene abgelehnt, bevor DKIM oder DMARC geprüft werden. Soft Fail lässt sie erst zur DMARC-Analyse durch, bei gültigem DKIM kann die Zustellung so trotzdem gelingen. Die aktuelle Praxis (2026) empfiehlt ~all für aktive Versenderdomains [9]. In Verbindung mit DMARC bei p=reject wird trotzdem konsequent abgelehnt, aber möglichst spät im Prozess.
• ARC (Authenticated Received Chain) verstehen. ARC ermöglicht es Weiterleitern, die ursprünglichen Authentifizierungsergebnisse „mitzusenden“. Große Anbieter wie Gmail oder Microsoft 365 integrieren dies automatisch; eine eigene Konfiguration ist nicht nötig [10].

Hinweis: Die IETF hat die offizielle Abschaffung von ARC beschlossen. DKIM2 wird voraussichtlich nachfolgen.DKIM2 wird voraussichtlich nachfolgen.

• Überwachen Sie Weiterleitungs-Fehler in DMARC-Berichten. Unterscheiden Sie Weiterleitung zuverlässig von Missbrauch. Weiterleitungen stammen meist von bekannten Servern und zeigen „SPF fail, DKIM pass“. Spoofing kommt von fremden IPs mit SPF UND DKIM fail.

Wie das aussieht: SPF besteht (die Absender-IP ist autorisiert), aber DMARC schlägt dennoch fehl. Das sorgt oft für Verwirrung, weil viele annehmen, SPF pass bedeutet automatisch DMARC pass. Stimmt nicht. Für ein tieferes Verständnis, wie SPF, DKIM und DMARC zusammenwirken, ist dieser Unterschied entscheidend.

Warum das passiert: DMARC fordert Alignment zwischen der Domain, die die Authentifizierung besteht, und der Domain in der Sichtbaren From-Adresse. Für SPF heißt das: Die Domain im Return-Path (auch Envelope From oder MAIL FROM genannt) muss mit der sichtbaren From-Domain übereinstimmen oder eine Subdomain davon sein.

Viele Drittanbieter nutzen aber für den Return-Path standardmäßig ihre eigene Domain. Beispiel Salesforce: Ohne explizite Konfiguration landet der Rückweg auf deren Domain. SPF prüft den Return-Path, findet die richtige IP in der Salesforce-SPF, und SPF ist bestanden. Jetzt folgt DMARC: „Stimmt Return-Path mit sichtbarer From-Adresse überein?“ Steht im From @yourdomain.com und im Return-Path @bounce.salesforce.com, scheitert das Alignment – SPF authentifiziert, DMARC scheitert trotzdem. Falls kein Alignment möglich ist, wird DKIM zur Pflicht.

Viele Organisationen scheitern gerade bei der DMARC-Einführung an diesem Punkt. SPF ist korrekt konfiguriert, und dennoch funktioniert DMARC nicht bzw. SPF ist ständig kritisch.

So beheben Sie das:

Konfigurieren Sie für jeden Versand-Service den Return-Path (Bounce-Adresse) so, dass er auf Ihre Domain oder eine Subdomain davon verweist. Je nach Plattform unterschiedlich umgesetzt:

• Salesforce: Deaktivieren Sie Bounce-Management, damit Salesforce Ihre eigene Domain als Return-Path nutzt.
• Microsoft 365: Return-Path-Alignment erfolgt mit Ihrer eigenen Domain automatisch.
• Marketing-Plattformen (HubSpot, Marketo, Mailchimp): Fast alle bieten die Konfiguration von Return-Path oder envelope-from. Schauen Sie dafür jeweils ins Anbieter-Handbuch.

DMARC unterstützt zwei Alignment-Modi:

• Striktes Alignment (aspf=s):aspf=s): Return-Path und From müssen exakt übereinstimmen.
• Locker (aspf=r):aspf=r): Return-Path darf eine Subdomain der From-Adresse sein. Das ist Standard und für die meisten Organisationen zu empfehlen.

Ist zum Beispiel From @yourdomain.com und Return-Path @mail.yourdomain.com, besteht das Alignment. So bleibt Flexibilität für verschiedene Sendequellen bei gewahrter DMARC-Konformität.

Das wichtigste Diagnose-Tool sind Ihre DMARC-Aggregatberichte. Sie zeigen SPF-Status und Alignment aufgeschlüsselt. So erkennen Sie direkt, ob ein Autorisierungsproblem (SPF) oder ein Alignment-Problem (Rückweg stimmt nicht mit From überein) vorliegt.

In Red Sift OnDMARC sehen Sie dies anschaulich: Welche Absender SPF bestehen, aber am Alignment scheitern, wird grafisch dargestellt und zeigt auch, wo genau die Domain-Diskrepanz liegt. Starten Sie Ihre Schritt-für-Schritt-DMARC-Implementierung und prüfen Sie so alle Ihre Versandquellen systematisch durch.

DMARC-Aggregatberichte enthalten alles, was Sie brauchen, um SPF-Fehler zu erkennen und zu beheben. Darauf sollten Sie achten:

Wenn Sie DMARC-Berichte manuell analysieren (XML parsen), verbringen Sie Stunden mit einer Arbeit, die eine Plattform in Sekunden erledigen kann. Red Sift OnDMARC verwandelt rohe aggregierte Berichtsdaten in klare, umsetzbare Dashboards, die genau zeigen, welche Absender fehlschlagen, warum sie fehlschlagen und wie sie zu beheben sind. Eine Übersicht der besten Tools für jede Phase finden Sie in unserem Leitfaden zu den besten Tools für E-Mail-Authentifizierung.

SPF-Fehler lassen sich beheben. Jede der sechs Fehlerarten in diesem Leitfaden hat einen klaren Diagnoseweg und eine konkrete Lösung. Die eigentliche Herausforderung ist nicht die Komplexität, sondern die Sichtbarkeit.

Ohne DMARC-Berichte sind Sie blind unterwegs. Sie wissen nicht, welche Dienste in Ihrem Namen E-Mails versenden, welche an der Authentifizierung scheitern oder warum. Mit DMARC wird jeder Fehler zu einem Posten, den Sie untersuchen und beheben können.

Wenn Sie aktuell mit SPF-Fehlern zu tun haben, starten Sie mit einem kostenlosen Scan mit Red Sift Investigate, um den Status Ihrer aktuellen Einträge zu überprüfen. Für kontinuierliche Überwachung, automatisiertes Absendermanagement und einen klaren Weg zur DMARC-Durchsetzung, starten Sie eine kostenlose Testversion von Red Sift OnDMARC.

[1] An update on bulk sender requirements - Google

[2] Strengthening Email Ecosystem - Microsoft Community Hub

[3] FBI Releases Annual Internet Crime Report

[4] 2024 IC3 Annual Report

[5] PCI DSS v4.0.1 Summary of Changes

[6] RFC 7208 - Sender Policy Framework (SPF)

[7] The SPF lookup limit explained - Mailhardener

[8] RFC 7208 Section 4.6.4 - DNS Lookup Limits

[9] SPF failures: Hard fail vs Soft fail - Red Sift

[10] ARC: Solving the DMARC Problem with Email Forwarding - Mailflow Authority