SPF-Eintrag prüfen

Was ist ein SPF-Record?

SPF (Sender Policy Framework) ist ein TXT-Record im DNS deiner Domain, der festlegt, welche Server E-Mails im Namen dieser Domain versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die absendende IP-Adresse im SPF-Record der Absenderdomain steht. Steht sie dort nicht, gilt die Mail als verdächtig und landet je nach Policy im Spam oder wird abgelehnt.

SPF ist neben DKIM und DMARC eine der drei Säulen der E-Mail-Authentifizierung. Seit 2024 verlangen Google und Yahoo von Massenversendern, dass SPF und DKIM eingerichtet sind und DMARC mindestens mit p=none existiert. Ohne SPF landen Newsletter, Rechnungen und Systemmails zunehmend im Spam.

So liest du das Ergebnis

Der Checker zeigt den gefundenen Record, zerlegt ihn in Mechanismen und bewertet drei Dinge: Ist die Syntax gültig, wie viele DNS-Lookups erzeugt der Record nach Auflösung aller Includes, und wie streng ist der Abschluss.

• v=spf1: Versionstag, muss am Anfang stehen.
• include:domain: Bindet den SPF-Record eines Dienstleisters ein, z.B. _spf.google.com für Google Workspace oder spf.protection.outlook.com für Microsoft 365. Jedes include kostet einen DNS-Lookup, plus die Lookups, die der eingebundene Record selbst erzeugt.
• a und mx: Erlauben die A- beziehungsweise MX-Server der Domain. Beide kosten je einen Lookup.
• ip4 und ip6: Erlauben feste Adressen oder Netze. Kosten keinen Lookup und sind deshalb die sparsamste Variante.
• -all: Hard Fail, alle anderen Absender sind nicht autorisiert. Empfohlen.
• ~all: Soft Fail, andere Absender sind verdächtig, werden aber meist angenommen. Guter Zwischenschritt.
• ?all oder +all: Neutral beziehungsweise alles erlaubt. Bietet keinen Schutz.

Das 10-Lookup-Limit

RFC 7208 begrenzt die Anzahl der DNS-Abfragen, die ein empfangender Server zur Auswertung eines SPF-Records durchführen darf, auf zehn. Mechanismen wie include, a, mx, ptr, exists und der Modifier redirect zählen; ip4 und ip6 nicht. Wird das Limit überschritten, antwortet der Empfänger mit permerror und behandelt den Record so, als gäbe es keinen. Genau dann landen Mails im Spam, obwohl ein SPF-Record vorhanden ist.

Die häufigste Ursache ist Wildwuchs: Google Workspace (drei Lookups), Microsoft 365 (zwei), ein Newsletter-Tool, ein CRM, ein Ticketsystem und der alte Hoster, den niemand entfernt hat. Der Checker löst jedes include rekursiv auf und zeigt, welcher Dienst wie viele Lookups verbraucht, damit du gezielt aufräumen kannst.

Häufige Fehler

Diese Probleme sehen wir beim Prüfen von Kundendomains am häufigsten:

• Mehrere SPF-Records: Zwei TXT-Records mit v=spf1 sind ein permanenter Fehler. Alle Angaben gehören in einen Record.
• Mehr als zehn Lookups: siehe oben. Nicht mehr genutzte Dienste entfernen oder ip4/ip6 statt include verwenden.
• Kein all am Ende: Ohne -all oder ~all bleibt der Record wirkungslos.
• +all: Erlaubt jedem Server der Welt, im Namen der Domain zu senden.
• ptr-Mechanismus: Veraltet, langsam und von vielen Empfängern ignoriert.
• Tippfehler in Includes: Ein include auf eine Domain ohne SPF-Record ist ein Fehler.

Beispiele für gängige Anbieter

Google Workspace:

v=spf1 include:_spf.google.com -all

Microsoft 365

Microsoft 365 mit zusätzlichem Newsletter-Versand über Brevo:

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com -all

SPF dauerhaft überwachen

Ein SPF-Record ändert sich, wenn jemand einen Dienst hinzufügt, den Hoster wechselt oder ein Dienstleister seine Netze umbaut. Eine einmalige Prüfung sagt nichts über nächsten Monat. DomainWarn prüft den SPF-Record aller Kundendomains regelmäßig, erkennt Änderungen und meldet, wenn das Lookup-Limit überschritten oder der Abschluss abgeschwächt wird.

Häufige Fragen

Wie viele Lookups darf ein SPF-Record haben?

Maximal zehn. Zählen tun include, a, mx, ptr, exists und redirect, jeweils inklusive der Lookups, die eingebundene Records selbst erzeugen. ip4 und ip6 zählen nicht.

Was ist der Unterschied zwischen -all und ~all?

-all (Hard Fail) sagt Empfängern, nicht gelistete Absender abzulehnen. ~all (Soft Fail) markiert sie nur als verdächtig. Für Domains mit fertiger Konfiguration ist -all die Empfehlung, ~all eignet sich für die Einführungsphase.

Reicht SPF allein aus?

Nein. SPF schützt nur den Envelope-Absender und bricht bei Weiterleitungen. Erst mit DKIM und einer DMARC-Policy ist eine Domain gegen Spoofing geschützt.

Warum landen meine Mails trotz SPF im Spam?

Häufig wegen permerror durch mehr als zehn Lookups oder mehrere Records, wegen fehlendem DKIM oder DMARC, oder weil die absendende IP im Record fehlt. Der Checker zeigt die ersten beiden Ursachen direkt.