DNS-SPF-Eintrag: So funktioniert er und wie man ihn einrichtet

Jede E-Mail, die Ihr Unternehmen versendet, wirkt sich auf den Ruf Ihrer Domain aus. Wenn Ihr SPF-Eintrag falsch konfiguriert ist oder ganz fehlt, haben die empfangenden Server keine zuverlässige Möglichkeit zu überprüfen, ob die E-Mail tatsächlich von Ihnen stammt. Legitime E-Mails landen im Spam-Ordner. Marketingkampagnen werden zurückgewiesen. Angreifer versenden Nachrichten, die so aussehen, als kämen sie von Ihrer Domain.

SPF (Sender Policy Framework) ist eine der drei wichtigsten E-Mail-Authentifizierungsprotokolle neben DKIM und DMARC, das empfangenden Mailservern mitteilt, welche IP-Adressen berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. Es wird als DNS-TXT-Eintrag veröffentlicht. Auf den ersten Blick sieht es einfach aus. In der Praxis ist SPF jedoch der Ausgangspunkt für die meisten Probleme bei der E-Mail-Authentifizierung. 

Dieser Leitfaden erklärt genau, was ein SPF-Eintrag ist, wie die SPF-Überprüfung Schritt für Schritt funktioniert, wie man einen solchen Eintrag erstellt und wie man die häufigsten SPF-Fehler behebt – einschließlich der Beschränkung auf 10 DNS-Abfragen, die bei wachsenden Unternehmen unbemerkt die E-Mail-Zustellung beeinträchtigt.

Was ist ein DNS-SPF-Eintrag?

Ein DNS-SPF-Eintrag (Sender Policy Framework) ist eine Art von DNS-TXT-Eintrag, der festlegt, welche Mailserver berechtigt sind, E-Mails für Ihre Domain zu versenden. Er hilft den empfangenden Mailservern dabei, zu überprüfen, ob eingehende Nachrichten aus legitimen Quellen stammen, und verringert so das Risiko von Spoofing und Phishing. Beim Empfang einer E-Mail überprüft der Server den SPF-Eintrag der Absenderdomain, um sicherzustellen, dass die Absender-IP-Adresse zulässig ist. 

Wenn die IP-Adresse nicht aufgeführt ist, wird die Nachricht möglicherweise markiert, abgelehnt oder in den Spam-Ordner verschoben. Die korrekte Konfiguration eines SPF-Eintrags verbessert die Zustellbarkeit von E-Mails und stärkt die Domain-Authentifizierung.

Sie können den SPF-Eintrag Ihrer Domain sofort mit einem kostenlosen SPF-Lookup-Toolüberprüfen. Das dauert nur fünf Sekunden und zeigt Ihnen genau, was in Ihrem DNS veröffentlicht ist.

Wie funktioniert die SPF-Authentifizierung?

Bei der SPF-Authentifizierung wird bei jedem E-Mail-Eingang ein strukturierter DNS-Abfrage- und Validierungsprozess durchlaufen:

• Ihre Domain veröffentlicht einen SPF-Eintrag als DNS-TXT-Eintrag. Dieser Eintrag definiert alle autorisierten Absenderquellen mithilfe von Mechanismen wie ip4, ip6, includeund eine, zusammen mit einer Standardrichtlinie (-all, ~alloder ?all).
• Wenn eine E-Mail versendet wird, fügt der sendende Server eine „Return-Path“-Adresse (Absenderadresse im Umschlag) hinzu, die die für die Zustellung zuständige Domain angibt.
• Der empfangende Mailserver extrahiert die Domain aus der Return-Path-Adresse.
• Es führt eine DNS-Abfrage durch, um den zu dieser Domain gehörenden SPF-Eintrag abzurufen.
• Die IP-Adresse des sendenden Servers wird dann anhand jedes einzelnen Mechanismus im SPF-Eintrag überprüft und der Reihe nach verarbeitet, bis eine Übereinstimmung festgestellt oder eine Richtlinienentscheidung getroffen wird.
• SPF begrenzt die Anzahl der DNS-Abfragen während dieser Auswertung auf 10, um eine übermäßige Rekursion zu verhindern. Wird diese Grenze überschritten, wird ein PermError ausgelöst.
• Je nach Ergebnis gibt SPF einen Wert wie „Pass“, „Fail“, „SoftFail“, „Neutral“, „None“, „PermError“ oder „TempError“ zurück.
• Der empfangende Server nutzt dieses Ergebnis zusammen mit der DKIM-Authentifizierung und der DMARC-Richtlinienkonformität, um zu entscheiden, wie die Nachricht behandelt werden soll (zustellen, unter Quarantäne stellen oder ablehnen).

Ein entscheidendes Detail: SPF überprüft die Domain des „Return-Path“ (Absender der E-Mail-Hülle), nicht den sichtbaren „From“-Header. Wenn diese Domains voneinander abweichen – was bei Versandplattformen von Drittanbietern häufig der Fall ist –, wird die SPF-Prüfung zwar bestanden, aber kann die DMARC-Übereinstimmung kann fehlschlagen, was sich direkt auf die Zustellung im Posteingang auswirkt.

Jeder SPF-Ergebniscode hat eine bestimmte praktische Bedeutung:

DMARC-Gesamtberichte zeigen Ihnen genau, welche E-Mails über alle Ihre Absenderquellen hinweg die SPF-Prüfung bestehen und welche nicht. Ohne DMARC-Berichterstattung treten SPF-Fehler unbemerkt auf, und Sie erfahren davon erst, wenn sich jemand beschwert.

Erläuterung der Syntax und des Formats von SPF-Einträgen

Um die SPF-Syntax zu verstehen, muss man zunächst einen vollständigen Eintrag lesen und wissen, wie die einzelnen Teile ausgewertet werden. Hier ein typisches Beispiel:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (wobei /24 einen Bereich von 256 IP-Adressen in der CIDR-Notation (Classless Inter-Domain Routing) darstellt)

Diese einzige Zeile teilt den empfangenden Servern genau mit, welche Absender E-Mails für Ihre Domain versenden dürfen und wie sie vorgehen sollen, wenn ein Absender nicht aufgeführt ist.

SPF-Versionskennzeichnung (v=spf1)

Jeder SPF-Eintrag muss mit v=spf1. Dies kennzeichnet den TXT-Eintrag als SPF-Richtlinie. Es gibt keine anderen gültigen Versionen. Fehlt dieses Tag oder ist es falsch, wird der Eintrag vollständig ignoriert.

SPF-Mechanismen (autorisierte Absender) 

Regeln legen fest, wer E-Mails versenden darf. Sie werden von links nach rechts abgearbeitet, und die erste Übereinstimmung bestimmt das Ergebnis.

Zu den umfassen: Der „include“-Mechanismus ist der am häufigsten verwendete und derjenige, der die meisten Probleme verursacht. Jeder „include:“ löst eine rekursive DNS-Abfrage aus. Wenn der SPF-Eintrag von Google drei weitere Domains enthält, werden diese alle auf Ihr Limit von 10 Abfragen angerechnet.

Ein häufiger Grund für Verwirrung: die a Mechanismus in SPF bezieht sich auf den DNS-A-Eintrag der Domain. Es wird kein separater „A-Eintrag für SPF“ erstellt. Wenn Sie einen zu Ihrem SPF-Eintrag hinzufügen, autorisieren Sie alle IP-Adressen, auf die der A-Eintrag Ihrer Domain verweist.

Modifikatoren (redirect=)

Modifikatoren steuern das Verhalten der SPF-Auswertung, anstatt Absender zu definieren.

• redirect=
  Überträgt die gesamte SPF-Auswertung auf eine andere Domain. Im Gegensatz zu include:, das eine eine weitere Richtlinie in Ihren Eintrag einfügt, ersetzt ersetzt Ihre Auswertung vollständig.
  Verwenden Sie dies nur, wenn eine Domain die SPF-Konfiguration einer anderen Domain vollständig übernehmen soll.

DNS-Lookup-Limit (kritische Einschränkung)

SPF erlaubt maximal 10 DNS-Abfragen pro Auswertung. Zu den Mechanismen gehören umfassen:, a, mx, existiert:, und redirect= alle zählen zu diesem Limit.

Wird das Limit überschritten, gibt SPF einen PermError zurück, und die Authentifizierung schlägt fehl, selbst wenn der Absender legitim ist. Aus diesem Grund müssen umfangreiche, komplexe Datensätze oft optimiert werden (z. B. durch Reduzierung nicht verwendeter Einbindungen oder durch Abflachung).

SPF-Qualifizierer (der „all“-Mechanismus)

Die Einschränkung bezüglich der „all“ „all“-Mechanismus am Ende Ihres SPF-Eintrags definiert Ihre SPF-Richtlinie – was mit E-Mails von Servern geschieht, die nicht ausdrücklich aufgeführt sind:

SPF funktioniert als logischer Regelsatz. Der empfangende Server liest Ihren Eintrag von links nach rechts, prüft jeden Mechanismus und hört beim ersten Treffer auf. Wird kein Treffer gefunden, wird der allgemeine Regel.

Ein gut strukturierter SPF-Eintrag sieht wie folgt aus:

• Vollständig (alle legitimen Absender enthalten)
• Effizient (innerhalb der Suchgrenzen)
• Strict (unter Verwendung von -all nach der Validierung)

Dadurch wird eine zuverlässige Authentifizierung gewährleistet und die unbefugte Nutzung Ihrer Domain zum Versenden von E-Mails verhindert.

So erstellen und veröffentlichen Sie einen SPF-Eintrag

Um einen SPF-Eintrag einzurichten, müssen Sie alle legitimen Absenderquellen identifizieren, diese im DNS eindeutig definieren und überprüfen, ob die Konfiguration wie erwartet funktioniert. Befolgen Sie die folgenden 5 Schritte der Reihe nach.

Schritt 1: Ermitteln Sie alle Ihre Absenderquellen

Listen Sie alle Dienste auf, die E-Mails im Namen Ihrer Domain versenden. Dazu gehören in der Regel Ihr primärer E-Mail-Anbieter (wie Google Workspace oder Microsoft 365), Marketingplattformen (wie Mailchimp oder HubSpot), Customer-Relationship-Management-Systeme (CRM) (Salesforce), Support-Tools (Zendesk) und Transaktions-E-Mail-Dienste (SendGrid, Amazon SES). Jeder dieser Dienste versendet E-Mails über eine andere Infrastruktur, daher müssen alle ausdrücklich autorisiert werden. Die meisten Anbieter veröffentlichen in ihrer Dokumentation einen SPF-Include-Wert, der den empfangenden Servern mitteilt, dass sie den Absender-IPs vertrauen können.

Schritt 2: Erstellen Sie Ihren SPF-Eintrag

Ein SPF-Eintrag ist ein einzeiliger TXT-Eintrag, der mit „v=spf1“ beginnt. Anschließend definieren Sie autorisierte Absender mithilfe folgender Mechanismen:

• einschließlich: für Dienste von Drittanbietern (z. B. include:_spf.google.com)
• ip4: oder ip6: für bestimmte IP-Adressen oder -Bereiche, die Sie verwalten
  Die Mechanismen werden von links nach rechts ausgewertet. Am Ende definieren Sie eine Richtlinie:
• ~all (Soft-Fail) markiert nicht autorisierte Absender als verdächtig
• -all (hardfail) lehnt sie ausdrücklich ab

Beispiel:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Diese Datei teilt den empfangenden Servern genau mit, welche Quellen zugelassen sind und wie mit allen anderen umzugehen ist.

Schritt 3: Den Eintrag im DNS veröffentlichen

Melden Sie sich bei Ihrem DNS-Anbieter (z. B. Cloudflare, Route 53 oder GoDaddy) an. Erstellen Sie einen neuen TXT-Eintrag für Ihre Root-Domain:

• Host/Name: @ (oder leer lassen, je nach Anbieter)
• Wert: Ihr vollständiger SPF-Eintrag
  Sobald der Eintrag gespeichert ist, ist er über das DNS öffentlich zugänglich. Es kann einige Zeit dauern, bis Änderungen wirksam werden.

Schritt 4: Den Datensatz überprüfen

Überprüfen Sie nach der Veröffentlichung Folgendes:

• Der SPF-Eintrag ist korrekt formatiert (keine Syntaxfehler)
• Alle Einträge werden korrekt aufgelöst
• Die Gesamtzahl der DNS-Abfragen darf das Limit von 10 nicht überschreiten (bei Überschreitung schlägt SPF mit einem PermError fehl)

Die Validierung stellt sicher, dass empfangende Server Ihren Datensatz zuverlässig und fehlerfrei verarbeiten können.

Schritt 5: Überwachen Sie die SPF-Ergebnisse

Die SPF-Einrichtung ist keine einmalige Angelegenheit. Wenn Sie Absenderquellen hinzufügen oder entfernen, muss Ihr SPF-Eintrag aktualisiert werden. So überwachen Sie die Leistung:

• Aktivieren DMARC , um aggregierte Berichte mit den SPF-Erfolgs- und Fehlerquoten zu erhalten
• Überprüfen Sie, welche Quellen die Authentifizierung bestehen oder nicht bestehen
• Entfernen Sie nicht genutzte Dienste und korrigieren Sie falsch zugeordnete oder nicht autorisierte Absender

Wichtig: Pro Domain ist nur ein SPF-Eintrag zulässig. Wenn mehrere TXT-Einträge vorhanden sind, die mit v=spf1 , schlägt die SPF-Auswertung vollständig mit einem PermError fehl. Führen Sie stets alle Absenderquellen zu einem einzigen, vollständigen Eintrag zusammen.

Das Limit für DNS-Lookups bei SPF 10 (und warum es Ihre E-Mails beeinträchtigt)

Die SPF-Prüfung ist nicht unbegrenzt. Gemäß RFC 7208 darf ein empfangender Server bei der Verarbeitung Ihres SPF-Eintrags maximal 10 DNS-Abfragen durchführen. Wird diese Grenze überschritten, gibt SPF einen PermError (permanenten Fehler) zurück und die Prüfung schlägt vollständig fehl.

Dies ist kein teilweiser Fehler. Ein „PermError“ bedeutet, dass die SPF-Prüfung überhaupt nicht durchgeführt werden kann. Infolgedessen durchläuft jede von Ihrer Domain versendete E-Mail die SPF-Authentifizierung nicht, unabhängig davon, ob der Absender legitim ist.

Was zählt auf das Limit von 10 Suchanfragen an?

Die folgenden Mechanismen lösen DNS-Abfragen aus:

• Dazu gehören: (die häufigsten und wirkungsvollsten)
• a
• mx
• ptr (veraltet, zählt aber weiterhin, wenn verwendet)
• existiert:
• Weiterleitung=

Die Mechanismen „ip4:“ und „ip6:“ werden nicht auf das Suchlimit angerechnet, da sie direkt auf IP-Adressen verweisen und keine DNS-Auflösung erfordern

Warum diese Grenze leicht überschritten wird

Das Hauptproblem liegt in verschachtelten (rekursiven) Abfragen.

Wenn Sie einen „include:“ einfügen, fügen Sie nicht nur eine Nachschlageintragung hinzu, sondern übernehmen auch den gesamten Inhalt des SPF-Eintrags dieses Anbieters.

Zum Beispiel:

• Sie fügen Google hinzu → Googles SPF kann mehrere andere Domains enthalten
• Sie fügen Microsoft 365 hinzu → fügt mehrere weitere Nachschlagewerke hinzu
• Sie integrieren Marketing- und Transaktions-Tools → jedes fügt seine eigene Kette hinzu

Das summiert sich schnell. Selbst wenn Ihr Datensatz kurz erscheint, kann die tatsächliche Anzahl der Abfragen bei der Auswertung 10 übersteigen.

Die (oft übersehene) Beschränkung auf zwei „Void-Lookups“

SPF begrenzt zudem die Anzahl der erfolglosen Suchvorgänge auf zwei.

Eine „Void Lookup“-Abfrage liegt vor, wenn eine DNS-Abfrage kein Ergebnis liefert (Non-Existent Domain (NXDOMAIN) oder eine leere Antwort).

Häufige Ursachen:

• Falsche oder veraltete Angaben umfassen: Domains
• Tippfehler in SPF-Mechanismen
• Verweise auf Domains, die nicht mehr existieren

Wenn mehr als zwei ungültige Suchvorgänge auftreten, gibt SPF erneut einen PermError zurück.

A PermError bedeutet nicht „Fehler bei einigen Absendern“. Es bedeutet:

• SPF wird als ungültig angesehen
• Empfangsserver können Ihrer SPF-Richtlinie nicht vertrauen
• SPF bietet praktisch keinen Schutz und keine Authentifizierung

Da SPF eines der von DMARC verwendeten Signale ist, kann dies auch dazu führen, dass:

• DMARC-Fehler (falls DKIM nicht übereinstimmt)
• Zunehmende Verbreitung von Spam
• Ablehnung von Nachrichten durch strengere Empfänger

Je mehr E-Mails Sie versenden, desto komplexer wird Ihr SPF-Eintrag natürlich. Ohne aktive Verwaltung:

• Die Anzahl der Abfragen steigt unbemerkt an
• Nicht genutzte Dienste bleiben im Datensatz erhalten
• Fehler häufen sich mit der Zeit an

SPF ist in dieser Hinsicht anfällig. Es funktioniert nur dann zuverlässig, wenn die Daten innerhalb bestimmter Grenzen bleiben, korrekt sind und kontinuierlich gepflegt werden.

Wie schnell man an die Grenze stößt (ein Beispiel aus der Praxis)

So sieht ein typischer SaaS-Stack für mittelständische Unternehmen in Bezug auf DNS-Abfragen aus:

Sie haben noch nicht einmal Zendesk, SendGrid, Ihren Helpdesk oder Ihren Lohnbuchhaltungsanbieter hinzugefügt. Wenn Ihr Unternehmen Google Workspace sowie vier oder fünf SaaS-Tools nutzt, die E-Mails versenden, haben Sie das Limit wahrscheinlich bereits erreicht oder sogar überschritten.

So beheben Sie Probleme mit dem SPF-Lookup-Limit

Wenn Ihr SPF-Eintrag das Limit von 10 DNS-Abfragen überschreitet, müssen Sie die Komplexität reduzieren, ohne dabei legitime Absender zu beeinträchtigen. Hier sind die drei praktischen Ansätze, geordnet nach ihrer Wirksamkeit:

Unnötige Mechanismen entfernen

Beginnen Sie mit einer umfassenden Überprüfung Ihres SPF-Eintrags.

• Nenne alle einschließlich: und derzeit aufgeführten Mechanismen
• Überprüfen Sie, ob jeder Dienst weiterhin aktiv E-Mails für Ihre Domain versendet
• Entfernen Sie alles, was nicht mehr gebraucht wird

Allgemeine Probleme:

• Veraltete Marketinginstrumente, die in den Unterlagen verblieben sind
• Doppelte Einträge über Subdomains hinweg
• Test- oder temporäre Dienste wurden nie bereinigt

Zu den ungenutzten Include: die Sie entfernen, macht sofort einen oder mehrere DNS-Lookups frei. Dies ist der einfachste und risikoärmste Weg, um wieder unter das Limit zu kommen.

Ersetzen einschließlich: durch ip4:/ip6: soweit möglich

Wenn ein Absender einen festen und kleinen Satz von IP-Adressen verwendet, können Sie dessen einschließlich: durch direkte IP-Einträge ersetzen.

• Beispiel: Ersetzen Sie include:vendor.com durch ip4:x.x.x.x
• Dadurch werden DNS-Abfragen für diesen Absender vollständig unterbunden

Wenn das gut funktioniert:

• Interne Infrastruktur
• Dedizierte IP-Adressen eines Anbieters
• Anbieter mit eindeutig dokumentierten, stabilen IP-Bereichen

Zu berücksichtigender Kompromiss:

• Sie übernehmen die Verantwortung für die Instandhaltung
• Wenn der Provider die IP-Adressen aktualisiert oder wechselt, ist Ihr SPF-Eintrag nicht mehr aktuell
• Dies kann zu unbemerkten SPF-Fehlern führen, bis das Problem behoben ist

Verwenden Sie dies nur, wenn die IP-Stabilität vorhersehbar ist.

Verwendung SPF-Flattening oder SPF-Makros

Wenn Sie auf mehrere Dienste von Drittanbietern zurückgreifen, reicht eine manuelle Bereinigung allein meist nicht aus. Sie benötigen eine Möglichkeit, die Anzahl der Abfragen zu reduzieren, ohne dabei an Abdeckung einzubüßen.

SPF-Abflachung

• Behebt alle einschließlich: Mechanismen in ihre zugrunde liegenden IP-Adressen
• Ersetzt sie durch eine einfache Liste von ip4: / ip6: Einträgen
• Vermeidet die meisten DNS-Abfragen

Einschränkung:

• Abgeflachte Datensätze sind statisch
• Wenn ein Anbieter (wie Google oder Microsoft) seine Absender-IPs aktualisiert, wird Ihr Eintrag nicht automatisch aktualisiert
• Dadurch entsteht eine Lücke, durch die legitime E-Mails ohne Vorwarnung die SPF-Prüfung nicht bestehen könnten

SPF-Makros (dynamische Alternative)

• Die SPF-Auswertung dynamisch halten und gleichzeitig die Lookup-Tiefe steuern
• Die Abhängigkeit von langen Include-Ketten verringern
• Besser geeignet für Umgebungen mit sich häufig ändernder Absenderinfrastruktur

Sie wissen nicht genau, wie viele Lookups Ihr SPF-Eintrag verwendet? Überprüfen Sie die Anzahl der Lookups mit unserem kostenlosen SPF-Checker

Für Unternehmen, die die Obergrenze von 10 Abfragen einhalten müssen, ohne manuelle DNS-Verwaltung, bietet PowerDMARC PowerSPF bietet sowohl traditionelles Flattening als auch moderne SPF-Makros, sodass Sie die Technik wählen können, die zu Ihrer Umgebung passt. Der Eintrag wird automatisch aktualisiert, wenn Drittanbieter ihre autorisierten IP-Bereiche ändern.

Warum der Lichtschutzfaktor allein nicht ausreicht

SPF ist eine grundlegende Authentifizierungsmethode, wurde jedoch nicht dafür entwickelt, umfassenden Schutz vor modernen Spoofing-Angriffen und Missbrauch zu bieten. Es weist drei wesentliche Einschränkungen auf, die es für sich genommen unzureichend machen.

Einschränkung 1: SPF überprüft den Absender der E-Mail, nicht den „From“-Header

SPF überprüft den Return-Path (Absender des E-Mail-Umschlags), also die bei der E-Mail-Übertragung verwendete Domain. Der Benutzer sieht jedoch den „From“-Header, der davon abweichen kann.

Dadurch entsteht eine Lücke, die Angreifer ausnutzen können:

• Ein Angreifer versendet E-Mails von seiner eigenen Domain (die die SPF-Prüfung besteht)
• Sie stellen die sichtbare Absenderadresse so ein, dass sie als Ihre Domain oder als eine vertrauenswürdige Person angezeigt wird
• SPF wird bestanden, da die Absenderdomain legitim ist
• Der Empfänger sieht weiterhin eine gefälschte Identität

SPF verfügt über keine integrierte Möglichkeit, zu überprüfen, ob die Absenderdomäne mit dem sichtbaren Absender übereinstimmt. DMARC löst dieses Problem durch die Durchsetzung Übereinstimmung zwischen SPF (oder DKIM) und der Domain im „From“-Header durchzusetzen.

Einschränkung 2: SPF-Fehler bei der E-Mail-Weiterleitung

SPF stützt sich auf die IP-Adresse des sendenden Servers. Wenn eine E-Mail weitergeleitet wird:

• Der Weiterleitungsserver wird zur neuen Absenderquelle
• Die IP-Adresse wird mit dem SPF-Eintrag der ursprünglichen Domain abgeglichen. Da der Weiterleitungsserver nicht als autorisierter Absender aufgeführt ist, schlägt die SPF-Prüfung fehl.
• Da es nicht aufgeführt ist, schlägt SPF fehl

Das passiert selbst dann, wenn die E-Mail völlig legitim ist. Es handelt sich dabei nicht um eine Fehlkonfiguration, sondern um eine Einschränkung der Funktionsweise von SPF.

Auswirkungen:

• Legitime weitergeleitete E-Mails scheitern oft am SPF
• Empfangssysteme müssen sich auf andere Signale (wie DKIM) stützen, um die Nachricht zu validieren

Einschränkung 3: SPF verfügt über keinen eigenen Berichtsmechanismus

SPF bietet keine integrierten Berichtsfunktionen.

Ohne zusätzliche Schicht:

• Du weißt nicht, welche Quellen den SPF-Test bestehen und welche nicht
• Sie können mit Ihrer Domain keine unberechtigten Absender erkennen
• Sie haben keinen Einblick in Authentifizierungsprobleme, die sich auf die Zustellbarkeit auswirken

DMARC bietet zusätzlich eine Berichtsfunktion, die Ihnen aggregierte Daten zu den SPF- und DKIM-Ergebnissen aller Empfänger liefert.

Die moderne E-Mail-Infrastruktur mit Weiterleitungen, Mailinglisten, externen Absendern und ausgeklügelten Spoofing-Methoden hat die Möglichkeiten von SPF allein längst überholt. DKIM ergänzt dies durch eine kryptografische Signatur, die auch bei Weiterleitungen erhalten bleibt, und behebt damit die größte Schwachstelle von SPF. DMARC ist die Richtlinienebene, die SPF und DKIM mit dem „From“-Header verbindet.

Einen umfassenden Vergleich der Funktionsweise dieser Protokolle im Zusammenspiel finden Sie in unserem Leitfaden zu SPF vs. DKIM vs. DMARC.

Häufige Fehler bei SPF-Einträgen (und wie man sie behebt)

Die meisten SPF-Fehler lassen sich auf einige wenige, immer wiederkehrende Probleme zurückführen. Das Problem liegt meist in mangelnder Wartung und Validierung. Hier erfahren Sie, wie Sie diese Probleme erkennen und mit konkreten Maßnahmen beheben können.

Fehler 1: Mehrere SPF-Einträge für dieselbe Domain.

SPF erfordert eine einzige, verbindliche Richtlinie. Wenn mehrere TXT-Einträge mit v=spf1, können empfangende Server nicht feststellen, welcher davon ausgewertet werden soll. Das Ergebnis ist ein PermError, was bedeutet, dass SPF für jede Nachricht vollständig fehlschlägt.

Warum das so ist:

• Verschiedene Teams fügen Datensätze unabhängig voneinander hinzu (Marketing, IT, Support-Tools)
• Neue Anbieter geben Anweisungen zum Hinzufügen dieses Datensatzes, ohne die bestehende Konfiguration zu überprüfen

Wie man das beheben kann:

• Überprüfen Sie alle TXT-Einträge Ihrer Domain
• Alle SPF-bezogenen Einträge identifizieren
• Alle Mechanismen in einem einzigen vollständigen Datensatz zusammenfassen

Was Sie beachten sollten:

• Nach Migrationen zurückgebliebene Teilbestände
• Subdomains, die fälschlicherweise anstelle der Root-Domain verwendet werden 

Fehler 2: Überschreitung des Limits von 10 DNS-Abfragen

Sobald die SPF-Prüfung 10 DNS-Abfragen überschreitet, wird sie sofort abgebrochen und es wird ein PermError zurückgegeben. Dadurch wird die SPF-Validierung für alle Absender ungültig, auch für legitime.

Warum das so ist:

• Zu häufige Verwendung von umfasst: für mehrere SaaS-Tools
• Verschachtelte Einbindungen von Anbietern (Sie binden sie ein, diese wiederum binden andere ein)
• Keine Übersicht über die Gesamtzahl der Suchanfragen

Wie man das beheben kann:

• Jeden Mechanismus und dessen Auswirkungen auf die Datensuche genau aufzeigen
• Entferne zuerst nicht verwendete oder überflüssige Include-Anweisungen
• Überprüfen Sie, ob jedes Tool wirklich von Ihrer Domain aus versendet werden muss

Was Sie beachten sollten:

• „Versteckte“ Abfragen in Include-Dateien von Drittanbietern
• Schrittweiser Ausbau im Laufe der Zeit durch die Einführung neuer Tools

Fehler 3: Die Verwendung von +all (alles übergeben)

Dadurch werden empfangende Server ausdrücklich angewiesen, jeder Absenderquelle zu vertrauen, wodurch SPF als Sicherheitsmaßnahme praktisch außer Kraft gesetzt wird.

Warum das so ist:

• Falsche Interpretation der SPF-Syntax
• Temporäre Testkonfigurationen wurden nie zurückgesetzt

Wie man das beheben kann:

• Ersetzen durch ~all während Sie Ihre Konfiguration überprüfen
• Wechseln zu -alle , sobald alle legitimen Absender bestätigt sind

Was Sie beachten sollten:

• Alte Aufzeichnungen, die aus unzuverlässigen Quellen kopiert wurden
• Domains, die als „authentifiziert“ erscheinen, aber keinen wirklichen Schutz bieten

Fehler 4: Verwendung des veralteten ptr Mechanismus

Mechanismen wie ptr führen zu langsamen, unzuverlässigen Nachschlägen und werden von modernen Empfängern möglicherweise ignoriert, was zu inkonsistenten SPF-Ergebnissen führt.

Warum das so ist:

• Im Laufe der Zeit beibehaltene Altkonfigurationen
• Veraltete Dokumentation oder Vorlagen

Wie man das beheben kann:

• Veraltete Mechanismen wie ptr
• Durch explizite Angaben ersetzen include: oder ip4: / ip6: Einträge

Was Sie beachten sollten:

• Überdimensionierte Datensätze, die versuchen, Sonderfälle abzudecken
• Mechanismen, die die Komplexität erhöhen, ohne einen klaren Nutzen zu bieten

Fehler 5: Fehlende legitime Absender

E-Mails von gültigen Plattformen bestehen den SPF-Test nicht, was folgende Folgen haben kann:

• Nachrichten, die im Spam-Ordner landen
• Lieferverzögerungen oder Ablehnungen
• DMARC-Fehler, wenn kein abgestimmter Fallback vorhanden ist

Warum das so ist:

• Neue Tools wurden hinzugefügt, ohne SPF zu aktualisieren
• Mangelnde Abstimmung zwischen den Teams, die die E-Mail-Systeme verwalten

Wie man das beheben kann:

• Führen Sie eine zentrale Liste aller zugelassenen Absenderquellen
• SPF-Einträge sollten bereits im Rahmen des Onboarding-Prozesses hinzugefügt werden – und nicht erst, wenn Probleme auftreten
• Überprüfen Sie regelmäßig, ob alle aktiven Absender erfasst sind

Was Sie beachten sollten:

• Transaktionssysteme (Abrechnung, Benachrichtigungen) werden oft übersehen
• Regionale oder teamspezifische Tools, die eigenständig versendet werden

Fehler 6: SPF-Eintrag mit mehr als 255 Zeichen in einer einzelnen DNS-Zeichenkette

SPF-Einträge, die die DNS-Grenzwerte überschreiten oder falsch formatiert sind, können abgeschnitten oder falsch interpretiert werden, was zu stillen Fehlern führen kann.

Warum das so ist:

• Zu viele Einbindungen und Mechanismen in einem einzigen Datensatz
• DNS-Anbieter behandeln lange TXT-Werte unterschiedlich

Wie man das beheben kann:

• Halten Sie den Bericht so kurz wie möglich
• Verwenden Sie bei Bedarf mehrere Zeichenfolgen in Anführungszeichen innerhalb eines einzelnen TXT-Eintrags
• Überprüfen Sie den veröffentlichten Datensatz nach dem Speichern noch einmal (nicht nur die Eingabe)

Was Sie beachten sollten:

• Einträge, die in Ihrem DNS-Panel korrekt aussehen, aber falsch aufgelöst werden
• Formatierungsprobleme, die bei manuellen Bearbeitungen entstanden sind

Führen Sie einen kostenlosen SPF-Zustandscheck durch, um zu prüfen, ob Ihr Eintrag einen dieser Fehler enthält

Bewährte Verfahren für SPF im Jahr 2026

Bei einem korrekten SPF-Eintrag geht es nicht nur um die Syntax. Es geht darum, eine Richtlinie einzuhalten, die auch bei der Weiterentwicklung Ihrer E-Mail-Infrastruktur stets korrekt bleibt. Diese bewährten Verfahren tragen dazu bei, dass Ihre SPF-Konfiguration zuverlässig und effizient bleibt und den aktuellen Anforderungen an Absender entspricht.

1. Verwenden Sie pro Domain nur einen SPF-Eintrag

SPF lässt nur einen TXT-Eintrag zu, der mit v=spf1. Mehrere Einträge führen zu einem PermError und unterbrechen die Authentifizierung vollständig. Fügen Sie neue Einträge immer in Ihren bestehenden Eintrag ein.

2. Alle legitimen Absenderquellen beibehalten

Ihr SPF-Eintrag muss jedes System enthalten, das in Ihrem Namen E-Mails versendet. Fehlt ein Absender, führt dies zu SPF-Fehlern, was sich direkt auf die Zustellbarkeit und die DMARC-Konformität auswirkt.

3. Halten Sie sich an das Limit von 10 DNS-Abfragen

Zu den enthält:, ein, mx, existiert:, und redirect= wird auf das Limit angerechnet. Bei Überschreitung von 10 wird ein PermError ausgelöst, wodurch SPF für alle E-Mails ungültig wird. Überprüfen und optimieren Sie Ihren Eintrag regelmäßig.

4. Nicht verwendete oder veraltete Include-Dateien entfernen

Alte Tools, Testumgebungen und veraltete Dienste bleiben oft noch lange in SPF-Einträgen erhalten, nachdem sie bereits keine E-Mails mehr versenden. Dies führt zu unnötiger Komplexität und belastet das Lookup-Budget.

5. Bevorzugen IPv4: und ip6: für kontrollierte Infrastruktur

Wenn Sie dedizierte IP-Adressen oder stabile Absenderbereiche verwalten, verwenden Sie direkte IP-Mechanismen anstelle von include:. Dies reduziert DNS-Lookups und verbessert die Leistung.

6. Vermeiden Sie die Verwendung von +all unter keinen Umständen

Die +all Qualifizierer ermöglicht es jedem Server, im Namen Ihrer Domain zu senden, wodurch SPF als Sicherheitsmaßnahme praktisch außer Kraft gesetzt wird. Er sollte niemals in der Produktion verwendet werden.

7. Verwenden Sie ~all während der Einrichtung, wechsle dann zu -all

Beginne mit ~all (Softfail), während Sie Ihre Konfiguration validieren. Sobald alle legitimen Absender bestätigt und mit DMARC abgeglichen sind, wechseln Sie zu -all (Hardfail) für eine strikte Durchsetzung.

8. Vermeiden Sie veraltete oder riskante Mechanismen wie ptr

Der ptr -Mechanismus ist veraltet und unzuverlässig. Er verursacht unnötige DNS-Abfragen und wird von modernen Empfängern möglicherweise ignoriert. Verwenden Sie stattdessen explizite Mechanismen.

9. Überwachen Sie die SPF-Leistung mithilfe von DMARC-Berichten

SPF allein bietet keine Transparenz. Aktivieren Sie die DMARC-Berichterstellung, um zu verfolgen, welche Absender SPF-Prüfungen bei allen Empfängern bestehen oder nicht bestehen, und um unbefugte Aktivitäten zu erkennen.

10. Behandeln Sie SPF als ein kontinuierlich verwaltetes System

Die SPF-Einrichtung ist keine einmalige Angelegenheit. Jedes neue Tool, jede neue Plattform und jeder neue Anbieter, der E-Mails versendet, muss in Ihrem SPF-Eintrag berücksichtigt werden. Überprüfen und aktualisieren Sie diesen regelmäßig, um unbemerkte Fehler zu vermeiden.

So funktioniert SPF in Verbindung mit DKIM und DMARC

SPF, DKIM und DMARC sind als aufeinander abgestimmtes System konzipiert. Jedes dieser Verfahren löst einen anderen Aspekt des Problems der E-Mail-Vertrauenswürdigkeit, darunter die Legitimität des Absenders, die Integrität der Nachricht und die Identitätsabgleichung, und nur gemeinsam bieten sie zuverlässigen Schutz und eine wirksame Durchsetzung.

Wenn eine E-Mail eingeht, erfolgt die Authentifizierung in mehreren Schritten:

• SPF prüft, ob die IP-Adresse des sendenden Servers für die Domain im Return-Path (Absender des Umschlags) autorisiert ist
• DKIM überprüft eine an die Nachricht angehängte kryptografische Signatur und bestätigt, dass diese nicht verändert wurde und die signierende Domain gültig ist
• DMARC wertet die Ergebnisse von SPF und DKIM aus und prüft, ob eines der beiden mit der sichtbaren Absenderadresse übereinstimmt

SPF und DKIM liefern reine Authentifizierungsergebnisse, doch DMARC entscheidet, ob diese Ergebnisse im Kontext dessen, was der Empfänger tatsächlich sieht, aussagekräftig sind.

Sie benötigen sowohl SPF als auch DKIM, da jedes der beiden die Schwächen des anderen ausgleicht. SPF versagt bei der Weiterleitung, DKIM hingegen nicht. DKIM kann von einigen Zwischenstationen entfernt werden, SPF ist hingegen nicht vom Inhalt der Nachricht abhängig. Zusammen bieten sie Redundanz.

DMARC fügt die Richtlinienebene hinzu: Wie sollen Empfänger vorgehen, wenn sowohl SPF als auch DKIM die Überprüfung nicht bestehen? Es gibt drei Optionen: keine (nur überwachen), Quarantäne (als Spam markieren) und Ablehnen (vollständig blockieren). DMARC bietet zudem eine Berichtsfunktion – ohne diese weiß man nie, wann die Authentifizierung fehlschlägt.

Schlussfolgerung

SPF bildet die Grundlage der E-Mail-Authentifizierung, ist jedoch nur so sicher wie seine Konfiguration und nur so nützlich wie das DMARC-Framework, in das es einfließt. Ein falsch konfigurierter SPF-Eintrag beeinträchtigt die E-Mail-Zustellung, macht Ihre Domain anfällig für Spoofing und führt dazu, dass Ihr Unternehmen die aktuellen Anforderungen an Absender nicht mehr erfüllt.

Der nächste Schritt ist derselbe, egal ob Sie SPF zum ersten Mal einrichten oder einen fehlerhaften Eintrag beheben: Überprüfen Sie Ihre aktuelle Konfiguration.

Überprüfen Sie die E-Mail-Authentifizierung Ihrer Domain mit unserem kostenlosen Domain Analyzer . Er bewertet SPF, DKIM, DMARC und mehr in Sekundenschnelle. Benötigen Sie eine kontinuierliche Überwachung, automatisiertes SPF-Management und DMARC-Berichte? 

Starten Sie eine 15-tägige kostenlose Testphase

Häufig gestellte Fragen

Kann eine Domain mehr als einen SPF-Eintrag haben?

Nein. RFC 7208 schreibt genau einen SPF-Eintrag pro Domain vor. Wenn zwei TXT-Einträge vorhanden sind, die mit v=spf1 , geben beide „PermError“ zurück und die SPF-Prüfung schlägt vollständig fehl. Führen Sie alle autorisierten Quellen in einem einzigen Eintrag zusammen.

Was bedeutet es, wenn meine Domain zu viele DNS-Abfragen aufweist?

Ihr SPF-Eintrag überschreitet das in RFC 7208 festgelegte Limit von 10 DNS-Abfragen. Dies führt zu einem SPF-PermError, wodurch die SPF-Authentifizierung für alle E-Mails unterbrochen wird – nicht nur für die überzähligen. Reduzieren Sie die Einbindungen und ersetzen Sie sie durch ip4:/ip6:, oder verwenden Sie SPF-Flattening oder Makros, um unter dem Limit zu bleiben.

Was ist der Unterschied zwischen SPF-Softfail (~all) und Hardfail (-all)?

Softfail (~all) weist Empfänger an, die E-Mail anzunehmen, sie aber als verdächtig zu markieren. Hardfail (-all) weist Empfänger an, die E-Mail sofort abzulehnen. Verwenden Sie Softfail während der Ersteinrichtung und beim Testen; wechseln Sie zu Hardfail, sobald alle legitimen Absender bestätigt sind und DMARC eingerichtet ist.

Verhindert SPF E-Mail-Spoofing?

Nicht allein. SPF überprüft den Absender des Umschlags (Return-Path), nicht den „From“-Header, den die Empfänger sehen. Ein Angreifer kann die SPF-Prüfung bestehen, während er die sichtbare „From“-Adresse fälscht. Sie benötigen DMARC – das die Übereinstimmung zwischen den SPF-/DKIM-Ergebnissen und dem „From“-Header überprüft –, um das Fälschen des Anzeigenamens zu verhindern.

Was passiert, wenn SPF versagt?

Das hängt vom SPF-Qualifier ab und davon, ob DMARC konfiguriert ist. Mit -all und einer DMARC-Ablehnungsrichtlinie wird die E-Mail blockiert. Bei ~all und ohne DMARC wird die E-Mail möglicherweise dennoch zugestellt, jedoch als verdächtig markiert. Fehlt SPF gänzlich, haben Empfänger kein SPF-Signal zur Auswertung.

Wie überprüfe ich meinen SPF-Eintrag?

Nutzen Sie ein kostenloses SPF-Lookup-Tool. Geben Sie Ihre Domain ein, und das Tool ruft Ihren SPF-Eintrag aus dem DNS ab, überprüft die Syntax, zählt die DNS-Abfragen und markiert etwaige Fehler – einschließlich PermError- und Void-Lookup-Verstößen.

Brauche ich SPF, wenn ich bereits DKIM und DMARC nutze?

Ja. DMARC setzt voraus, dass mindestens entweder SPF oder DKIM die Überprüfung besteht und die Übereinstimmung gewährleistet ist. Zwar reicht DKIM allein aus, um die DMARC-Anforderungen zu erfüllen, doch bietet die Kombination aus SPF und DKIM eine zusätzliche Absicherung. Sollte eine der beiden Methoden versagen (beispielsweise wenn SPF bei der Weiterleitung nicht funktioniert), kann die andere weiterhin die DMARC-Übereinstimmung gewährleisten.

Was bedeutet SPF-Ausrichtung?

Unter SPF-Übereinstimmung versteht man, dass die Domain im Return-Path (Absender des Umschlags) mit der Domain im From-Header übereinstimmt. DMARC überprüft diese Übereinstimmung. Ohne sie kann SPF zwar bestehen, DMARC jedoch weiterhin fehlschlagen – was bei vielen Drittanbieter-Absendern der Fall ist, sofern diese nicht so konfiguriert sind, dass sie Ihre Domain im Return-Path verwenden.

Wie oft sollte ich meinen SPF-Eintrag aktualisieren?

Überprüfen Sie Ihren SPF-Eintrag jedes Mal, wenn Sie einen Versanddienst hinzufügen oder entfernen, und führen Sie mindestens vierteljährlich eine Überprüfung durch. SPF-Einträge verlieren ihre Gültigkeit, wenn Anbieter ihre IP-Bereiche ändern und sich die Versandinfrastruktur Ihres Unternehmens weiterentwickelt. Ein SPF-Eintrag, der vor sechs Monaten noch gültig war, kann heute fehlerhaft oder unvollständig sein.

Was ist SPF-Flattening?

Die SPF-Abflachung löst alle , einschließlich: Mechanismen in reine IP-Adressen um, wodurch die Anzahl der DNS-Lookups reduziert wird. Dadurch bleibt man unter dem Limit von 10 Lookups, erstellt jedoch einen statischen Eintrag, der aktualisiert werden muss, sobald ein Anbieter seine IPs ändert. Moderne Alternativen wie SPF-Makros halten den Eintrag dynamisch und bleiben gleichzeitig unter dem Limit.

• Über
• Neueste Beiträge

Ahona Rudra

Experte für Domain- und E-Mail-Sicherheit bei PowerDMARC

Ahona ist Marketing-Managerin bei PowerDMARC und verfügt über mehr als 5 Jahre Erfahrung im Schreiben über Cybersicherheitsthemen, insbesondere im Bereich Domain- und E-Mail-Sicherheit. Ahona hat einen Postgraduierten-Abschluss in Journalismus und Kommunikation und ist seit 2019 in der Sicherheitsbranche tätig.

Neueste Beiträge von Ahona Rudra (alle anzeigen)

• Office 365-Anti-Phishing-Richtlinie: So konfigurieren Sie sie – 3. Juni 2026
• Sicherheit bei KI-Agenten: Risiken, bewährte Verfahren und E-Mail-Authentifizierung – 2. Juni 2026
• PowerDMARC lässt sich nun in HaloPSA integrieren – 1. Juni 2026