SPF-Eintrag-Checker

Ein SPF-Record ist ein DNS-TXT-Eintrag, der die Mailserver auflistet, die berechtigt sind, E-Mails für eine Domain zu versenden. Wenn ein empfangender Server eine Nachricht erhält, schlägt er die Absenderdomain im DNS nach, findet den SPF-Record und prüft, ob die sendende IP-Adresse in dieser Liste steht. Ist das nicht der Fall, wendet der Empfänger den durch den all Mechanismus definierten Qualifier an, was dazu führen kann, dass die Nachricht abgelehnt oder markiert wird.

Die SPF-Auswertung hat ein hartes Limit von 10 DNS-auflösenden Lookups. Mechanismen wie include: , a und mx lösen jeweils einen Lookup aus, wenn ein empfangender Server deinen Record auswertet. Wer 10 überschreitet, erhält einen permerror, den viele Server als Fehler behandeln, unabhängig davon, ob die sendende IP tatsächlich autorisiert ist. Der Checker zeigt deine aktuelle Anzahl an und gibt eine Warnung aus, wenn sie 8 überschreitet, damit du noch Spielraum hast, bevor du das Limit erreichst.

Der Qualifier beim all Mechanismus legt fest, was empfangende Server mit E-Mails tun sollen, die keinem aufgeführten Absender entsprechen. Ein ~all Softfail signalisiert, dass der Domain-Inhaber die E-Mail für verdächtig hält, die endgültige Entscheidung aber dem Empfänger überlässt, weshalb viele Server sie trotzdem annehmen. Ein -all Hardfail weist Empfänger ausdrücklich an, nicht übereinstimmende E-Mails abzulehnen. Der Checker zeigt an, welchen Qualifier dein Record verwendet, und markiert Softfail als schwächere Richtlinie.

RFC 7208 legt fest, dass eine Domain höchstens einen TXT-Record haben darf, der mit v=spf1 beginnt. Wenn ein empfangender Server mehrere SPF-Records findet, kann er nicht bestimmen, welchen er verwenden soll, und muss einen permerror zurückgeben. Das bedeutet, dass legitime E-Mails abgelehnt werden können, obwohl ein gültiger Record vorhanden ist. Die Lösung besteht darin, alle autorisierten Absender in einem einzigen Record zusammenzuführen und den Duplikat zu löschen.

Dieses Tool fragt das DNS der Domain nach einem TXT-Record ab, der mit v=spf1 beginnt, und analysiert und validiert dann die Mechanismen und Qualifier in diesem Record. SPF authentifiziert die IP-Adresse des sendenden Servers. Der DKIM Checker fragt einen selektor-spezifischen DNS-Record ab und validiert den öffentlichen Schlüssel, der zur Überprüfung einer kryptografischen Signatur verwendet wird, die an den Nachrichtentext und die Header angehängt ist. Beide Records befassen sich mit unterschiedlichen Aspekten der E-Mail-Authentifizierung und werden beide für eine vollständige Einrichtung benötigt.

Der ptr Mechanismus funktioniert, indem er eine Reverse-DNS-Abfrage für die sendende IP durchführt und dann eine Forward-Abfrage, um das Ergebnis zu bestätigen. Das erfordert mehrere DNS-Abfragen, ist langsam und gilt als unzuverlässig, da Reverse-DNS-Records nicht immer vorhanden oder korrekt sind. RFC 7208 rät ausdrücklich von seiner Verwendung ab. Der Checker warnt, wenn er in einem Record vorkommt, damit du ihn durch einen präziseren Mechanismus wie ip4: oder include: ersetzen kannst.

Ja. SPF-Records werden für die genaue Domain nachgeschlagen, die in der SMTP-Envelope-Absenderadresse verwendet wird. Eine Subdomain wie mail.example.com hat ihre eigene DNS-Zone und kann einen eigenen SPF-Record haben oder auch keinen. Du kannst jeden vollständig qualifizierten Domainnamen in den Checker eingeben, und er fragt diesen spezifischen Namen ab. Wenn für die Subdomain kein Record vorhanden ist, meldet das Tool, dass kein SPF-Record gefunden wurde, anstatt auf die übergeordnete Domain zurückzufallen.

Ein dig TXT example.com Befehl gibt den rohen Record-Text zurück, macht aber nichts damit. Du müsstest dann manuell DNS-Lookups zählen, jeden Mechanismus und Qualifier identifizieren und nach bekannten Problemen suchen. Dieses Tool führt dieselbe DNS-Abfrage durch und analysiert dann automatisch jeden Mechanismus, zählt Lookups, wendet Validierungsregeln an und zeigt Fehler und Warnungen an. Es ist nützlich, wenn du eine strukturierte Analyse möchtest, ohne eigene Parsing-Logik schreiben zu müssen.

SPF prüft die Envelope-Absenderadresse, die während der SMTP-Verbindung verwendet wird, nicht den From-Header, den Empfänger sehen. Ein Angreifer kann den sichtbaren From-Header fälschen und dabei eine Domain verwenden, die für den Envelope SPF besteht. DMARC schließt diese Lücke, indem es eine Übereinstimmung zwischen der Envelope-Domain und dem From-Header vorschreibt. Für vollständigen Schutz sollte SPF mit DKIM und einer DMARC-Richtlinie kombiniert werden. Du kannst deine DMARC-Einrichtung mit dem DMARC Checker validieren.

Das Tool führt eine Live-DNS-Abfrage für die eingegebene Domain durch und gibt die Ergebnisse an deinen Browser zurück. Domainnamen, die in den Checker eingegeben werden, werden nach Abschluss der Abfrage nicht gespeichert oder protokolliert. DNS-Records sind von Natur aus öffentlich zugänglich, daher werden durch die Abfrage des SPF-Records einer Domain keine privaten Informationen preisgegeben. Die vollständigen Datenpraktiken der Website findest du auf der Datenschutzseite .

Wenn der Checker keinen v=spf1 TXT-Record findet, haben empfangende Server keine SPF-Richtlinie zur Auswertung. Die meisten behandeln dies als neutrales Ergebnis, aber einige wenden strengere Regeln an. Du solltest über deinen DNS-Anbieter einen SPF-Record hinzufügen, der alle Server auflistet, die berechtigt sind, E-Mails für deine Domain zu versenden. Ein Record wie v=spf1 -all signalisiert mindestens, dass deine Domain keine E-Mails versendet, was Spoofing für Domains verhindert, die nur zum Empfangen verwendet werden.

DNS-Änderungen werden basierend auf dem TTL-Wert (Time to Live) deines TXT-Records weitergegeben. Die meisten DNS-Anbieter setzen einen Standard-TTL von 3600 Sekunden (eine Stunde), was bedeutet, dass Resolver, die den alten Record zwischengespeichert haben, ihn bis zu dieser Dauer weiter verwenden. Nach Ablauf des TTL rufen Resolver den neuen Record ab. Du kannst den Checker nach deinem erwarteten Propagierungszeitraum erneut ausführen, um zu bestätigen, dass der aktualisierte Record aktiv ist.