DNS-SPF-Record-Generator & Validator

DNS-SPF-Record-Generator & Validator

Erstellen und validieren Sie RFC 7208-konforme SPF-TXT-Einträge mit IPv4/IPv6-CIDR-Bereichen, MX-, A- und include-Mechanismen sowie SoftFail/HardFail-Richtlinien.

Vorlagen:
DNS-Abfragemechanismen (a, mx, include, exists)
Gängige E-Mail-DienstanbieterBeliebte E-Mail- & SaaS-Vorlagen
Autorisierte Drittanbieter-Includes (include:)
include:_spf.google.cominclude:sendgrid.net
Autorisierte IPv4-Adressen & CIDR (ip4:)
ip4:198.51.100.24/32
Autorisierte IPv6-Adressen & CIDR (ip6:)
DNS-TXT-Wert
80 chars
v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all
DNS-Eintragsparameter
Eintragstyp (TXT)TXT
Host / Subdomain (@ für Apex)@ (oder mycompany.io)
TTL (Time to Live in Sekunden)3600 (1 Stunde empfohlen)
BIND-Zonendatei-Syntax
; RFC 7208 SPF TXT Resource Record for mycompany.io
; Host/Name: @ (or mycompany.io.)
; Record Type: TXT
; TTL: 3600 seconds ({t.lbl1HourRecommended || "1 hour recommended"})

mycompany.io.    IN    TXT    "v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all"

; --- Cloudflare DNS API / Web Dashboard ---
; Type: TXT
; Name: @
; Content: v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all
; TTL: Auto (or 3600)
; Proxy status: DNS only
DNS-Lookups3 / 10 verwendetRFC 7208 Section 4.6.4
ZeichenlängeSoftFail (~all)DMARC-Ausrichtung kompatibel
DurchsetzungsrichtlinieKlasse A+ (100/100)Null Datenexfiltration

100% Client-seitige Auswertung & Datenschutz

Ihre Domänen, internen Mailserver-IPs und Versandkonfigurationen werden ausschließlich in Ihrer Browser-Sandbox verarbeitet. Es werden keinerlei DNS-Abfragen oder Infrastrukturdaten an externe Server übertragen.

RFC 7208-Konformität & 10-Lookup-Budget

Gewährleistet strikte RFC 7208-Konformität: Erkennt Überschreitungen des 10-DNS-Lookup-Limits (verhindert PermError-Zustellungsabbrüche), validiert die 255-Zeichen-Grenze und warnt vor veralteten ptr-Mechanismen.

SaaS-Vorlagen, BIND & CLI-Diagnose

Enthält praxiserprobte SaaS-Vorlagen für Google Workspace, Microsoft 365, SendGrid, Amazon SES und Mailgun. Exportiert saubere DNS-TXT-Einträge, BIND-Syntax und CLI-Prüfbefehle (dig/nslookup).

Technische Referenz & Architektur-Leitfaden

DNS SPF (Sender Policy Framework) Record Builder & Explainer — Referenz-Leitfaden

Erstellen und validieren Sie RFC 7208-konforme SPF-TXT-Einträge mit IPv4/IPv6-CIDR-Bereichen, MX-, A- und include-Mechanismen sowie SoftFail/HardFail-Richtlinien.

Wichtige Parameter & Steuerelemente

all-Mechanismus-Richtlinie (~all / -all / ?all / +all)enum ('~all' | '-all' | '?all' | '+all')

Definiert die Richtlinie für nicht übereinstimmende Absender-IP-Adressen. '~all' (SoftFail) akzeptiert Nachrichten mit Sicherheitskennzeichnung; '-all' (HardFail) weist empfangende MTAs an, nicht autorisierte E-Mails strikt abzulehnen.

Standard: ~all
Include-Mechanismen (include:domain)string[] (durch Leerzeichen getrennte FQDNs)

Autorisiert externe E-Mail-Dienste (z. B. Google Workspace, SendGrid, Microsoft 365) durch Abfrage deren veröffentlichter SPF-Einträge. Jeder include-Mechanismus verbraucht mindestens eine DNS-Abfrage des RFC 7208-Limits von 10.

Standard: _spf.google.com
IPv4-Adressen & CIDR-Bereiche (ip4:ip/cidr)string[] (IPv4 / CIDR-Notationen)

Gibt explizite statische IPv4-Adressen oder CIDR-Subnetze an, die zum E-Mail-Versand autorisiert sind. Werden direkt ohne DNS-Abfragen ausgewertet.

Standard: 192.0.2.1/32
IPv6-Adressen & CIDR-Bereiche (ip6:ip/cidr)string[] (IPv6 / CIDR-Notationen)

Definiert statische IPv6-Adressen oder /64-/48-CIDR-Blöcke für den ausgehenden Mailversand. Verbraucht keine DNS-Lookup-Kontingente.

Standard: 2001:db8::/32
MX-Mechanismus (mx / mx:domain)boolean | string (optionaler FQDN)

Autorisiert die IP-Adressen der Mail-Exchange-(MX)-Server der Domain zum E-Mail-Versand. Verbraucht DNS-Abfragen für die MX-Auflösung sowie anschließende A/AAAA-Lookups.

Standard: false
A-Mechanismus (a / a:domain)boolean | string (optionaler FQDN)

Autorisiert die primären Host-IPs der A- bzw. AAAA-Einträge der Domain. Ideal, wenn Webserver direkt über Postfix oder Sendmail Systemnachrichten versenden.

Standard: false

Profi-Tipps & Best Practices

RFC 7208 Abschnitt 4.6.4 beschränkt

RFC 7208 Abschnitt 4.6.4 beschränkt die Auswertung von SPF-Einträgen auf maximal 10 iterative DNS-Abfragen (über include, a, mx, ptr, exists). Mehr als 10 Lookups führen unmittelbar zu einem 'PermError', wodurch Mailprovider wie Gmail oder Microsoft Mails als unauthentifiziert ablehnen. Verwenden Sie bei Bedarf SPF-Flattening.

Erstellen Sie niemals mehrere

Erstellen Sie niemals mehrere TXT-Einträge, die mit 'v=spf1' beginnen, auf derselben Host- oder Stamm-Domain. Laut RFC 7208 Abschnitt 3.2 muss ein empfangender MTA bei Erkennung mehrerer SPF-Einträge die Auswertung sofort mit einem 'PermError' abbrechen. Führen Sie alle Versender in einem einzigen TXT-Eintrag zusammen.

Bei der Einführung von DMARC

Bei der Einführung von DMARC (p=reject oder p=quarantine) empfiehlt es sich, im SPF-Eintrag '~all' (SoftFail) statt '-all' beizubehalten. Da SPF bei E-Mail-Weiterleitungen oft bricht, verhindert '~all' fälschliche Ablehnungen, solange die Nachricht über eine intakte DKIM-Signatur authentifiziert wird.

Der 'ptr'-Mechanismus gilt laut RFC

Der 'ptr'-Mechanismus gilt laut RFC 7208 als veraltet und ineffizient, da er umfangreiche Reverse-DNS-Lookups erzwingt, die von vielen MTAs ignoriert werden. Die Richtlinie '+all' autorisiert das gesamte Internet, in Ihrem Namen E-Mails zu versenden, und stellt eine gravierende Sicherheitslücke dar.

Häufige Fallstricke & Fehlerbehebung

Empfangende Mailserver weisen E-Mails mit '550 5.7.23 SPF PermError: too many DNS lookups' ab

Überprüfen Sie Ihren SPF-Eintrag auf verschachtelte 'include:'-Mechanismen. Viele SaaS-Dienste verbrauchen intern mehrere DNS-Lookups. Entfernen Sie ungenutzte Dienste, überführen Sie statische Adressbereiche in direkte 'ip4:'/'ip6:'-Mechanismen oder verlagern Sie Marketing-Mails auf dedizierte Subdomains (z. B. news.example.com).

DNS-Validatoren melden 'SPF PermError: duplicate SPF records found'

Führen Sie im Terminal 'dig +noall +answer TXT example.com' aus, um alle vorhandenen TXT-Einträge einzusehen. Wenn mehr als ein Eintrag mit 'v=spf1' existiert, löschen Sie das Duplikat und vereinigen Sie alle 'include:'-, 'ip4:'- und 'ip6:'-Werte in einem einzigen konsolidierten TXT-Eintrag.

Automatisch weitergeleitete E-Mails scheitern an der SPF-Prüfung beim Endempfänger

SPF validiert die IP-Adresse des Envelope-Senders (RFC 5321 Return-Path). Bei automatischer Weiterleitung stimmt die IP des Weiterleitungsservers nicht mit dem SPF-Eintrag der Absenderdomain überein. Konfigurieren Sie DKIM-Signaturen und DMARC-Alignment, damit weitergeleitete E-Mails über DKIM erfolgreich validiert werden.

Häufig gestellte Fragen (FAQ)

Was ist SPF und wie schützt es vor E-Mail-Spoofing und Phishing?▼

Das Sender Policy Framework (SPF, RFC 7208) ist ein DNS-basiertes Protokoll zur Absenderauthentifizierung. Domaininhaber hinterlegen im DNS autorisierte Server-IPs. Der empfangende Mailserver prüft bei Verbindungsaufbau, ob die sendende IP-Adresse im SPF-Eintrag der Envelope-Return-Path-Domain autorisiert ist. Unberechtigte Server werden abgewiesen oder markiert.

Worin liegt der Unterschied zwischen SoftFail (~all) und HardFail (-all)?▼

'-all' (HardFail) instruiert den empfangenden Server, E-Mails von nicht autorisierten IPs strikt abzulehnen (Reject). '~all' (SoftFail) signalisiert, dass unautorisierte E-Mails zwar angenommen, aber als verdächtig markiert oder in den Spamordner verschoben werden sollen. In modernen DMARC-Umgebungen wird '~all' bevorzugt, um Fehlalarme bei Weiterleitungen zu minimieren.

Warum wird das Limit von 10 DNS-Lookups so strikt erzwungen?▼

RFC 7208 begrenzt die DNS-Abfragen auf maximal 10, um Denial-of-Service-Angriffe (DoS) und DNS-Amplification auf E-Mail-Infrastrukturen zu verhindern. Ohne dieses Limit könnten manipulierte SPF-Einträge unendliche Kaskaden von DNS-Abfragen auslösen. Eine elfte DNS-Abfrage erzeugt automatisch einen fatalen SPF PermError.

Prüft SPF die im E-Mail-Client sichtbare 'Von'-Adresse (From-Header)?▼

Nein. SPF prüft ausschließlich die technische Envelope-Sender-Adresse (RFC 5321 Return-Path), nicht den im Mailclient angezeigten Header (RFC 5322 From). Angreifer können daher eine sichtbare Absenderadresse fälschen, während der technische Umschlag SPF besteht. Um diese Lücke zu schließen, ist DMARC (RFC 7489) erforderlich, das die Übereinstimmung beider Adressen erzwingt.

Erben Subdomains automatisch den SPF-Eintrag der Hauptdomain?▼

Nein, Subdomains erben SPF-Einträge nach RFC 7208 nicht automatisch. Die SPF-Prüfung erfolgt exakt auf dem im Return-Path angegebenen Hostnamen. Wird eine E-Mail von 'newsletter.example.com' versendet, muss für diese Subdomain ein eigener SPF-TXT-Eintrag existieren, andernfalls schlägt die Auswertung mit 'None' fehl.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →