Leitfaden zur SPF-Record-Syntax: Komponenten, Regeln, Beispiele und Validierung

Wenn Sie sich schon einmal gefragt haben, warum einige Ihrer legitimen E-Mails im Spam-Ordner landen oder gar blockiert werden, könnte das Problem an der Konfiguration der E-Mail-Authentifizierung Ihrer Domain liegen. Ein entscheidender Faktor hierbei ist die Syntax des SPF-Eintrags, die eine entscheidende Rolle dabei spielt, zu überprüfen, ob Ihre E-Mails von autorisierten Servern versendet werden. SPF trägt zwar dazu bei, dass Ihre Nachrichten nicht als verdächtig markiert werden, doch die Syntax kann schwer zu verstehen und noch schwieriger korrekt zu konfigurieren sein. 

In diesem Beitrag erklären wir Ihnen, wie die Syntax von SPF-Einträgen funktioniert und was Sie bei der Einrichtung für Ihre Domain beachten sollten.

Was ist die SPF-Record-Syntax?

Die Syntax eines SPF-Datensatzes ist eine Reihe von Regeln, die festlegen, wie ein SPF-Datensatz (Sender Policy Framework) im DNS einer Domäne geschrieben wird. Einfach ausgedrückt ist dies die "Sprache", die Ihre Domäne verwendet, um empfangenden E-Mail-Servern mitzuteilen, welche Quellen berechtigt sind, E-Mails in ihrem Namen zu versenden.

Die Syntax eines SPF-Eintrags umfasst in der Regel Mechanismen (wie z. B. „ip4“, „ip6“ oder „include“), Qualifizierer (wie z. B. „+“, „-“, „~“ oder „?“) und Modifikatoren, die gemeinsam bestimmen, ob eine eingehende E-Mail die SPF-Prüfung besteht oder nicht.

Die Kenntnis dieser Syntax ist von entscheidender Bedeutung, denn schon ein kleiner Fehler, wie ein zusätzliches Leerzeichen, ein falscher Qualifier oder ein fehlender Mechanismus, kann dazu führen, dass Ihre E-Mails bei der Authentifizierung scheitern und im Spam landen oder zurückgewiesen werden.

Hinweiszur DMARC-Übereinstimmung: SPF überprüft die Absenderdomain des Umschlags, nicht immer die sichtbare „Von“-Adresse, die Nutzer in ihrem Posteingang sehen. Damit DMARC über SPF erfolgreich ist, muss die Domain im „Return-Path“ mit der sichtbaren „Von“-Domain übereinstimmen. Aus diesem Grund sollte SPF mit DKIM und DMARC kombiniert werden.

Aufbau und Bestandteile der SPF-Eintragssyntax

Ein SPF-Eintrag besteht aus vier Hauptteilen: dem Versionskennzeichen, den Mechanismen, den Qualifizierern und den Modifikatoren. Jeder Teil erfüllt eine eigene Funktion, und zusammen bestimmen sie, wie empfangende Mailserver E-Mails behandeln, die angeblich von Ihrer Domain stammen.

Versions-Tag

Das Versions-Tag ist der Ausgangspunkt eines SPF-Eintrags. Es kennzeichnet den Eintrag als solchen, der die SPF-Syntax verwendet, und stellt sicher, dass Mailserver den nachfolgenden Text korrekt interpretieren. Ohne dieses Tag funktioniert der Eintrag nicht. Es ist nur ein Versions-Tag zulässig, und es muss ganz am Anfang des Eintrags stehen. Derzeit gültiges Format: v=spf1.

SPF-Qualifizierer: +, -, ~ und ?

Qualifizierer sind Symbole, die vor Mechanismen stehen. Sie geben dem empfangenden Mailserver Anweisungen, wie er vorgehen soll, wenn der Mechanismus zutrifft. Wird kein Qualifizierer angegeben, ist die Standardaktion „Pass“.

SPF-Mechanismen: all, ip4, ip6, a, mx, exists und include

Mechanismen sind die wichtigsten Regeln in einem SPF-Eintrag. Sie legen fest, welche Server, IP-Adressen oder Domänen berechtigt sind, E-Mails im Namen der Domäne zu versenden. Jeder Mechanismus wird der Reihe nach von links nach rechts überprüft, und wenn eine Übereinstimmung gefunden wird, wird der zugehörige Qualifizierer angewendet.

Der „all“-Mechanismus: -all vs. ~all vs. ?all

-all (Hard Fail): Jeder nicht aufgeführte Absender wird ausdrücklich abgelehnt. Verwenden Sie diese Einstellung, sobald Ihr SPF-Eintrag vollständig getestet wurde und alle legitimen Absender enthalten sind. Dies ist die empfohlene Einstellung für eine strenge Durchsetzung.

~alle (SoftFail): Nicht gelistete Absender werden akzeptiert, aber markiert. Verwenden Sie diese Option während der Testphase oder bei der schrittweisen Einführung, wenn Sie noch nicht sicher sind, ob alle legitimen Absender gelistet sind.

?all (Neutral): Auf nicht gelistete Absender wird keine Richtlinie angewendet. Dies bietet keinen wirklichen Schutz und wird für den produktiven Einsatz nicht empfohlen.

+all (Alle weiterleiten): Erlaubt jedem Server, in Ihrem Namen zu senden. Dies ist gefährlich und sollte niemals verwendet werden.

SPF-Modifikatoren: redirect und exp

redirect= (Modifikator): Verlagert die gesamte Auswertung der SPF-Richtlinie auf eine andere Domäne. Im Gegensatz zu „include“ ersetzt „redirect“ den aktuellen Eintrag vollständig und kann nicht mit einem „all“-Mechanismus kombiniert werden. Der SPF-„include“-Mechanismus funktioniert anders. Er fügt autorisierte Absender aus dem SPF-Eintrag einer referenzierten Domäne hinzu, ohne Ihren eigenen zu ersetzen.

exp= (Modifikator): Stellt eine benutzerdefinierte Erläuterung für SPF-Fehler bereit. Wenn eine Nachricht die SPF-Prüfung nicht besteht, kann der empfangende Server diesen TXT-Eintrag abfragen, um einen für Menschen lesbaren Grund abzurufen.

„include“ vs. „redirect“: Der wesentliche Unterschied

Ergebnisse der SPF-Bewertung und ihre Bedeutung

Wenn ein empfangender Mailserver einen SPF-Eintrag auswertet, gibt er eines von sieben möglichen Ergebnissen zurück. Das Verständnis der einzelnen Ergebnisse hilft Domain-Inhabern dabei, Zustellungsfehler zu diagnostizieren und ihre SPF-Konfiguration zu verbessern. Strategien zur Behebung häufiger SPF-Fehler finden Sie in unserem Leitfaden zum Thema Optimierung Ihres SPF-Eintrags.

SPF Record Syntax Beispiele

Einfacher SPF-Eintrag

v=spf1 ip4:203.0.113.5 -all

v=spf1 → Versionsangabe. ip4:203.0.113.5 → autorisiert eine IPv4-Adresse. -all → alle anderen Server werden abgelehnt. Dies ist eine gängige Konfiguration für eine kleine Domain, die E-Mails von einem einzigen Server versendet.

Erweiterter SPF-Datensatz

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com

Dieser Eintrag autorisiert einen gesamten /24-IP-Bereich, zwei Absender von Drittanbietern, akzeptiert nicht aufgeführte Absender mit einem SoftFail-Flag und liefert eine benutzerdefinierte Fehlererklärung. Jeder „include“-Eintrag, jedes „a“- und „mx“-Feld sowie jeder „exists“- und „redirect“-Mechanismus löst DNS-Abfragen aus. Wenn die Gesamtzahl 10 überschreitet, gibt SPF einen PermError zurück.

Beispiel für einen SPF-Eintrag im Unternehmensbereich

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

Dieser Eintrag ist bei Organisationen üblich, die Google Workspace, Microsoft 365 und eine Bereitstellungsplattform eines Drittanbieters nutzen. Jede Hinzufügung führt zu DNS-Abfragen, daher sollten Teams die Angaben sorgfältig überprüfen, um „PermError“-Ergebnisse zu vermeiden.

Beispiel für das MSP-SPF-Management

Für MSPs, die zahlreiche Kundendomänen verwalten, besteht das Ziel nicht nur darin, einen gültigen SPF-Eintrag zu erstellen, sondern auch darin, Änderungen bei allen Kunden zu überwachen. Eine zentralisierte SPF-Validierung hilft dabei, doppelte Einträge, Risiken durch Abfragebeschränkungen und fehlerhafte Einbindungen zu erkennen, bevor es bei den Kunden zu Zustellungsproblemen kommt. Das MSP/MSSP-Partnerprogramm von PowerDMARC ermöglicht es Dienstanbietern, die Authentifizierung über alle Kundendomänen hinweg von einem einzigen Dashboard aus zu verwalten, ohne zwischen Tools wechseln oder DNS-Einträge manuell auswerten zu müssen.

Beispiele für die Syntax von SPF-TXT-Einträgen nach Anwendungsfall

Verwendung mehrerer Einbindungsmechanismen in der SPF-Record-Syntax

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

Jeder Include-Mechanismus löst mindestens eine DNS-Abfrage aus, und verschachtelte Includes führen zu weiteren Abfragen. Die Gesamtzahl über die gesamte Kette darf 10 nicht überschreiten. Die SPF-Verarbeitung wird bei der ersten Übereinstimmung beendet, daher ist die Reihenfolge entscheidend: Platzieren Sie die am häufigsten verwendeten Absender an erster Stelle. Wenn sich die Anzahl der Abfragen der 10 nähert, verwenden Sie das SPF-Flattening-Tool , um Ihren Eintrag automatisch zu optimieren. Bei komplexen Unternehmenskonfigurationen bieten SPF-Makros eine skalierbarere Alternative zum herkömmlichen Flattening, da sie zum Zeitpunkt der Auswertung dynamisch erweitert werden.

Zu viele DNS-Abfragen in SPF-Einträgen

RFC 7208 begrenzt die Gesamtzahl der DNS-Abfragen während der SPF-Auswertung auf 10. Diese Begrenzung gilt für die gesamte Abfragekette – einschließlich verschachtelter Abfragen, die durch „include“, „a“, „mx“, „exists“ und „redirect“-Mechanismen ausgelöst werden. Wird die Begrenzung überschritten, gibt der empfangende Server einen „PermError“ zurück, wodurch die SPF-Prüfung vollständig fehlschlägt. Es gibt außerdem eine weniger bekannte Einschränkung: die „2-void-Lookup“-Beschränkung. Wenn mehr als zwei DNS-Abfragen „NXDOMAIN“ zurückgeben, schlägt die SPF-Prüfung ebenfalls fehl. Eine detaillierte Anleitung zur Behebung dieses Problems finden Sie unter „So beheben Sie zu viele DNS-Lookups“.

Mechanismen, die gezählt werden: include (1 + verschachtelt), a (1), mx (1 pro MX- und A-Lookup), exists (1), redirect (1 + verschachtelt), ptr (mehrfach – veraltet).

Mechanismen, die NICHT berücksichtigt werden: ip4 und ip6 lösen keine DNS-Abfragen aus.

So reduzieren Sie DNS-Lookups: Entfernen Sie Include-Einträge für Absender, die Sie nicht mehr verwenden. Ersetzen Sie a- und MX-Einträge nach Möglichkeit durch explizite IPv4-Adressen. Vermeiden Sie PTR-Einträge. Verwenden Sie PowerSPF (Hosted SPF) , um „Includes“ zu konsolidieren und das Limit einzuhalten, ohne manuelle DNS-Pflege durchführen zu müssen. Weitere Informationen zum Flattening-Prozess selbst finden Sie unter SPF-Flattening: Von der DNS-Überlastung zu einem optimierten SPF.

So veröffentlichen Sie einen SPF-TXT-Eintrag im DNS

Der SPF-Eintrag wird als TXT-Eintrag im DNS Ihrer Domain auf der Ebene der Root-Domain (z. B. example.com) oder der entsprechenden Subdomain veröffentlicht. Nutzen Sie unseren kostenlosen SPF-Eintragsgenerator , um vor der Veröffentlichung sofort einen gültigen Eintrag zu erstellen.

Wichtig: Eine Domain darf nur einen SPF-TXT-Eintrag haben. Das Veröffentlichen mehrerer TXT-Einträge, die mit „v=spf1“ beginnen, führt zu einem PermError.

Workflow zur Überprüfung der SPF-Syntax

Schritt 1: Erstellen Sie eine Bestandsaufnahme aller Absenderquellen – Microsoft 365, Google Workspace, CRM-Systeme, Marketing-Tools, Helpdesk-Systeme, Lohnbuchhaltung und regionale Absender.

Schritt 2: Erstellen oder aktualisieren Sie den SPF-Eintrag – Fügen Sie nur autorisierte Mechanismen und „includes“ hinzu.

Schritt 3: Anzahl der Lookups prüfen – Stellen Sie sicher, dass der Datensatz das Limit von 10 DNS-Lookups nicht überschreitet.

Schritt 4: Syntax überprüfen – Verwenden Sie ein SPF-Prüftool , um Probleme mit der Formatierung, Duplikaten und veralteten Mechanismen zu erkennen.

Schritt 5: Überwachen Sie die Authentifizierungsergebnisse – Überprüfen Sie die DMARC-Berichte, um sicherzustellen, dass legitime Absender die SPF- und DKIM-Pr üfung bestehen.

Regeln zur Syntax von SPF-Einträgen, Validierung und häufige Fehler

Beim Schreiben eines SPF-Eintrags geht es vor allem darum, Mechanismen und Qualifizierer in die richtige Reihenfolge zu bringen und sicherzustellen, dass der Eintrag tatsächlich wie vorgesehen funktioniert. Selbst kleine Syntaxfehler, wie ein fehlendes Tag oder ein zusätzliches Leerzeichen, können dazu führen, dass der Eintrag fehlschlägt und E-Mails abgelehnt oder als Spam markiert werden oder Ihre Domain anfällig für Spoofing ist.

In diesem Abschnitt werden drei wichtige Bereiche behandelt: bewährte Verfahren für die Erstellung der SPF-Syntax, häufige Fehler, die vermieden werden sollten, und die Validierung Ihres Eintrags vor der Live-Veröffentlichung.

Befolgen Sie die besten Praktiken für die SPF-Syntax

Um die SPF richtig zu gestalten, müssen einige goldene Regeln beachtet werden, damit die Aufzeichnung sowohl effektiv als auch zuverlässig ist:

• Beginnen Sie immer mit dem richtigen Versions-Tag: v=spf1.
• Grenze DNS Lookups, um das Überschreiten des 10-Lookup-Grenzezu überschreiten, was zu einem Bruch des Datensatzes führen würde.
• Verwenden Sie die include Mechanismus sorgfältig, um Schleifen oder zirkuläre Verweise zu vermeiden.
• Halten Sie die Konfigurationen so übersichtlich wie möglich – übermäßig komplexe Konfigurationen sind schwieriger zu warten und störanfälliger.
• Überprüfen Sie SPF-Einträge regelmäßig, insbesondere wenn sich Ihre E-Mail-Infrastruktur ändert oder wenn Sie Anbieter hinzufügen oder entfernen.

SPF-Syntaxverwaltung für MSPs und MSSPs

Für MSPs und MSSPs, die SPF über zahlreiche Kundendomänen hinweg verwalten, gehen die Best Practices über das Erstellen eines einzigen korrekten Eintrags hinaus. Zu den wichtigsten betrieblichen Aspekten zählen:

• Standardisierung von SPF-Vorlagen für gängige Kundenkonfigurationen (z. B. Google Workspace + Microsoft 365), um die Einarbeitung zu beschleunigen und Syntaxfehler zu reduzieren.
• Automatisierung der Überwachung der Abfrageanzahl um Benachrichtigungen zu erhalten, bevor der SPF-Eintrag eines Kunden das Limit von 10 DNS-Lookups überschreitet – insbesondere wenn Kunden neue SaaS-Tools hinzufügen.
• Nutzen Sie zentralisierte Dashboards, , um gleichzeitig über alle Kundendomänen hinweg doppelte SPF-Einträge, fehlerhafte Einbindungen oder fehlende Mechanismen zu erkennen.
• Änderungen dokumentieren immer dann, wenn ein neuer Absender zur Umgebung eines Kunden hinzugefügt wird, um einen genauen Prüfpfad für Compliance-Zwecke und zur Fehlerbehebung zu gewährleisten.

Vermeiden Sie häufige Syntaxfehler

Viele SPF-Probleme entstehen durch einfache, aber schädliche Fehler. Achten Sie auf diese Fallstricke:

• Fehlendes Versions-Tag: Jeder Datensatz muss mit v=spf1.
• Doppelte Qualifizierer: Die Verwendung von mehr als einem Qualifizierer für denselben Mechanismus ist ungültig.
• Übermäßige Mechanismen: Lange, aufgeblähte Datensätze erhöhen das Fehlerrisiko und überschreiten die DNS-Grenzwerte.
• Probleme bei der Syntaxformatierung: Falsch platzierte Leerzeichen, Tippfehler oder nicht unterstützte Zeichen können dazu führen, dass der Datensatz nicht verarbeitet werden kann.
• Mehrere SPF-Einträge: Eine Domain darf nur einen SPF-Eintrag haben – wenn mehr als einer vorhanden ist, schlägt die Validierung fehl.
• Veraltete Mechanismen: vermeiden ptr, da dies nicht mehr empfohlen wird und möglicherweise nicht von allen Servern unterstützt wird.

Denken Sie daran: Auch wenn die Absicht des Datensatzes korrekt ist, führen Syntaxfehler dazu, dass SPF vollständig fehlschlägt.

Überprüfen Sie die Syntax Ihres SPF-Eintrags

Vor der Veröffentlichung Ihres SPF-Datensatzes ist die Validierung entscheidend. Die Validierer prüfen, ob die Syntax korrekt ist und ob der Eintrag nicht die DNS-Lookup-Grenzen überschreitet oder nicht unterstützte Mechanismen enthält.

• Nutzen Sie Tools zur Überprüfung von SPF-Einträgen, wie beispielsweise den SPF-Checker von PowerDMARC SPF-Checker, um Probleme schnell zu identifizieren.
• Durch die Validierung wird sichergestellt, dass der Eintrag auf verschiedenen empfangenden E-Mail-Servern einheitlich funktioniert.
• Es wird empfohlen, neue oder aktualisierte Datensätze in einer Staging-Umgebung zu testen, bevor sie live geschaltet werden.
• Durch die regelmäßige Validierung nach Änderungen bleibt Ihre SPF-Richtlinie aktuell und funktionsfähig.

Durch die Validierung verringern Sie das Risiko, dass E-Mails nicht angenommen werden, in Spam landen oder Ihre Domäne anfällig für Spoofing ist.

SPF-Datensatz-Syntax in Aktion

Die korrekte Syntax des SPF-Eintrags ist für eine sichere E-Mail-Zustellung und den Schutz vor Spoofing von entscheidender Bedeutung. Alle Bestandteile – Versionskennzeichnung, Mechanismen, Qualifizierer und Modifikatoren – wirken zusammen und legen fest, wie Mailserver Ihre Nachrichten verarbeiten. 

Da die Verbreitung von SPF weiter zunimmt und die weltweite Erfolgsquote mittlerweile bei 80,24 % liegt, verschaffen sich Unternehmen, die in eine saubere, validierte SPF-Syntax investieren, einen messbaren Vorteil in Bezug auf Zustellbarkeit, Compliance und Sicherheitslage. 

Eine vollständige Schritt-für-Schritt-Anleitung zur Ersteinrichtung finden Sie unter Anleitung zum Einrichten von SPF-Einträgen. Um sicherzustellen, dass Sie die neuesten Compliance-Vorgaben erfüllen, lesen Sie die E-Mail-Authentifizierungsanforderungen von Google und Yahoo für 2026.

Häufig gestellte Fragen

1. Wie erstelle ich einen SPF-Eintrag?

Beginnen Sie mit „v=spf1“, fügen Sie Mechanismen zur Auflistung autorisierter Absender hinzu (z. B. „ip4:“ für bestimmte IP-Adressen oder „include:“ für Dienste von Drittanbietern) und schließen Sie mit einem Qualifizierer wie „-all“, um alles andere zu blockieren. Veröffentlichen Sie den Eintrag als einzelnen DNS-TXT-Eintrag in der Root-Zone Ihrer Domain.

2. Was passiert, wenn die Syntax meines SPF-Eintrags falsch ist?

Mailserver können Ihre E-Mails ablehnen oder als Spam kennzeichnen, und Ihre Domain wird anfälliger für Spoofing. Ein Syntaxfehler, wie beispielsweise ein fehlendes Versionskennzeichen, doppelte SPF-Einträge oder die Überschreitung des Limits von 10 DNS-Lookups, kann dazu führen, dass die SPF-Prüfung vollständig fehlschlägt.

3. Was ist ein Beispiel für einen SPF-Eintrag unter Verwendung von MX?

Ein SPF-Eintrag unter Verwendung von MX sieht wie folgt aus: v=spf1 mx -all. Damit wird nur den Mail-Exchange-Servern der Domain gestattet, E-Mails in deren Namen zu versenden.

4. Wie viele DNS-Abfragen sind in einem SPF-Eintrag zulässig?

SPF erlaubt gemäß RFC 7208 maximal 10 DNS-Abfragen pro Auswertung. Zu den gezählten Mechanismen gehören: include, a, mx, exists, redirect und ptr. Bei Überschreitung dieser Grenze gibt SPF einen PermError zurück.

5. Kann man mehrere SPF-Einträge für eine Domain haben?

Nein. Eine Domain darf nur einen einzigen SPF-TXT-Eintrag enthalten. Mehrere Einträge, die mit „v=spf1“ beginnen, führen zu einem PermError. Fassen Sie alle autorisierten Absender in einem einzigen Eintrag zusammen.

6. Was ist der Unterschied zwischen SPF -all und ~all?

-all (Hard Fail) weist die Empfänger an, E-Mails von nicht gelisteten Absendern abzulehnen. ~all (Soft Fail) weist die Empfänger an, die E-Mails anzunehmen, sie jedoch zu kennzeichnen. Verwenden Sie ~all während der Testphase und wechseln Sie zu -all, sobald alle legitimen Absender bestätigt sind.

7. Verhindert SPF allein das E-Mail-Spoofing?

Nein. SPF überprüft lediglich den Absender der E-Mail-Hülle (Return-Path), nicht die sichtbare „Von“-Adresse. Für einen umfassenden Schutz vor Spoofing und Phishing muss SPF mit DKIM und DMARC kombiniert werden.

8. Was ist SPF-Flattening und wann brauche ich es?

Die SPF-Flattening-Funktion ersetzt die „include“-Mechanismen durch die aufgelösten IP-Adressen und reduziert so die Anzahl der DNS-Abfragen. Dies ist erforderlich, wenn Ihr SPF-Eintrag die Grenze von 10 DNS-Abfragen überschreitet oder sich dieser Grenze nähert. Automatisierte Tools wie PowerSPF wickeln dies dynamisch ab.

9. Wie lange dauert es, bis ein SPF-Eintrag übernommen wird?

Die DNS-Propagierung dauert in der Regel 1 bis 4 Stunden, abhängig von Ihrem DNS-Anbieter und den TTL-Einstellungen. In manchen Fällen kann es bis zu 48 Stunden dauern. Überprüfen Sie Ihren Eintrag nach der Veröffentlichung stets.

• Ü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)

• Wiederherstellung von Exchange-Postfächern: So stellen Sie gelöschte Postfächer in Exchange Server wieder her – 22. September 2026
• DMARC-MSP-Fallstudie: Wie Presis die Zustellbarkeit der E-Mails seiner Kunden mit PowerDMARC verbessert hat – 17. September 2026
• So erkennen Sie, ob eine E-Mail gefälscht ist: Warnzeichen, auf die Sie achten sollten – 14. September 2026