SPF-Flattening durch DomainWarn
Ein SPF-Record darf beim Auswerten höchstens zehn DNS-Lookups auslösen (RFC 7208). Jedes include, a, mx und redirect zählt, die includes der eingebundenen Dienste mit: Google Workspace, Microsoft 365, ein Newsletter-Tool und ein Ticketsystem sind schnell darüber. Dann werten Empfänger den Record als Fehler (PermError) – und Mails, die eigentlich durchgehen sollten, scheitern an SPF.
DomainWarn flacht den Record ab: Es löst jedes include, a, mx und redirect rekursiv in die Netze auf, die sie erlauben, entfernt Doppelte, fasst benachbarte Netze zusammen und veröffentlicht das Ergebnis als _spf.kunde.de. Passt es nicht in einen Record (höchstens 450 Zeichen, damit die Antwort auch per UDP ganz ankommt), teilt DomainWarn es auf _spf.kunde.de, _spf1.kunde.de, _spf2.kunde.de …, jeder Teil bindet den nächsten ein. Der SPF-Record der Domain wird dann zu v=spf1 include:_spf.kunde.de -all – mit dem all des Originals – und braucht einen Lookup je Teil statt zwölf oder fünfzehn.
Im Reiter „E-Mail“ einer Domain öffnest du „SPF-Flattening“. Schon vor dem Einschalten zeigt die Karte, was herauskäme: Lookups vorher und nachher, die Records und den neuen SPF-Record der Domain. „Von DomainWarn abgeflacht“ unter „Verwaltung“ schaltet es ein (ab dem Tarif Freelancer). Die Quelle ist der SPF-Record, der gerade an der Domain steht; nach dem Umstellen trägst du neue Dienste in der Karte unter „Quelle“ ein. Ändert der Kunde seinen Record an der Domain wieder selbst (ohne den Verweis), übernimmt DomainWarn ihn als neue Quelle.
_spf.kunde.de. TXT "v=spf1 ip4:35.190.247.0/24 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip6:2001:4860:4000::/36"
kunde.de. TXT "v=spf1 include:_spf.kunde.de -all"Per Klick statt abtippen: Ist die Zone über eine Integration verbunden (Cloudflare, Hetzner DNS, IONOS, netcup, INWX oder Route 53), legt „Mit Cloudflare einrichten“ (bzw. mit dem jeweiligen Anbieter) erst die Teile unter _spf an und ersetzt danach den SPF-Record der Domain. Den bisherigen SPF-Record ersetzt DomainWarn nur nach ausdrücklicher Bestätigung; andere TXT-Records an der Domain (etwa Verifizierungen) bleiben unberührt. Scheitert ein Teil, bleibt der alte SPF-Record stehen – der neue zeigte sonst ins Leere.
Die Dienste ändern ihre Netze gelegentlich. DomainWarn löst den Record deshalb täglich und nach jeder SPF-Prüfung neu auf; jede Änderung steht im Verlauf der Karte und als „Abgeflachter SPF-Record aktualisiert“ mit den hinzugekommenen und weggefallenen Netzen in der Zeitleiste. Mit „DNS-Record bei Änderungen automatisch nachziehen“ stellt DomainWarn die Teile unter _spf selbst um (auch einen neuen Teil, wenn mehr Netze dazukommen) – den SPF-Record der Domain fasst das Nachziehen nie an. Ohne Integration meldet DomainWarn „Abgeflachter SPF-Record veraltet“ mit dem neuen Inhalt zum Kopieren, sobald der Verweis an der Domain steht und die Teile nicht mehr passen. „Jetzt neu auflösen“ in der Verwaltung stößt das sofort an.
Nicht alles lässt sich abflachen. Makros (%{i}, %{d} …), exists und ptr hängen vom einzelnen Absender ab und lassen sich nicht als feste Netze ausdrücken; ein Mechanismus mit anderem Qualifier als + vor dem all verlöre seine Reihenfolge. Dann sagt die Karte, welcher Teil das ist, und die Funktion lässt sich nicht einschalten. Dazu kommen Grenzen gegen ausufernde Records: höchstens zehn DNS-Mechanismen je Ebene, fünf Ebenen Tiefe, 64 Netze nach dem Zusammenfassen. Netze größer als /16 (IPv4) bzw. /32 (IPv6) übernimmt DomainWarn, nennt sie aber als Hinweis – meist steckt dahinter ein Tippfehler oder ein sehr großzügiger Dienst.
Ausschalten geht erst, wenn an der Domain wieder ein eigener SPF-Record steht: Bindet er noch _spf.kunde.de ein, blieben die Netze sonst eingefroren. Die Records unter _spf lässt DomainWarn beim Ausschalten stehen. Der SPF-Check prüft weiterhin von außen, wie viele Lookups der Record tatsächlich auslöst.
Siehe auch: SPF-Record prüfen · Was geprüft wird