So funktioniert’s
Ein SPF-Record ist ein TXT-Record direkt auf der Domain, der mit v=spf1 beginnt, zum Beispiel v=spf1 ip4:203.0.113.10 include:_spf.google.com -all. Über Mechanismen wie ip4, ip6, a, mx und include zählt er die Server auf, die für die Domain senden dürfen. Beschrieben ist das Verfahren in RFC 7208.
Der empfangende Mailserver nimmt die Domain aus der Rücklaufadresse (Envelope-From, im Kopf als Return-Path sichtbar), holt deren SPF-Record und prüft, ob die einliefernde IP-Adresse darin vorkommt. Der Mechanismus all am Ende regelt alle übrigen Server: -all heißt Fail, ~all Softfail, ?all neutral, und +all erlaubt schlicht jedem den Versand.
Jedes include, a, mx, ptr, exists und redirect kostet eine DNS-Abfrage, auch verschachtelt in den Includes der Dienstleister. Mehr als 10 solcher Lookups oder mehr als ein SPF-Record auf derselben Domain führen beim Empfänger zum dauerhaften Fehler (permerror), und SPF gilt als nicht bestanden.
SPF prüft nicht die Absenderadresse, die im Mailprogramm angezeigt wird. Erst DMARC verknüpft das SPF-Ergebnis mit der sichtbaren From-Adresse.
Warum gefährlich
Ohne SPF oder mit +all bzw. ?all kann jeder Server Mails mit der Rücklaufadresse deiner Domain einliefern, und der Empfänger hat keinen technischen Grund, sie abzulehnen. Gmail, Yahoo und Microsoft verlangen von Absendern inzwischen SPF oder DKIM; fehlt beides, landen auch echte Mails im Spam oder werden abgewiesen.
Häufiger als ein fehlender Record ist ein kaputter: ein zweiter SPF-Record, den der neue Newsletter-Dienst verlangt hat, ein Tippfehler im Include oder das elfte Lookup durch ein zusätzliches Tool. Dann besteht SPF für alle Mails der Domain nicht mehr – oft unbemerkt, bis Kunden nach Mails im Spam-Ordner fragen.
So vermeidest du es
- Pro Domain genau einen TXT-Record mit v=spf1 pflegen und neue Versanddienste dort ergänzen, statt einen zweiten Record anzulegen.
- Den Record mit -all abschließen, sobald alle legitimen Absender drinstehen; ~all nur für die Übergangszeit nutzen.
- Vor jedem neuen include die Lookups zählen, nicht mehr genutzte Dienste entfernen und feste Server lieber als ip4 oder ip6 eintragen.
- Domains und Subdomains, die keine Mails versenden, mit v=spf1 -all absichern.
- Auf den ptr-Mechanismus verzichten, RFC 7208 rät ausdrücklich davon ab.
- Nach jeder Änderung über jeden Versandweg eine Testmail schicken (Postfach, Shop, Kontaktformular, Newsletter) und das SPF-Ergebnis prüfen.
So erkennt DomainWarn es
Der SPF-Check fragt den TXT-Record der Domain ab, zerlegt ihn und verfolgt alle Includes bis in die Tiefe. Er meldet einen fehlenden Record, mehrere SPF-Records (kritisch, weil Empfänger permerror werten), Syntaxfehler, Includes ohne SPF-Record, nicht auflösbare oder im Kreis verweisende Includes und mehr als 10 DNS-Lookups; bei 9 oder 10 Lookups gibt es einen Hinweis. Endet der Record mit +all, ?all oder ganz ohne all, ist er „zu freizügig“, ~all ist ein Hinweis, der ptr-Mechanismus eine Warnung.
Daraus entstehen Incidents wie „SPF fehlt“, „Mehrere SPF-Records“, „SPF fehlerhaft“, „SPF: zu viele DNS-Lookups“ und „SPF zu freizügig“. Die Änderungserkennung meldet außerdem, wenn der Record geändert, abgeschwächt oder entfernt wird; ein entfernter SPF-Record ist eine kritische Änderung. Auf einer Subdomain ist ein fehlender Record nur ein Hinweis.
Liegt eine Domain über dem Lookup-Limit, kann DomainWarn den Record per SPF-Flattening in ip4- und ip6-Netze auflösen und aktuell halten. Ob eine bestimmte Mail SPF tatsächlich besteht, zeigt der Mail-Test.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.