SPF/DMARC/DKIM-Prüfer
Prüft veröffentlichte oder eingefügte SPF-Daten auf Syntax, Duplikate und Policy-Warnungen.
E-Mail-SicherheitSPF-Records entwerfen, die das 10-Lookup-Limit überleben
SPF scheitert selten an komplizierter Syntax. Gefährlich sind die unsichtbaren Abhängigkeiten: Ein paar harmlose Includes verbrauchen über Provider-Ketten ein festes DNS-Budget, bis Empfänger plötzlich permerror melden.
Zähle die Auswertung, nicht die sichtbaren Wörter
Das Limit umfasst zehn DNS-abfragende Terme pro SPF-Auswertung — nicht zehn Einträge im TXT-Record und auch nicht zehn einzelne DNS-Pakete. include, a, mx, ptr und exists sowie der Modifier redirect verbrauchen Budget, sobald sie ausgewertet werden. Verschachtelte Terme zählen mit. Drei Includes am Apex können deshalb schon über dem Limit liegen, wenn jeder Anbieter intern weiter delegiert. Für ergebnislose Abfragen und MX/PTR-Erweiterungen gelten zusätzliche Grenzen; kostenlos sind sie trotzdem nicht.
Zeichne zuerst den Abhängigkeitsbaum, statt Zeichen zu zählen. Löse jedes Include rekursiv auf, notiere die durch die Reihenfolge erreichbaren Zweige und ermittle den schlechtesten Pfad. Der SPF/DMARC/DKIM-Prüfer hilft beim Lesen des veröffentlichten Records und findet Syntaxfehler oder Duplikate. Die Verantwortung für den Provider-Baum nimmt er dir nicht ab. Ein Anbieter kann seine Unter-Includes ändern, ohne dass sich deine Zone bewegt. „Wir haben nur vier Includes“ ist daher keine Kapazitätsangabe. Halte je Abhängigkeit außerdem fest, welchem Dienst sie gehört und wer sie entfernen darf; sonst bleibt jeder gekündigte Anbieter aus Angst vor unbekannten Folgen für immer autorisiert.
Adressen dort, wo du die Adressen besitzt
ip4 und ip6 benötigen bei der Auswertung keinen DNS-Lookup. Für stabile ausgehende Infrastruktur unter deiner Kontrolle — etwa ein festes Relay-Netz — sind sie die sauberste Darstellung. Für die Cloud eines Dritten sind sie eine schlechte Kopie: Sobald der Anbieter einen Egress-Bereich ergänzt oder stilllegt, ist deine statische Abschrift falsch. Nutze ein Include, wenn der Provider den Versandpool betreibt und dafür ausdrücklich eine SPF-Domain veröffentlicht.
Ersetze Includes nicht durch a oder mx, nur weil der Record dadurch kürzer aussieht. Beide kosten Abfragen und koppeln die Autorisierung an DNS-Daten, die für einen anderen Zweck gepflegt werden. Eingehende MX-Server sind nicht automatisch ausgehende Sender. Auch ein Webserver gehört nicht dauerhaft per a ins SPF, bloß weil er heute noch Formularmails direkt verschickt. Autorisiere seine konkreten Egress-Adressen — oder leite diesen Verkehr endlich über die vorgesehene Mailplattform.
Flattening tauscht Lookup-Risiko gegen Drift
Beim Flattening ersetzt du Include-Bäume durch deren aktuelle Zielnetze. Das schafft Lookup-Spielraum, überträgt aber die Änderungshoheit des Providers auf dich. Ein flacher Record ist eine Momentaufnahme ohne Ablaufdatum: DNS liefert auch die gestrige Autorisierung absolut zuverlässig aus. Blindes Flattening verliert außerdem Qualifier, Reihenfolge, Makro-Logik und bedingte Zweige. Bei großen, volatilen Provider-Netzen wird aus einem Lookup-Problem schnell ein überlanger, ständig veraltender TXT-Record.
Flatten deshalb nur den stabilen Zweig, der tatsächlich Druck erzeugt, und dokumentiere seine Quelle. Ein Automatismus muss Upstream-Änderungen erkennen, den erzeugten Record vor dem Publizieren validieren und einen Rollback-Wert behalten. Leere oder kaputte Provider-Antworten dürfen den Job stoppen, nicht um drei Uhr morgens eine leere Autorisierung veröffentlichen. Plane nach dem Flattening Reserve ein. Wer exakt bei zehn landet, baut den nächsten unsichtbaren Provider-Include bereits als Störung ein. Alarmiere nicht erst beim Versandfehler, sondern sobald Upstream und publizierte Momentaufnahme länger als das vereinbarte Frischefenster auseinanderliegen.
Baue permanente Fehler gar nicht erst ein
Pro Name darf genau ein SPF-Record existieren. Einen langen Record in zwei Werte mit v=spf1 zu teilen fügt sie nicht zusammen, sondern erzeugt einen permanenten Fehler. Lange TXT-Daten dürfen innerhalb eines DNS-Records aus mehreren quoted Strings bestehen; Resolver setzen sie zusammen. Halte jeden Term begründet, ende nach bewiesener Inventur mit einem -all, und behandle die Provider-Anweisung „füge diesen SPF-Record hinzu“ immer als Merge-Request gegen die bestehende Policy.
Include-Ziele ohne SPF-Record, mit mehreren Records, kaputter Syntax oder DNS-Fehlern gehören ebenfalls auf die Fehlerliste. Ein include ist keine Textersetzung, sondern verlangt, dass die Ziel-Policy für die konkrete Client-IP auf Pass entscheidet. Zyklen und zu tiefe Ketten enden im Fehler; ein bequemes +all endet schlimmer, weil es jeden autorisiert. Prüfe den Entwurf vorab und danach die Live-Antwort. Nur der zweite Test entdeckt falsche Owner-Namen, Quoting-Pannen und Eigenheiten des DNS-Panels.
Makros und redirect sind Skalpelle
redirect= delegiert die gesamte Policy, wenn zuvor kein Mechanismus gepasst hat. Das ist sinnvoll, wenn mehrere Domains eine zentrale vollständige Policy erben sollen; es ist kein Include, und ein fehlendes Ziel endet als Fehler statt als neutrales Ergebnis. Zentralisierung spart doppelte Änderungen, erzeugt aber eine gemeinsame Ausfallzone. Der Redirect-Owner braucht denselben Change-Prozess und dasselbe Monitoring wie jede andere produktive Abhängigkeit. Prüfe delegierte Domains mit abweichenden Versandwegen besonders kritisch: Eine gemeinsame Policy vereinfacht nur dann, wenn ihre Mitglieder tatsächlich dieselbe Autorisierung brauchen.
Makros können Lookup-Namen aus Absender, Domain oder Client-IP bilden. Für bestimmte Multi-Tenant-Modelle, oft zusammen mit exists, ist das nützlich. Gleichzeitig wird der Pfad datenabhängig und im Audit schwerer greifbar. Nimm kein Makro, wenn eine Adresse oder ein Provider-Include dasselbe klar ausdrückt. Verstecke nie vertrauliche Daten in expandierten DNS-Namen: Die Queries verlassen deine Grenze. Kannst du den konkreten Namen im Incident nicht erklären, war die Konstruktion zu clever.
Ändere einen Zweig und beobachte echte Mail
Senke vor einer geplanten Migration die TTL, sichere die alte TXT-Antwort und publiziere die neue Variante mit mindestens einem freien Lookup. Frage danach über mehrere Resolver ab; deine autoritative Sicht ist nicht automatisch die Sicht jedes Empfängers. Kontrolliere erneut, dass genau ein Record existiert, und zähle den Baum rekursiv. Die MX-Record-Prüfung deckt nur die benachbarte Routing-Schicht ab: Gesunde MX-Records beweisen keine SPF-Autorisierung für ausgehende Mail.
Ein korrektes DNS-Ergebnis ist nur der Anfang. Sende über jeden legitimen Kanal und lies mit der E-Mail-Header-Analyzer die Empfänger-Evidenz: Authentication-Results, Envelope-Domain, Client-IP und DMARC-Alignment. Beobachte DMARC-Aggregatreports mindestens über einen vollständigen Versandzyklus auf neue permerror, temperror und unbekannte Quellen. Vergleiche dabei mit einer Baseline von vor dem Change; absolute Pass-Zahlen verbergen kleine, aber geschäftskritische Streams. Fertig ist der Record erst, wenn Lohnlauf, Support, Marketing und das vergessene Multifunktionsgerät weiter authentifizieren — nicht wenn der Zone-Editor den Text schluckt.