Kostenloser SPF-Record- Checker

Was ist SPF und warum ist es 2026 wichtig

Sender Policy Framework (SPF) ist eine der drei Säulen moderner E-Mail-Authentifizierung, neben DKIM und DMARC. Definiert in RFC 7208, lässt es einen Domain-Inhaber im DNS eine Liste autorisierter Sende-Server veröffentlichen, damit empfangende Mail-Provider verifizieren können, dass eingehende Nachrichten tatsächlich von dort kommen, woher sie zu kommen behaupten. Ohne SPF kann jeder E-Mails verschicken und sich als deine Domain ausgeben — und moderne Provider wie Gmail und Yahoo lassen unauthentifizierte Mail leise direkt in Spam fallen.

2026 ist SPF nicht mehr optional. Die Bulk-Sender-Anforderungen von Gmail und Yahoo (ausgerollt 2024 und seither verschärft) machen SPF und DKIM für jede Domain mit mehr als 5.000 Nachrichten pro Tag zur Pflicht. Microsoft 365 und Apple Mail setzen ähnliche Standards durch. Ein fehlkonfigurierter oder fehlender SPF-Record bedeutet jetzt direkt Spam-Ordner-Placement, Umsatzverlust und Markenschaden. Die gute Nachricht: SPF ist einer der günstigsten und schnellsten Zustellbarkeits-Wins — ein einzelner korrekt konfigurierter TXT-Record kann das Inbox-Placement über Nacht um 20–40% heben.

Aufbau eines SPF-Records

Jeder SPF-Record ist ein einzelner DNS-TXT-Record mit durch Leerzeichen getrennten Mechanismen. Hier ein typisches Beispiel für eine Domain, die Google Workspace und Mailgun nutzt:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — das Versionstag. Jeder SPF-Record muss damit beginnen. Es gibt kein v=spf2; das Protokoll hat sich seit über einem Jahrzehnt nicht geändert.
• ip4: / ip6: — ip4: und ip6: — explizit erlaubte IP-Adressen oder CIDR-Bereiche. ip4:203.0.113.0/24 autorisiert ein ganzes Subnetz. Das sind die günstigsten Mechanismen, weil sie null DNS-Lookups auslösen.
• include: — zieht den SPF-Record einer anderen Domain rein. include:_spf.google.com sagt Empfängern, dass sie auch Mail von jedem Server akzeptieren sollen, den Google für seine Tenants autorisiert. Jeder Include zählt als ein DNS-Lookup, und verschachtelte Includes zählen ebenfalls.
• a / mx — a und mx — autorisieren die IP-Adressen des A-Records (der Server der Website) oder der MX-Records (die eingehenden Mail-Server) der Domain. Sparsam einsetzen: Viele Domains haben Web-Server, die keine Mail senden sollten.
• Qualifier steuern das Ergebnis. ~all (Soft Fail) markiert nicht passende Mail als verdächtig, akzeptiert sie aber — nützlich beim Testen. -all (Hard Fail) weist nicht passende Mail direkt ab — die empfohlene Produktionsform. ?all (neutral) macht nichts und ist nutzlos. +all autorisiert explizit jede IP im Internet — niemals nutzen; das ist, als würdest du deine Haustür offen lassen mit einem Schild „bitte gib dich als ich aus".

5 häufige SPF-Fehler und wie du sie behebst

Zu viele DNS-Lookups (RFC-7208-Limit: 10)

SPF erlaubt maximal 10 DNS-Lookups pro Auswertung. Jeder include:, a:, mx:, exists: und redirect= zählt. Verschachtelte Includes zählen ebenfalls — wenn include:_spf.google.com selbst vier Includes enthält, sind das fünf Lookups für diesen einen Mechanismus. Das Limit zu überschreiten löst PermError aus, und die meisten Empfänger behandeln das als Hard Fail. Lösung: Audite jeden Include mit unserem SPF-Checker oben, entferne ungenutzte Anbieter, ersetze include: durch ip4:-Blöcke, wo der Anbieter statische Bereiche veröffentlicht, oder nutze einen Flattening-Service.

PermError: SPF-Record-Syntax ungültig

Häufige Syntaxfehler: das fehlende v=spf1-Präfix, Semikolons statt Leerzeichen, übrig gebliebene Zeichen aus Copy-Paste oder der Qualifier (~all) in der Mitte des Records statt am Ende. Empfänger sehen das als Konfigurationsfehler und lassen SPF direkt scheitern. Lösung: Füg den exakten Record in einen Validator ein, suche nach versteckten Unicode-Zeichen und stelle sicher, dass Mechanismen durch Leerzeichen getrennt sind und der all-Qualifier am Ende steht.

Mehrere SPF-Records (müssen zusammengeführt werden)

RFC 7208 verbietet ausdrücklich mehr als einen v=spf1-TXT-Record auf derselben Domain. Das passiert meist, wenn ein Team Google Workspace und ein anderes SendGrid hinzufügt, ohne sich abzustimmen. Empfänger, die zwei Records sehen, werfen einen PermError. Lösung: Zu einem einzigen Record kombinieren. v=spf1 include:_spf.google.com include:sendgrid.net ~all ersetzt beide einzelnen Records.

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

Forwarding zerschießt SPF

Wenn ein Empfänger deine Nachricht an eine andere Adresse weiterleitet, ändert sich die verbindende IP, aber der Return-Path bleibt deiner — und SPF schlägt am Forwarding-Hop fehl. Das ist so vorgesehen, verursacht aber False Negatives. Lösung: Verlass dich für Alignment auf DKIM (DKIM überlebt Forwarding), implementiere SRS auf ausgehenden Forwardern, die du kontrollierst, und akzeptiere, dass SPF allein nicht ausreicht — genau deshalb verlangt DMARC SPF oder DKIM, nicht beide.

Subdomain-Vererbungs-Verwirrung

SPF wird nicht vererbt. mail.example.com und example.com sind separate Hosts und brauchen separate SPF-Records. Häufiger Bug: Firma veröffentlicht SPF am Apex, aber ein Marketing-Tool sendet von updates.example.com — Empfänger sehen keinen SPF-Record auf der Subdomain und deine Mail scheitert beim Alignment. Lösung: Veröffentliche v=spf1 -all auf jeder Subdomain, die nie senden soll, und eine echte Policy auf jeder Subdomain, die sendet.

Schritt-für-Schritt-SPF-Setup

1. Alle Sende-Dienste inventarisieren

Liste jedes System auf, das Mail über deine Domain verschickt: Marketing-Plattformen (Mailchimp, HubSpot), transaktionale Provider (SendGrid, Postmark, Resend), CRMs, Support-Desks (Zendesk, Intercom), Lohnabrechnung, Zahlungsdienstleister und deine eigenen App-Server. Auch nur einen zu vergessen heißt, dass nach der Veröffentlichung deines Records legitime Mail abgewiesen wird.

2. Fail-Policy wählen (~all vs -all)

Starte für die ersten 1–2 Wochen mit ~all (Soft Fail), während du DMARC-Reports auf unerwartete Quellen beobachtest. Sobald du bestätigt hast, dass jeder legitime Sender im Record steht und DMARC-Reports 100% Pass-Rate zeigen, wechsle für maximalen Schutz auf -all.

3. Den Record konstruieren

Nutze wann immer möglich vom Anbieter veröffentlichte include:-Mechanismen (z. B. include:_spf.google.com). Für Dienste ohne Include nimm ip4: mit ihren veröffentlichten IP-Bereichen. Halte den Record unter dem 10-Lookup-Limit, indem du jeden Include und seine verschachtelten Lookups zählst. Schließ mit einem einzigen Qualifier ab — ~all oder -all — niemals beide.

4. Den TXT-Record im DNS hinzufügen

Erstelle in der Steuerungskonsole deines DNS-Providers einen neuen TXT-Record mit Host = @ (oder dem Apex deiner Domain) und Wert = den vollständigen SPF-String in Anführungszeichen. TTL 3600 (1 Stunde) ist ein guter Standard. Wenn dein DNS-Provider automatisch in Anführungszeichen setzt, nicht doppelt zitieren.

5. Validieren und überwachen

Nutze den Checker oben, um zu verifizieren, dass der Record sauber parst, der Lookup-Count unter 10 liegt und die Policy korrekt gesetzt ist. Schick dann Test-Mails an mail-tester.com und an deine eigenen Gmail/Outlook-Konten. Richte DMARC mit rua=-Reports ein, um Quellen zu erwischen, die du übersehen hast. Überwache kontinuierlich — Anbieter-IPs ändern sich, Includes kommen dazu, und ein SPF-Record, der vor sechs Monaten sauber war, kann leise kaputtgehen.

Wie du unter dem 10-DNS-Lookup-Limit bleibst

Das 10-Lookup-Limit ist die mit Abstand häufigste Ursache von SPF-Fehlschlägen bei Skalierung. Jeder include: löst eine DNS-Abfrage aus, und jeder Include, der selbst Includes enthält, löst weitere aus — Salesforces SPF kann zum Beispiel allein zu 8+ Lookups aufgelöst werden. Drei Strategien halten dich unter dem Limit. Erstens: rigoros auditieren — jeder Anbieter, den du nicht mehr nutzt, muss aus dem Record raus. Lass unseren Checker monatlich laufen und entferne tote Includes.

Zweitens: Ersetze include: durch ip4:, wo Anbieter stabile IP-Bereiche veröffentlichen. SendGrid, Mailgun und Amazon SES veröffentlichen alle statische Blöcke; ip4:198.61.254.0/24 statt include:sendgrid.net kostet null Lookups statt zwei. Der Trade-off ist Wartung — wenn der Anbieter neue IPs hinzufügt, musst du manuell aktualisieren.

Drittens: Nutze SPF-Flattening-Services (z. B. easydmarc.com, dmarcian) für unvermeidbare verschachtelte Includes. Diese Services lösen alle deine Includes in eine flache Liste von ip4:-Blöcken auf und veröffentlichen sie als einzelnen gehosteten SPF-Record, den du mit einem Include referenzierst. Nachteil ist die operative Abhängigkeit von einem Drittanbieter — prüfe sie sorgfältig und überwache auf Ausfälle.

SPF, DKIM und DMARC: Wie sie zusammenarbeiten

SPF allein reicht nicht. Die drei Protokolle bilden eine geschichtete Verteidigung: SPF authentifiziert die IP des Sende-Servers, DKIM signiert den Nachrichteninhalt kryptografisch und DMARC verbindet beide mit der sichtbaren From-Adresse und sagt Empfängern, was zu tun ist, wenn die Authentifizierung scheitert. SPF zerbricht beim Forwarding; DKIM überlebt Forwarding, ist aber schwerer einzuführen, weil es Schlüsselgenerierung und Veröffentlichung des öffentlichen Schlüssels im DNS verlangt. Zusammen besteht DMARC-Alignment, sobald entweder SPF oder DKIM besteht — die Einführung beider gibt dir Redundanz und volle Abdeckung in realen Zustell-Szenarien, in denen Forwarding, Mailing-Listen und ARC-Trust-Chains üblich sind. Ohne DMARC sind SPF und DKIM nur Diagnose-Tools; Empfänger nutzen die Ergebnisse vielleicht locker oder ignorieren sie. Mit DMARC bei p=reject committest du dich öffentlich auf deine Authentifizierungs-Policy und weist jeden Empfänger der Welt an, gespoofte Mail direkt zu verwerfen. Das ist der moderne E-Mail-Sicherheitsstandard, und er beginnt mit einem sauberen SPF-Record. Empfohlene Einführungsreihenfolge: SPF zuerst (ein TXT-Record, sofortige Wirkung), dann DKIM (Schlüsselgenerierung plus DNS), dann DMARC bei p=none mit rua=-Reports für zwei Wochen Monitoring, dann progressiv auf p=quarantine und schließlich p=reject verschärfen. Monitoring zu überspringen ist die häufigste Ursache, dass legitime Mail beim DMARC-Rollout verloren geht.

Gmail- und Yahoo-Anforderungen 2026

Seit Februar 2024 verlangen Gmail und Yahoo von allen Bulk-Sendern (5.000+ Nachrichten pro Tag an ihre Nutzer), SPF, DKIM und DMARC zu veröffentlichen, einen One-Click-Unsubscribe-Header zu pflegen (List-Unsubscribe mit Post URL) und Spam-Beschwerderaten unter 0,3% zu halten, gemessen in den Postmaster Tools. Microsoft 365 setzt ähnliche Regeln über SmartScreen durch und Apple Mail folgt DMARC strikt über iCloud und verwaltete Apple IDs. 2026 wurden diese Standards weiter verschärft: DMARC muss für unauthentifizierten Bulk-Traffic auf p=quarantine oder strenger stehen, ARC-Trust wurde der Auswertungskette für weitergeleitete Mail hinzugefügt, und Beschwerderaten über 0,1% führen schon vor der harten 0,3%-Grenze zu reduzierter Zustellung. Scheitern ist keine sanfte Warnung — deine Mail geht in Spam oder wird direkt auf der SMTP-Schicht abgewiesen. Selbst Nicht-Bulk-Sender sind zunehmend betroffen, weil Filter generalisieren: Ein B2B-Sender mit 200 E-Mails pro Tag profitiert immer noch von sauberem SPF, DKIM und DMARC, weil Gmails Machine-Learning-Klassifizierer dieselben Authentifizierungssignale wiederverwenden, um jede Nachricht zu bewerten. Fazit: SPF ist keine Best Practice mehr — es ist eine Zustellbarkeits-Voraussetzung. Lass den Checker oben heute laufen, um zu bestätigen, dass dein SPF besteht, und arbeite dann an DKIM und DMARC, um den Stack zu vervollständigen.

Verwandte Guides

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack