Nach dem Umstellen der DMARC-Richtlinie kommt Post nicht mehr an. Warum die Ausrichtung zwischen sichtbarem Absender und SPF bzw. DKIM zählt.
Aufwand:
ca. 45 Min.
Voraussetzung:
Zugriff auf die DNS-Zone der eigenen Domain, Terminal oder Eingabeaufforderung, Ein Postfach für die Auswertungsberichte
Gilt für:
DMARC nach RFC 7489
Das Symptom
Jemand hat „die E-Mail-Sicherheit verbessert“ — ein Dienstleister, ein
IT-affines Vorstandsmitglied, eine Anleitung aus dem Netz. Seitdem stimmt etwas
nicht. Die Einladung zur Mitgliederversammlung erreicht einen Teil der Empfänger
nicht mehr. Das Kontaktformular der Webseite verschickt keine Bestätigungen. Die
automatischen Rechnungen aus dem Vereinsprogramm kommen nirgends an. Manche
Empfänger bekommen alles wie immer, andere gar nichts — und Rückläufer erscheinen
nur manchmal, oft mit einer Zeile wie 550 5.7.1.
Die „Layer 8“-Wahrheit
SPF und DKIM beantworten je eine Teilfrage, und beide beantworten sie an einer
Stelle, die der Leser einer E-Mail nie zu sehen bekommt: SPF prüft die Domain aus
dem Briefumschlag, DKIM die Domain, die das Siegel angebracht hat. Was im
Mailprogramm groß als Absender steht, kann davon völlig abweichen — und tut es im
Alltag ständig, völlig legitim, sobald ein Newsletter-Dienst oder ein
Ticketsystem im Spiel ist. Genau in diese Lücke setzt DMARC seinen einzigen
wirklich neuen Gedanken: die Ausrichtung. Sie verlangt, dass die sichtbare
Absenderdomain zu dem passt, was SPF oder DKIM tatsächlich beglaubigt haben. Erst
dann gilt eine Mail als bestanden. Dazu kommt zweitens die Möglichkeit, dem
Empfänger zu sagen, was er mit dem Rest tun soll, und drittens ein
Rückmeldekanal, über den man erfährt, wer im eigenen Namen versendet.
Der Schaden entsteht fast nie durch DMARC selbst, sondern durch die Reihenfolge,
in der Menschen es einführen. Die Richtlinie ist in zwei Minuten von none auf
reject gestellt; die Bestandsaufnahme aller Systeme, die im Namen der Domain
versenden, dauert Wochen. Wer die zweite Aufgabe überspringt, merkt es oft erst
spät: Der Standard beschreibt neben der vollständigen Ablehnung mit einem
5xy-Antwortcode auch das stille Verwerfen, bei dem der Server einen 2xy-Code
zurückgibt und damit eine erfolgreiche Zustellung andeutet, die Nachricht danach
aber ohne weitere Maßnahme verwirft. Dann kommt nicht einmal ein Rückläufer.
Der Standard sieht für genau dieses Problem eine Reihenfolge vor,
und sie ist unbequem langweilig: erst beobachten, dann Berichte auswerten, dann in
Prozentschritten verschärfen. Das Feld dafür heißt pct und existiert laut RFC
ausdrücklich, weil die Aussicht auf alles oder nichts Organisationen davon abhält,
überhaupt anzufangen.
Und dann bleibt die unangenehme Nachricht, die keine Konfiguration behebt: Über
Mailinglisten und Weiterleitungen ist ein bestandenes DMARC-Ergebnis
konstruktionsbedingt nicht garantiert. Der Standard sagt das selbst. Wer eine
strenge Richtlinie fährt, entscheidet sich damit bewusst gegen bestimmte
Versandwege — das kann richtig sein, aber es sollte eine Entscheidung sein und
keine Überraschung drei Wochen später.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die eigene Richtlinie nachschlagen, bevor irgendetwas geändert wird
Die DMARC-Vorgaben eines Domaininhabers werden laut RFC 7489 als DNS-TXT-Einträge in Unterdomains namens _dmarc gespeichert; der Inhaber von example.com hinterlegt sie also in einem TXT-Eintrag unter _dmarc.example.com. Der RFC führt die Abfrage mit einem gängigen Kommandozeilenwerkzeug selbst vor. Kommt keine Antwort, gibt es keine Richtlinie — und dann ist auch nichts durch eine Verschärfung kaputtgegangen:
Sofort zurück auf Beobachtung schalten, wenn Post verschwindet
Wenn nach einer Verschärfung Mails fehlen, ist die erste Maßnahme nicht die Fehlersuche, sondern das Zurückdrehen. Der RFC hält für p=none ausdrücklich fest, dass ermittelte Richtlinien mit p=none die bestehende Behandlung von Nachrichten NICHT verändern SOLLTEN — damit Domaininhaber DMARC-Rückmeldungen erhalten können, ohne die bestehende Mailverarbeitung zu beeinträchtigen. Der Aufbau eines solchen Eintrags ist im RFC als Beispiel wörtlich abgedruckt: v ist die Version und MUSS den Wert DMARC1 haben, p ist die gewünschte Richtlinie, rua nennt die Adressen, an die zusammenfassende Rückmeldungen zu senden sind.
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" )
3.
Die Berichte wirklich auswerten, statt sie zu sammeln
Der RFC nennt als Zweck dieser Beobachtungsphase drei Punkte, und sie sind exakt die Fragen, die vor jeder Verschärfung beantwortet sein müssen: zu bestätigen, dass die legitimen Nachrichten korrekt beglaubigt werden; zu überprüfen, dass alle berechtigten Nachrichtenquellen Authentifizierungsmaßnahmen umgesetzt haben; und zu ermitteln, wie viele Nachrichten aus anderen Quellen von einer blockierenden Richtlinie betroffen wären. Der RFC empfiehlt außerdem, eigene E-Mail-Adressen zum Empfang und zur Verarbeitung der Berichte einzurichten, da diese von erheblicher Größe und die Empfangsadressen öffentlich sichtbar sind.
4.
Die Ausrichtung für jeden Versandweg einzeln prüfen
Für SPF und DKIM lässt sich die Ausrichtung getrennt streng oder entspannt einstellen; die Vorgabewerte der Felder aspf und adkim sind laut RFC jeweils r für den entspannten Modus, s steht für streng. Im entspannten Modus müssen laut RFC die organisatorischen Domains übereinstimmen; im strengen Modus zählt ausschließlich eine exakte Übereinstimmung der vollständigen Domainnamen. Der RFC illustriert das an einem Beispiel: Besteht eine Nachricht die SPF-Prüfung mit einer MAIL-FROM-Domain von cbg.bounces.example.com, während im From-Feld payments@example.com steht, gelten die Kennungen im entspannten Modus als ausgerichtet, im strengen nicht. Wer also über einen Dienstleister versendet, der eine eigene Rückweg-Domain setzt, muss auf DKIM ausweichen.
5.
Schrittweise verschärfen statt auf einen Schlag
Das Feld pct ist genau dafür gedacht. Der RFC beschreibt es als ganze Zahl zwischen 0 und 100 mit dem Vorgabewert 100 und nennt den Zweck ausdrücklich: Der Sinn des pct-Feldes liegt darin, Domaininhabern eine langsame Einführung der DMARC-Durchsetzung zu ermöglichen, denn die Aussicht auf alles oder nichts halte viele Organisationen davon ab, mit starken Authentifizierungsverfahren zu experimentieren. Der Weg führt also über none, dann quarantine mit kleinem Anteil, dann quarantine vollständig — und reject erst, wenn die Berichte über Wochen sauber sind.
6.
An die Unterdomains denken
Ein häufig übersehener Nebeneffekt: Laut RFC gilt die Richtlinie für die abgefragte Domain und für Unterdomains, sofern nicht ausdrücklich eine eigene Richtlinie für Unterdomains über das sp-Feld beschrieben wird. Wer also auf der Hauptdomain verschärft, verschärft damit zugleich für jede Unterdomain, aus der irgendein Werkzeug versendet — die Ticket-Adresse, das Wiki, der Kalenderdienst. Das sp-Feld gilt laut RFC ausschließlich für Unterdomains der abgefragten Domain und nicht für die Domain selbst.
7.
Rückläufer richtig lesen
Lehnt ein Empfänger wegen DMARC ab, geschieht das laut RFC in der Regel als vollständige Ablehnung, bei der der SMTP-Server einen 5xy-Antwortcode als Hinweis an den einliefernden Server ausgibt, dass die Übertragung fehlgeschlagen ist. Der RFC empfiehlt den Empfängern dabei, im Klartext einen Hinweis zu geben und das Wort DMARC im Antworttext unterzubringen, und führt als Beispiel eine Zeile mit 550 5.7.1 an. Findet sich das im Rückläufer, ist die Ursache eindeutig — und die Suche beim eigenen Mailserver kann entfallen. Kann ein Empfänger die Richtlinie nicht abrufen oder anwenden und stellt die Zustellung deshalb zurück, geschieht das laut RFC am besten mit einem 4xy-Antwortcode.
Häufige Fragen (FAQ)
?Was heißt Ausrichtung — ich habe doch SPF und DKIM eingerichtet?
Ausrichtung ist der Kern von DMARC und der Grund, warum korrekt eingerichtetes SPF und DKIM trotzdem nicht reichen. RFC 7489 beschreibt das Problem selbst: Die Authentifizierungsverfahren beglaubigen jeweils unterschiedliche Bestandteile einer Nachricht. DKIM beglaubigt die Domain, die eine Signatur angebracht hat, während SPF entweder die Domain aus dem MAIL-FROM-Teil oder die HELO-Domain beglaubigen kann — und diese können verschiedene Domains sein und sind für den Endbenutzer typischerweise nicht sichtbar. Der entscheidende Satz lautet: DMARC beglaubigt die Verwendung der RFC5322.From-Domain, indem es verlangt, dass sie mit einer beglaubigten Kennung übereinstimmt, also mit ihr ausgerichtet ist. Der RFC begründet die Wahl auch: Dieses Feld ist dasjenige, das Endbenutzer zur Bestimmung der Herkunft einer Nachricht verwenden, und deshalb ein bevorzugtes Angriffsziel. SPF darf also glänzend bestehen — wenn die dabei geprüfte Domain nicht zu der passt, die der Leser sieht, ist das DMARC-Ergebnis trotzdem ein Fehlschlag.
?Was bedeuten none, quarantine und reject konkret für meine Empfänger?
Der RFC definiert die drei Werte des p-Feldes wörtlich. Bei none verlangt der Domaininhaber, dass hinsichtlich der Zustellung der Nachrichten keine besondere Maßnahme ergriffen wird. Bei quarantine wünscht der Domaininhaber, dass E-Mail, die die DMARC-Prüfung nicht besteht, von den empfangenden Mailsystemen als verdächtig behandelt wird — je nach Fähigkeiten des Empfängers kann das heißen: in den Spam-Ordner legen, mit zusätzlicher Intensität prüfen und/oder als verdächtig kennzeichnen. Bei reject wünscht der Domaininhaber, dass die empfangenden Mailsysteme E-Mail ablehnen, die die DMARC-Prüfung nicht besteht, und die Ablehnung SOLLTE während der SMTP-Übertragung erfolgen. Wichtig ist die grammatische Form: Es sind Wünsche, keine Befehle. Der RFC hält ausdrücklich fest, dass empfangende Systeme E-Mail auch dann annehmen dürfen, wenn sie die DMARC-Prüfung nicht besteht und der Domaininhaber eine reject-Richtlinie veröffentlicht hat. Deshalb wirkt eine Verschärfung bei verschiedenen Anbietern unterschiedlich stark — und deshalb fällt sie oft erst spät auf.
?SPF und DKIM stimmen, trotzdem scheitern Mails über unsere Mailingliste. Was übersehe ich?
Nichts. Das ist eine bekannte und im Standard dokumentierte Grenze. RFC 7489 schreibt unter Interoperabilitätsproblemen: DMARC schränkt ein, welche Ende-zu-Ende-Szenarien überhaupt ein pass-Ergebnis erreichen können; da DMARC auf SPF und/oder DKIM angewiesen ist, gelten deren Beschränkungen ebenfalls. Und weiter: Zusätzliche DMARC-Einschränkungen treten auf, wenn eine Nachricht von manchen Mediatoren wie Mailinglisten verarbeitet wird — das Passieren eines Mediators führt oft dazu, dass entweder die Authentifizierung fehlschlägt oder die Ausrichtung verloren geht, und diese Umformungen mögen den Standards entsprechen, verhindern aber trotzdem ein DMARC-pass. Der RFC nennt zudem Post, die von berechtigten, unabhängigen Dritten versendet wird und möglicherweise nicht mit Ausrichtung verschickt wird, was ebenfalls ein pass-Ergebnis verhindert. Genau deshalb ist die Bestandsaufnahme aller Versandwege vor dem Verschärfen keine Fleißaufgabe, sondern die eigentliche Arbeit.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der eigene Mailserver kann nicht senden, empfangen geht? Viele Anbieter sperren den ausgehenden Port 25 gegen Spam — der Versand braucht einen anderen Weg.