← Frankys Web GitHub Kontakt
Frankys Web Mailtools

E-Mail-Konfigurationen prüfen und verstehen

SPF Check

SPF-Record finden, Syntax prüfen, DNS-Lookups gegen die Grenze von 10 zählen.

Das Sender Policy Framework (SPF) ist ein TXT-Eintrag im DNS, der festlegt, welche Server im Namen einer Domain E-Mails versenden dürfen. Ein empfangender Mailserver liest den Record, vergleicht die IP-Adresse des einliefernden Servers mit den dort freigegebenen Netzen und leitet daraus ab, ob die Nachricht autorisiert ist. SPF ist neben DKIM eine der beiden Grundlagen, auf denen DMARC aufsetzt: ohne bestandenes SPF oder DKIM greift die DMARC-Policy.

Was dieses Werkzeug prüft

Es holt den v=spf1-TXT-Record der Domain, löst alle include- und redirect-Verweise rekursiv auf und zeigt den vollständigen Baum. Es zählt die Mechanismen, die einen DNS-Lookup kosten (include, a, mx, ptr, exists, redirect), prüft die Syntax jedes Terms gegen RFC 7208, erkennt Schleifen und leere Verweise (Void-Lookups) und fasst die tatsächlich autorisierten Netzblöcke zusammen. Wird zusätzlich eine sendende IP-Adresse angegeben, führt das Werkzeug die vollständige check_host()-Auswertung nach RFC 7208 §4 aus und nennt den Mechanismus, der greift.

Das Ergebnis lesen

Grün bedeutet: genau ein Record, gültige Syntax, höchstens 10 lookup-kostende Terme, ein abschließendes -all oder ~all. Eine Warnung erscheint bei ?all oder +all, bei mehr als zwei Void-Lookups oder wenn die Lookup-Zahl nah an der Grenze liegt. Ein Fehler steht für einen doppelten v=spf1-Record, für mehr als 10 Lookups (PermError) oder für ungültige Syntax. Ist eine IP gesetzt, zeigt das Ergebnis zusätzlich pass, fail, softfail, neutral, permerror oder temperror, so wie ein echter Empfänger entscheiden würde, inklusive eines aufgelösten exp=-Erklärtextes bei fail.

Grundlagen

Maßgeblich ist RFC 7208. Die Grenze von 10 lookup-kostenden Termen und die von höchstens zwei Void-Lookups stehen in §4.6.4, die Auswertungsreihenfolge in §4.6.2, der optionale exp=-Text in §6.2, die Makro-Sprache in §8. Der ältere RFC 4408 ist durch RFC 7208 abgelöst. Einen eigenen SPF-DNS-Record-Typ gibt es seit RFC 7208 nicht mehr, SPF steht ausschließlich im TXT-Record.

Typische Fehlerbilder und wie man sie behebt

  • Kein SPF-Record. Ohne v=spf1-Eintrag kann kein Empfänger die Herkunft prüfen und DMARC scheitert an der SPF-Seite. Einen Record anlegen, der alle legitimen Versandwege abdeckt (eigener Mailserver, Newsletter-Dienst, CRM, Ticketsystem) und mit -all oder ~all abschließen.
  • PermError durch zu viele DNS-Lookups. Jeder include eines großen Anbieters bringt oft schon drei bis fünf weitere Lookups mit. Nicht mehr genutzte Includes entfernen, mehrere kleine Dienste beim Anbieter zu einem Include zusammenfassen lassen (SPF-Flattening) oder statische ip4/ip6-Netze direkt eintragen, statt sie über a/mx aufzulösen.
  • Legitime Post landet im Spam. Kommt eigene Post trotz ~all oder -all nicht sauber an, fehlt meist ein Versandweg im Record. Die real sendenden IPs aus den DMARC-Aggregatberichten ablesen und im Record ergänzen. Ob danach von ~all auf -all verschärft wird, ist eine bewusste Abwägung, siehe die FAQ zu ~all und DMARC.
  • Zwei SPF-Records. Ein zweiter v=spf1-TXT-Eintrag, oft von einem alten Dienst, ergibt sofort PermError. Alle erlaubten Sender in einen einzigen Record zusammenführen, den zweiten löschen.
  • ptr im Record. Der ptr-Mechanismus ist langsam und unzuverlässig, RFC 7208 rät ausdrücklich davon ab. Durch ip4/ip6 oder einen include des Anbieters ersetzen.
  • Zu breite Freigabe. +all oder ein ganzer /8-Block erlaubt praktisch jedem Server das Senden. Auf die tatsächlich genutzten Adressen eingrenzen.

Ausführlicher Hintergrund im Blogartikel Sender Policy Framework (SPF): Wie es funktioniert und wann man es nicht nutzen sollte auf frankysweb.de.

Häufige Fragen

Was ist die 10-Lookup-Grenze bei SPF?
RFC 7208 §4.6.4 erlaubt pro Auswertung höchstens 10 DNS-Abfragen durch Mechanismen wie include, a, mx, ptr, exists und den Modifier redirect. ip4, ip6 und all zählen nicht mit. Wird die Grenze überschritten, ergibt SPF einen PermError und die Prüfung gilt als fehlgeschlagen.
SPF meldet 'too many DNS lookups', was tun?
Den aufgelösten Baum durchgehen und zählen, welcher include wie viele Lookups kostet. Ungenutzte Dienste streichen, a- und mx-Mechanismen durch feste ip4-/ip6-Netze ersetzen und den Anbieter nach einem schlankeren oder geflatteten Include fragen. Ziel sind spürbar weniger als 10 Terme, damit künftige Änderungen nicht sofort wieder anschlagen.
Unterschied zwischen ~all und -all?
~all (SoftFail) markiert nicht gelistete Absender als verdächtig, lässt sie aber meist durch. -all (HardFail) fordert die Abweisung. Beide sind zulässige Endzustände; welcher passt, hängt davon ab, ob DMARC im Einsatz ist. Ein abschließendes ?all (Neutral) oder +all (jeder darf senden) ist dagegen praktisch wirkungslos bzw. ein Fehler.
Sollte ich mit DMARC ~all oder -all verwenden?
Ohne DMARC ist -all das eigentliche Durchsetzungssignal und die strengere Wahl. Mit einer durchgesetzten DMARC-Policy (p=quarantine oder p=reject) trifft DMARC die Entscheidung anhand der Ausrichtung von SPF oder DKIM, und viele Empfehlungen raten dann zu ~all: -all lässt weitergeleitete Mail und Mailinglisten schon an der SPF-Stufe scheitern, während bei ~all die mitlaufende DKIM-Signatur die Nachricht über DMARC noch rettet. Gefälschte Mail ohne gültige, ausgerichtete Signatur fällt weiterhin durch die DMARC-Policy. -all bleibt vertretbar, ~all ist mit DMARC oft der robustere Standard.
Darf eine Domain mehrere SPF-Records haben?
Nein. Bei mehr als einem v=spf1-TXT-Record ergibt die Prüfung einen PermError. Alle erlaubten Sender gehören in einen einzigen Record. Mehrere Einträge entstehen oft, wenn ein neuer Dienst einen eigenen SPF-Record anlegt, statt den bestehenden zu ergänzen.
Reicht SPF allein gegen Spoofing?
Nein. SPF prüft nur die Envelope-Absenderdomain (MAIL FROM), nicht die im Mailprogramm sichtbare From-Adresse, und es überlebt keine Weiterleitung. Wirksamen Schutz gibt es erst mit DKIM und einer durchgesetzten DMARC-Policy (p=quarantine oder p=reject) darüber.
Was bewirkt das zusätzliche Feld 'Sendende IP'?
Nur mit gesetzter IP prüft das Werkzeug zusätzlich, wie ein echter Empfänger entscheiden würde: pass, fail, softfail, neutral, permerror oder temperror, inklusive des greifenden Mechanismus. Ohne IP bleibt es bei der reinen Syntax- und Struktur-Analyse des Records.
Was bedeutet ein 'fail'-Ergebnis mit Erklärung?
Manche Records veröffentlichen über exp= einen Erklärtext, den ein Empfänger bei fail zurückgeben würde (RFC 7208 §6.2). Dieses Werkzeug löst ihn auf, expandiert die enthaltenen Makros und zeigt ihn an, sofern vorhanden.