DMARC

Was DMARC leistet — und was ausdrücklich nicht

DMARC verbindet den einen Bezeichner, den ein Leser tatsächlich sieht — die Domain im From-Headerfeld, RFC5322.From genannt und in DMARC-Terminologie die Author Domain, also die Domain des scheinbaren Absenders — mit Authentifizierungsergebnissen, die SPF und DKIM für völlig andere Bezeichner liefern. RFC 9989 §4.2 benennt offen, warum gerade dieses Feld gewählt wurde: Es war über die gesamte Geschichte der E-Mail hinweg trivial fälschbar, aber von allen Bezeichnern in einer Nachricht ist es der einzige, der zwingend vorhanden sein muss. SPF und DKIM authentifizieren Domains; keines von beiden ist für sich genommen mit der Domain verbunden, die Ihr Empfänger liest. DMARC ist die Bindung zwischen beidem.

Ein DMARC-Pass ist eine eng gefasste Aussage. Nach RFC 9989 §4.1 und §5.4 besagt er, dass die Verwendung der Author Domain in dieser Nachricht als vom Domaininhaber autorisiert bestätigt wurde — mehr nicht. Er enthält keine ausdrückliche oder implizite Wertaussage über die Nachricht oder über den Domaininhaber, und §4.1 ergänzt, dass die zugrunde liegenden Mechanismen ausschließlich die Verwendung einer DNS-Domain prüfen, nie den Local Part einer Adresse in der Nachricht. Eine Nachricht von ceo@example.com und eine von attacker-with-your-password@example.com sind für DMARC nicht unterscheidbar.

Die zweite Hälfte von DMARC ist das Reporting, und in der Praxis ist es die Hälfte, die die Arbeit erledigt. Aggregate-Reports geben dem Domaininhaber Einblick in alle Mail-Ströme, die die Author Domain verwenden (RFC 9989 §5.3.8), und decken nach RFC 9990 §3.1 sowohl Nachrichten ab, die die Authentifizierung bestanden haben, als auch solche, die daran gescheitert sind — gezählt über alle empfangenen Nachrichten, selbst wenn deren Zustellung am Ende durch andere Filterung unterbunden wurde. So finden Sie den Weiterleiter, das Ticketsystem und die Marketing-Plattform, von denen Ihnen niemand erzählt hat, bevor Sie auf Enforcement (die durchgesetzte Policy) umstellen.

Eine Konsequenz wird regelmäßig missverstanden, auch von Anbietern, die DMARC als Schalter verkaufen, der gefälschte Mail stoppt: p=reject ist eine Bitte, und die Spezifikation untersagt es, allein darauf zu handeln.

Ausrichtung (Alignment) — der Mechanismus, der tatsächlich entscheidet

Die meiste DMARC-Fehlersuche endet in dem Moment, in dem Sie aufhören zu fragen „ist SPF bestanden?“ und anfangen zu fragen „welche Domain hat bestanden, und ist sie ausgerichtet?“. Drei Domain-Bezeichner sind im Spiel, und häufig sind es drei verschiedene Domains in derselben Nachricht.

RFC5322.From — die Author Domain

Die Domain des scheinbaren Verfassers, entnommen aus dem From-Headerfeld (RFC 9989 §3.2.2). Der Empfänger extrahiert sie als ersten Schritt der Auswertung und wandelt ein U-Label vor der Verarbeitung in ein A-Label um; ist keine oder mehr als eine Domain vorhanden, ist eine DMARC-Prüfung nicht möglich und der Vorgang endet (§5.3.1). Dies ist das einzige Headerfeld, das DMARC zur Bestimmung der Author Domain auswertet — §2.4 führt die Auswertung von irgendetwas anderem als dem RFC5322.From-Headerfeld als außerhalb des Geltungsbereichs auf.

RFC5321.MailFrom — die SPF-Domain

Die Domain im SMTP-Kommando MAIL FROM, auch Envelope-Sender oder Return-Path genannt. SPF kann sowohl die HELO-Identität als auch die MAIL-FROM-Identität prüfen, aber §3.2.4 und §4.4.2 sind eindeutig: DMARC stützt sich ausschließlich auf die SPF-Prüfung der MAIL-FROM-Identität. Ein SPF-Pass, der über den HELO-Namen erzielt wurde, trägt zu DMARC nichts bei. Für einen leeren Return-Path verweist §3.2.4 auf die Behandlung in RFC 7208 §2.4, bei der die Identität zu postmaster an der HELO-Domain wird.

DKIM d= — die DKIM-Signaturdomain

Der Wert des d-Tags in einem DKIM-Signature-Headerfeld, dessen kryptografische Signatur gültig ist (§3.2.3, §4.4.1). Eine Nachricht kann mehrere Signaturen tragen; §4.4.1 hält fest, dass sie einen DMARC-Pass erzeugt, wenn irgendein DKIM-Authenticated Identifier zur Author Domain ausgerichtet ist.

Die Regel, die das Ergebnis entscheidet, ist kurz. Nach §5.3.5 besteht die Nachricht, wenn einer oder mehrere der Authenticated Identifiers zur Author Domain ausgerichtet sind; existiert kein Authenticated Identifier oder ist keiner davon ausgerichtet, scheitert sie. Ein ausgerichteter Bezeichner genügt — aber ein Bezeichner, der sich authentifiziert, ohne ausgerichtet zu sein, trägt überhaupt nichts bei. §4.4.1 und §4.4.2 nennen den Grund: Es gibt keinen anerkannten Mechanismus, mit dem Sie Dritte benennen könnten, die für Sie signieren oder Ihre Domain als MAIL FROM verwenden dürfen, und jeder Angreifer kann für eine von ihm kontrollierte Domain einen SPF-Record veröffentlichen oder eine Nachricht mit seinem eigenen Schlüssel signieren. Erst die Ausrichtung sorgt dafür, dass ein Authentifizierungsergebnis etwas über Ihre Domain aussagt.

Die Ausrichtung kennt zwei Modi. Zwei Domains sind relaxed ausgerichtet, wenn sie dieselbe Organisationsdomain haben (§3.2.10.1), und strict nur dann, wenn sie identisch sind (§3.2.10.2). Den Modus wählen Sie, getrennt für jeden Mechanismus, über die Tags aspf und adkim; §4.7 gibt beiden den Standardwert r, sodass ein Record, der keines der beiden Tags nennt, auf beiden Seiten relaxed ist. §4.4 merkt an, dass diese Domain-Vergleiche unabhängig von Groß- und Kleinschreibung sind, und hält fest, dass nahezu alle Domaininhaber relaxed als ausreichend empfunden haben.

Die Organisationsdomain stammt aus dem Tree Walk, nicht aus der Public Suffix List

Hier weicht das heutige DMARC von dem ab, was die meisten veröffentlichten Anleitungen noch schreiben. §3.2.14 definiert die Organisationsdomain als die Domain an der Spitze der Namensraum-Hierarchie, die sich mit der betrachteten Domain dieselbe administrative Zuständigkeit teilt, und hält fest, dass sie durch Anwendung des Algorithmus aus §4.10 bestimmt wird — des DNS Tree Walk. §4.10 hält die Vorgeschichte ausdrücklich fest: RFC 7489 beschrieb die Verwendung einer Public Suffix List, schrieb keine bestimmte Liste vor, gab keine Vorgaben zur Aktualisierung, räumte die daraus entstehenden Interoperabilitätsprobleme ein und legte nahe, dass ein zuverlässigeres Verfahren an ihre Stelle treten sollte. RFC 9989 ist dieses Verfahren.

Der Tree Walk fragt einen DMARC-Policy-Record an der Startdomain ab, entfernt dann wiederholt das linkeste Label und fragt erneut ab — begrenzt auf acht Abfragen, damit eine Author Domain mit hunderten Labels nicht als Verstärker für einen Denial-of-Service-Angriff missbraucht werden kann (§4.10). §4.10.2 wählt anschließend aus den gefundenen Records die Organisationsdomain aus: Ein Record mit psd=n entscheidet die Sache sofort; ein Record, der nicht der Start-Record ist und psd=y trägt, macht die Domain ein Label darunter zur Organisationsdomain; andernfalls gewinnt der Record, der am Namen mit den wenigsten Labels gefunden wurde. Ergibt der Vorgang nichts, ist die anfängliche Zieldomain ihre eigene Organisationsdomain.

Zwei Abkürzungen in §4.10.2 sollte man kennen, denn sie erklären, warum manche Konfigurationen billig auszuwerten sind: Es ist überhaupt keine Auswertung der Ausrichtung nötig, wenn der Policy-Record strict vorgibt, da ein Zeichenkettenvergleich genügt, und ebenso wenig, wenn die Author Domain und jeder Authenticated Identifier dieselbe Domain sind und für sie ein Policy-Record veröffentlicht ist — diese gemeinsame Domain wird dann als Organisationsdomain behandelt.

SMTP:  MAIL FROM:<bounce@mail.example.com>

Headers:
  From: Example News <news@example.com>
  DKIM-Signature: v=1; a=rsa-sha256; d=mailer.example.net; s=k1; ...

Warum SPF besteht und DMARC trotzdem scheitert

Das ist die mit Abstand häufigste Fehldeutung eines DMARC-Reports. SPF sagt Pass, der Authentication-Results-Header sagt spf=pass, und DMARC sagt Fail. Nichts ist kaputt; die beiden Mechanismen beantworten verschiedene Fragen. SPF beantwortet: „Durfte dieser Host jene Envelope-Sender-Domain verwenden?“ DMARC beantwortet: „Stimmt irgendeine authentifizierte Domain mit der Domain im From-Header überein?“

MAIL FROM:<bounces+9d21c@esp.example.net>   -> SPF checks esp.example.net  = pass
From: news@example.com                       -> Author Domain example.com
DKIM-Signature: d=esp.example.net            -> signature valid, identifier esp.example.net

example.com  -->  alumni.example.org  -->  final mailbox
                  (relays the message on, From: unchanged)

Beide Fälle sind messbar statt theoretisch: Schicken Sie eine echte Nachricht über den Weg, um den es Ihnen geht, und lesen Sie die Bezeichner direkt von der Leitung ab. Genau das tut der Sende-Test — er fängt eine von Ihnen gesendete Nachricht ab und meldet den Envelope-Sender, jedes d= in der Nachricht, die SPF- und DKIM-Ergebnisse und ob jeder Bezeichner zu Ihrer Author Domain ausgerichtet ist.

Wo der Record liegt und wie er gelesen wird

Eine DMARC-Policy ist ein einzelner DNS-TXT-Record, der unter dem Namen _dmarc vor derjenigen Domain veröffentlicht wird, für die er gilt. Für example.com lautet dieser Name _dmarc.example.com, und ein Empfänger, der die Policy einer Author Domain sucht — also der Domain im From-Headerfeld —, stellt genau für diesen Namen eine TXT-Abfrage (RFC 9989 §4.5). Einen anderen Ort sieht sich ein Empfänger nicht an: nicht den TXT-Record am Apex, nicht ein anders benanntes Label und keinen DMARC-eigenen Resource-Record-Typ. Die Abfrage gilt immer TXT unter _dmarc vor der jeweiligen Domain. Der Knotenname _dmarc ist bei der IANA für den Typ TXT im Registry „Underscored and Globally Scoped DNS Node Names" eingetragen (RFC 9989 §9.5).

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Gar keinen Record zu veröffentlichen, ist eine zulässige Haltung, und RFC 9989 §4.5 sagt das ausdrücklich: Ein Domaininhaber entzieht sich der DMARC-Prüfung durch Empfänger schlicht dadurch, dass er keinen Policy-Record veröffentlicht. Für Sie zählt dabei, dass das Fehlen eines Records und das Vorhandensein eines Records, den Empfänger verwerfen, in der Praxis dasselbe Ergebnis haben — und der zweite Fall tritt weit leichter versehentlich ein. Im Rest dieses Abschnitts geht es um die Wege, auf denen ein korrekt aussehender Record weggeworfen wird.

Ein in mehrere Strings aufgeteilter TXT-Record wird vor dem Parsen zusammengefügt

Ein TXT-Record kann aus mehr als einem Character-String-Objekt bestehen. Wo das der Fall ist, MUSS das Modul, das die DMARC-Auswertung vornimmt, diese Strings zusammenfügen, indem es die Objekte der Reihe nach aneinanderhängt und das Ergebnis als einen einzigen String parst (RFC 9989 §4.5). Das Zusammenfügen ist eine reine Verkettung — an der Nahtstelle wird nichts eingefügt.

Das ist deshalb wichtig, weil DNS-Hosting-Oberflächen einen langen Wert unterschiedlich darstellen. Manche nehmen einen einzigen langen String entgegen und teilen ihn für Sie auf; manche erwarten, dass Sie die Teile selbst eingeben. Endet ein Teil dort, wo der nächste beginnt, parst das Ergebnis sauber. Fügen Sie an einer Grenze „sicherheitshalber" ein Leerzeichen oder ein Semikolon ein, wird dieses Zeichen Teil des Record-Werts, und Sie landen womöglich bei einem Tag-Wert, den Sie nicht beabsichtigt haben.

Prüfen Sie den Record so, wie ein Resolver ihn zurückgibt, nicht so, wie Ihr DNS-Panel ihn anzeigt. Das Panel zeigt die Teile; der Empfänger sieht das Zusammengefügte.

_dmarc.example.com.  IN  TXT  "v=dmarc1; p=reject"

Dasselbe gilt für jeden Record, dessen erstes Tag ein anderes ist. Eine Reihenfolge p=reject; v=DMARC1 wird verworfen, und ebenso ein Record, bei dem der Verifizierungsstring eines Anbieters vor der Policy gelandet ist: RFC 9989 §4.10 Schritt 2 verwirft Records, die nicht mit einem v-Tag beginnen, das die aktuelle DMARC-Version bezeichnet. Das Versions-Tag ist das Tor, und alles dahinter wird nur erreicht, wenn das Tor aufgeht.

Unbekannte Tags werden ignoriert, fehlerhafte Werte fallen auf Vorgabewerte zurück

Nur Tags, die im DMARC-Tag-Registry definiert sind, sind zu verarbeiten; unbekannte Tags MÜSSEN ignoriert werden (RFC 9989 §4.7). Die formale Definition in §4.8 wiederholt die Regel und ergänzt, was mit dem Rest geschieht: Syntaxfehler im übrigen Record MÜSSEN zugunsten von Vorgabewerten verworfen werden, sofern es welche gibt, oder andernfalls schlicht ignoriert werden. §4.8 nennt auch den Grund — weil unbekannte Tags ignoriert werden müssen, lässt sich ein neues Tag registrieren, ohne eine neue DMARC-Version einzuführen und ohne ältere Implementierungen zu brechen.

Die Folge für Sie ist, dass ein falsch geschriebener Tag-Name nirgends einen Fehler erzeugt. Er erzeugt Stille. v=DMARC1; poIicy=reject — mit einem großen I anstelle des l — ist ein syntaktisch gültiger DMARC-Record mit einem unbekannten Tag und ohne Policy-Tag.

Was dann geschieht, legt RFC 9989 §4.10.1 fest. Enthält ein abgerufener Policy-Record kein gültiges p-Tag oder enthält er ein sp- oder np-Tag, das nicht gültig ist, dann gilt: Ist ein rua-Tag mit mindestens einer syntaktisch gültigen Report-URI vorhanden, MUSS der Empfänger so verfahren, als wäre ein Record mit p=none abgerufen worden, und die Verarbeitung fortsetzen; andernfalls wendet der Empfänger überhaupt keine DMARC-Verarbeitung auf die Nachricht an. Ein Tippfehler im Policy-Tag kostet Sie damit entweder Ihr Enforcement — die tatsächliche Durchsetzung der Policy beim Empfänger — oder Ihre DMARC-Auswertung insgesamt, je nachdem, ob Sie zufällig eine Report-Adresse veröffentlicht haben.

Zwei Records unter demselben Namen verwerfen einander — aber der Tree Walk geht weiter

Eine TXT-Abfrage auf _dmarc.example.com liefert eine Menge von Records zurück, und diese Menge darf legitim Records enthalten, die mit DMARC nichts zu tun haben. RFC 9989 §4.10 Schritt 2 behandelt beide Fälle der Reihe nach: Records, die nicht mit einem v-Tag beginnen, das die aktuelle DMARC-Version bezeichnet, werden verworfen; und werden für ein einzelnes Ziel mehrere DMARC-Policy-Records zurückgegeben, werden sie allesamt verworfen. Der Verifizierungsstring eines Anbieters, der neben Ihrer Policy unter demselben Namen liegt, ist harmlos, weil ihn die erste Hälfte der Regel entfernt. Ein zweiter Record, der mit v=DMARC1 beginnt, ist nicht harmlos, weil er die zweite Hälfte auslöst und Ihre echte Policy mitreißt.

Was danach geschieht, ist der Punkt, an dem RFC 9989 von der älteren RFC 7489 abweicht, und der Unterschied wird weithin falsch wiedergegeben. Nach RFC 7489 §6.6.3 Schritt 5 bedeutete eine Menge mit mehreren Records, dass die Policy-Ermittlung endete und DMARC auf die Nachricht nicht angewendet wurde — DMARC war für diese Nachricht aus. Nach RFC 9989 bleibt das Verwerfen auf diesen einen Namen beschränkt. Die Policy-Ermittlung fällt auf den DNS-Tree-Walk durch (§4.10.1): Wird bei der ersten Abfrage kein gültiger Record gefunden, geht der Empfänger nach oben und fragt _dmarc bei jedem nächsthöheren Elternteil ab — bei einer Author Domain mit mehr als acht Labels springt der Walk zuerst zu dem Vorfahren, der sieben Labels hat (§4.10 Schritt 4) — und die Schritte 5 bis 7 von §4.10 wiederholen Abfrage und Verwerfen, bis der Vorgang endet oder keine Labels mehr übrig sind.

Ein doppelter Record auf mail.example.com schaltet DMARC für diese Subdomain also nicht ab. Er nimmt der Subdomain ihre eigene Policy und übergibt die Entscheidung dem nächsten Record, der weiter oben im Baum gefunden wird — typischerweise dem Record der Organisationsdomain, dessen sp- oder np-Tag dann anstelle des p gilt, das Sie auf der Subdomain veröffentlicht haben. Das beobachtbare Ergebnis ist nicht „kein DMARC". Es ist eine andere Policy als die, die Sie geschrieben haben, angewendet aus Gründen, die am Record der Subdomain selbst nicht zu sehen sind.

Die vollständige Tag-Referenz (RFC 9989)

RFC 9989 §4.7 definiert elf gültige DMARC-Tags und sonst nichts. Die Tabelle unten gibt Status und Vorgabewert jedes einzelnen so wieder, wie die Spezifikation sie festlegt, denn beides wird regelmäßig falsch zitiert: Genau ein Tag ist REQUIRED, genau ein weiteres ist RECOMMENDED, und die übrigen neun sind OPTIONAL, mit Vorgabewerten, die darüber entscheiden, was ein unvollständiger Record bedeutet.

Vier dieser Zeilen beschreiben ein Verhalten, das eine Tabellenzelle zwar nennt, ein Leser aber gern überspringt. Es sind die, die aus einem Record am häufigsten etwas anderes machen, als er zu sein scheint.

Eine weitere Folge aus §4.7, die in keine Tabellenzelle recht hineinpasst: Nur Tags aus dem Registry werden verarbeitet, unbekannte Tags MÜSSEN ignoriert werden. Jedes Tag, das Ihnen in freier Wildbahn begegnet ist und in der Tabelle oben nicht vorkommt — Anbieter-Präfixe, Kommentar-Tags, erfundene Optionen —, wird von konformen Empfängern verworfen, bevor die Policy ausgewertet wird.

Entfernte und historische Tags

Was t=y tatsächlich ersetzt hat — und was nicht

Der mit Abstand häufigste Fehler in DMARC-Dokumentation ist die Behauptung, t=y sei der moderne Weg zu einem prozentualen Rollout. Das ist es nicht. RFC 9989 §C.5.1 trägt t mit der Beschreibung „Replacement for some 'pct' tag functionality" ein, und Anhang A.6 legt genau dar, welcher Teil gemeint ist.

Laut Anhang A.6 zeigte die betriebliche Erfahrung, dass pct in der Regel nicht genau angewendet wurde, sofern der Wert nicht 0 oder 100 war, und dass die Ungenauigkeiten bei anderen Werten von Implementierung zu Implementierung stark schwankten. Der Wert 100 war der Vorgabewert und erforderte keine gesonderte Verarbeitung. Der Wert 0 hatte eine unbeabsichtigte zweite Bedeutung angenommen: Manche Vermittler und Mailbox-Provider nutzten ihn als Signal, vom Standardverhalten abzuweichen, meist indem sie das From-Headerfeld umschrieben, um nachgelagerte DMARC-Fehlschläge zu vermeiden. Dieses Verhalten erwies sich als tatsächlich nützlich, weil ein Vergleich der Aggregate-Reports vor und nach der Veröffentlichung von pct=0 einem Domaininhaber erlaubte abzuleiten, wie viel seines Verkehrs über Vermittler läuft, die das From-Headerfeld nicht umschreiben. Anhang A.6 kommt zu dem Schluss, dass es keinen Sinn ergab, ein Tag namens pct beizubehalten, das nur zwei nützliche Werte hatte, und führt t mit den Werten y und n ein, die in ihrer Anwendung den pct-Werten 0 beziehungsweise 100 entsprechen.

Lesen Sie den Umfang davon genau. Die beiden Endpunkte wurden übernommen. Der Bereich dazwischen nicht. Es gibt in RFC 9989 kein Tag, das pct=50 ausdrückt, keine Kombination der elf gültigen Tags, die dem nahekommt, und nirgends in der Spezifikation eine Aussage, dass ein teilweiser Rollout auf anderem Weg möglich bliebe. Ein stufenweiser Rollout bewegt sich unter RFC 9989 durch die Policy-Stufen — none, dann quarantine, dann reject, wahlweise mit t=y, um jede neue Stufe eine Stufe darunter zu halten, während Sie die Reports lesen — nicht durch Bruchteile Ihres Mailstroms.

Wenn Ihr Record noch ein pct-Tag trägt

Es zu entfernen ist richtig, aber die Reihenfolge der Schritte zählt, denn Ihre Empfänger betreiben nicht alle dieselbe DMARC-Version.

Ein Empfänger, der RFC 9989 umsetzt, hat für pct keine definierte Behandlung: Es gehört nicht zu den elf gültigen Tags aus §4.7, und das Registry führt es als historic (§9.3). Für diesen Empfänger liest sich Ihr Record bereits als glattes p=reject, angewendet auf jede fehlschlagende Nachricht. Ein Empfänger, der noch RFC 7489 umsetzt, liest das Tag und wendet Ihre Policy auf den angeforderten Anteil an. Ein Record wie v=DMARC1; p=reject; pct=25 ist also kein 25-Prozent-Rollout. Er ist volles Enforcement bei jedem aktualisierten Empfänger und ein Viertel-Enforcement beim Rest, wobei die Aufteilung von den Aktualisierungsplänen anderer Leute bestimmt wird.

Das Tag zu löschen schließt diese Lücke, indem es die zweite Gruppe auf das Verhalten der ersten bringt: RFC 7489 gab pct den Vorgabewert 100, sodass ein Empfänger nach altem Stand, der das Tag nicht mehr sieht, darauf zurückfällt, Ihre Policy auf die gesamte fehlschlagende Mail anzuwenden. Die Änderung wirkt augenblicklich, und sie ist nicht graduell. War Ihre Rampe echt — schützte pct=25 also einen Mailstrom, dessen Authentifizierung Sie noch nicht abgeschlossen hatten —, dann endet dieser Schutz für den Altbestand Ihrer Empfänger genau in dem Moment, in dem Sie das Tag löschen.

Die Reihenfolge, die eine Überraschung vermeidet, lautet daher: Lesen Sie zuerst Ihre Aggregate-Reports und bestätigen Sie, dass die legitimen Quellen, die Sie kennen, ausgerichtete Passes erzeugen; nehmen Sie die aktualisierten Empfänger als Maßstab, denn sie setzen bereits vollständig durch, und ihre Reports zeigen Ihnen, was volles Enforcement kostet; entfernen Sie dann pct. Zeigen die Reports Quellen, die Sie noch nicht in Ordnung gebracht haben, ist die Antwort, p auf quarantine oder none zurückzunehmen oder t=y zu setzen und die Arbeit der Policy-Stufe zu überlassen. Diese Mechanismen sind definiert, über alle Empfänger hinweg einheitlich und in den Reports sichtbar. Ein Prozentsatz ist nichts davon mehr.

Die eine saubere Übersetzung ist pct=0 → t=y, und sie ist die einzige, die Anhang A.6 erhalten hat — über die beiden Empfängerpopulationen hinweg ist sie aber kein Eins-zu-eins-Tausch. Bei einem RFC-9989-Empfänger geht der Record eine Stufe hinunter: pct ist dort ein unbekanntes Tag, Ihr p galt also voll, und t=y bittet um eine Stufe darunter (§4.7). Bei einem RFC-7489-Empfänger geht er in die andere Richtung, eine Stufe hinauf: Nach §6.6.4 wird nicht ausgewählte Mail bei reject wie quarantine behandelt und bei quarantine der normalen lokalen Einstufung überlassen — nach dem Tausch ist auch dort t ein unbekanntes Tag, pct fällt auf seinen Vorgabewert 100 zurück, und Ihr p gilt voll.

Der DNS Tree Walk: welche Policy tatsächlich gilt

Bevor ein Empfänger irgendeine Policy auf eine Nachricht anwenden kann, muss er entscheiden, welcher DMARC-Record für diese Nachricht maßgeblich ist. RFC 9989 beantwortet das mit einem Algorithmus namens DNS Tree Walk (Abschnitt 4.10). Er ersetzt den Nachschlag in der Public Suffix List aus RFC 7489, und bei Domains, die Records auf mehr als einer Ebene veröffentlichen, kann er zu einem anderen Ergebnis kommen als die Liste.

Derselbe Walk beantwortet zwei verschiedene Fragen. Die Policy-Ermittlung (Abschnitt 4.10.1) fragt, welcher Record für die Author Domain gilt — die Domain im From-Header der Nachricht. Die Bewertung der Identifier-Ausrichtung (Alignment, Abschnitt 4.10.2) fragt, zu welcher Organisationsdomain die Author Domain und jeder authentifizierte Identifier gehören, damit über relaxed Ausrichtung entschieden werden kann. Die Mechanik ist identisch; nur der Startname unterscheidet sich, und Abschnitt 4.10.2 zählt die möglichen Startpunkte auf: die Author Domain, den SPF-authentifizierten Identifier, falls SPF bestanden hat, und jeden DKIM-authentifizierten Identifier, der bestanden hat.

Was der Empfänger tatsächlich abfragt

Abschnitt 4.10 formuliert das Verfahren in sieben Schritten. In der Diktion des RFC, mit den DMARC-spezifischen Teilen ausbuchstabiert:

1. Das DNS am Startnamen nach einem TXT-Record abfragen, der dem Format eines DMARC-Policy-Records entspricht. Für die Policy-Ermittlung ist dieser Startname die unmittelbare Elterndomain der Author Domain mit vorangestelltem Label _dmarc, sofern die Author Domain acht oder weniger Labels hat, andernfalls der Name, der aus der Verkürzung in Schritt 3 hervorgeht; die Abfrage an der Author Domain selbst erfolgt, bevor der Walk beginnt (Abschnitt 4.10.1). Zurück kommt eine möglicherweise leere Menge von Records.
2. Jeden Record verwerfen, der nicht mit einem v-Tag beginnt, das die aktuelle DMARC-Version bezeichnet. Wird für einen einzelnen Namen mehr als ein DMARC-Policy-Record zurückgegeben, alle davon verwerfen. Bleibt ein einzelner Record übrig und enthält er psd=n oder psd=y, anhalten.
3. Den betrachteten Namen in geordnete Labels zerlegen, die Anzahl der Labels x zuweisen und die Labels von rechts nach links durchnummerieren. Für a.mail.example.com ist x gleich 4, com ist Label 1, example ist Label 2, mail ist Label 3.
4. Ist x < 8, das am weitesten links stehende (höchstnummerierte) Label entfernen. Ist x >= 8, so lange Labels von links entfernen, bis sieben Labels übrig sind. Das Ergebnis ist der nächste abzufragende Name.
5. Das DNS an diesem Namen nach einem DMARC-Policy-Record abfragen.
6. Dieselbe Verwerfungs- und Abbruchprüfung anwenden wie in Schritt 2.
7. Das am weitesten links stehende Label vom vorherigen Ziel entfernen und die Schritte 5 bis 7 wiederholen, bis der Walk anhält oder keine Labels mehr übrig sind.

Nichts an diesem Verfahren hält an einer Registry-Grenze an. Wird kein psd-Tag angetroffen, läuft der Walk oben aus dem Baum heraus: Der zuletzt abgefragte Name ist die einlabelige Top-Level-Domain, zum Beispiel _dmarc.com. Das ist Absicht, denn ein Public-Suffix-Betreiber darf einen Record veröffentlichen, und der Walk muss ihn finden können.

Das Limit von acht Abfragen und die Label-Abkürzung

Abschnitt 4.10 erklärt, warum es das Limit gibt. Weil der Walk eine Folge von DNS-Abfragen ist, die von einem Namen gesteuert wird, den der Absender kontrolliert, könnte ein böswilliger Domaininhaber Mail mit Author Domains aus Dutzenden oder Hunderten Labels versenden, um einen Denial-of-Service-Angriff auf den Empfänger zu fahren. Die Abkürzung in Schritt 4 ist der Schutz: Author Domains mit mehr als acht Labels führen nicht zu mehr als acht DNS-Abfragen. Acht wurde gewählt, weil beobachtete Daten zum Zeitpunkt der Veröffentlichung Author Domains mit bis zu sieben Labels im Einsatz zeigten — mit Luft nach oben.

Die genaue Regel ist die aus Schritt 4, und sie ist ein Sprung, kein Herunterzählen. Hat der betrachtete Name acht oder mehr Labels, entfernt der Empfänger nicht ein Label; er entfernt Labels, bis genau sieben übrig sind. Jeder Name zwischen der Author Domain und diesem siebenlabeligen Namen wird übersprungen und nie abgefragt. Abschnitt 4.10.1 formuliert dieselbe Regel von der anderen Seite: Hat die Author Domain acht oder weniger Labels, beginnt der Walk bei ihrer unmittelbaren Elterndomain; andernfalls beginnt er bei dem Namen, der aus der Verkürzung ab Schritt 3 hervorgeht.

Author Domain:                       mail.a.b.c.d.e.f.g.example.com   (10 labels)
Record with psd=n published at:            b.c.d.e.f.g.example.com   ( 8 labels)

Queries the receiver makes:
  _dmarc.mail.a.b.c.d.e.f.g.example.com
  _dmarc.c.d.e.f.g.example.com          <- jump straight to seven labels
  _dmarc.d.e.f.g.example.com
  _dmarc.e.f.g.example.com
  _dmarc.f.g.example.com
  _dmarc.g.example.com
  _dmarc.example.com
  _dmarc.com

psd=y und psd=n als Abbruchbedingungen

Das psd-Tag ist das Einzige, was einen Walk vorzeitig anhalten kann. Abschnitt 4.7 definiert drei Werte. psd=y wird von einem Public-Suffix-Betreiber veröffentlicht, um zu erklären, dass der Name eine Public-Suffix-Domain ist. psd=n erklärt, dass der Name keine Public-Suffix-Domain ist, wohl aber die Organisationsdomain für sich selbst und seine Subdomains. psd=u ist die Voreinstellung und bedeutet, dass der Walk entscheidet.

Ist der Walk beendet, wählt Abschnitt 4.10.2 die Organisationsdomain unter den Namen aus, die gültige Records geliefert haben, und betrachtet sie vom längsten zum kürzesten:

1. Ein Record mit psd=n macht diesen Namen zur Organisationsdomain, und die Auswahl endet.
2. Ein Record mit psd=y an einem anderen Namen als dem, an dem der Walk begonnen hat, macht den Namen ein Label darunter in der DNS-Hierarchie zur Organisationsdomain, und die Auswahl endet. Bei Namen innerhalb des Budgets von acht Abfragen ist das der Name, den der Walk unmittelbar davor abgefragt hat.
3. Andernfalls gewinnt der Record, der am Namen mit den wenigsten Labels gefunden wurde, und dieser Name ist die Organisationsdomain.

Führt keine der drei Regeln zu einer Antwort, ist die ursprüngliche Zieldomain die Organisationsdomain. Beachten Sie, was Regel 3 für einen Record bedeutet, der zwischen der Author Domain und dem Apex sitzt: Ohne psd-Tag gewinnt er nicht allein dadurch, dass er der Author Domain näher ist. Anhang B.4.1 buchstabiert das mit Records sowohl an signing.example.com als auch an example.com aus, wobei example.com die Organisationsdomain ist, weil es die wenigsten Labels hat.

Durchgerechnetes Beispiel: mail.eu.corp.example.co.uk

Nehmen Sie eine Nachricht, deren Author Domain mail.eu.corp.example.co.uk ist. Das sind sechs Labels, die Abkürzung bei acht Abfragen greift also nie, und der Walk entfernt ein Label nach dem anderen. Angenommen, das DNS sieht so aus:

_dmarc.corp.example.co.uk  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@corp.example.co.uk"
_dmarc.example.co.uk       TXT  "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.co.uk"
_dmarc.co.uk               TXT  "v=DMARC1; p=none; psd=y; rua=mailto:psd-reports@example.net"

Welcher Name die Organisationsdomain ist. Abschnitt 4.10.2, angewandt auf die Namen, die Records geliefert haben, vom längsten zum kürzesten: corp.example.co.uk hat kein psd-Tag, example.co.uk hat kein psd-Tag, und co.uk hat psd=y und ist nicht der Name, an dem der Walk begonnen hat. Regel 2 greift, und die Organisationsdomain ist der Name ein Label unterhalb von co.uk auf diesem Pfad: example.co.uk.

Welcher Record maßgeblich ist. Abschnitt 4.10.1 ordnet die Kandidaten nach Vorrang: die Author Domain, dann die Organisationsdomain der Author Domain, dann die PSD der Author Domain. An der Author Domain gibt es keinen Record, also wird der Record an example.co.uk angewendet. Die Author Domain ist eine Subdomain davon und existiert im DNS, die Bewertungs-Policy kommt daher aus dem sp-Tag dieses Records: quarantine. Existierte die Author Domain nicht, würde stattdessen np herangezogen; ist keines der beiden Tags vorhanden, gälte p auch für Subdomains.

Welche Records leer ausgehen. Zwei der drei veröffentlichten Records entscheiden über diese Nachricht nicht. Das p=reject an example.co.uk ist nicht die angewendete Policy, weil sp für Subdomains der Organisationsdomain Vorrang hat. Und der Record an corp.example.co.uk spielt überhaupt keine Rolle: Er liegt weder an der Author Domain noch an der Organisationsdomain, also wird für diese Nachricht weder seine Policy noch seine Reporting-Adresse verwendet. Die DMARC Policy Domain ist hier (Abschnitt 3.2.5) example.co.uk, und genau diesen Namen meldet ein Empfänger im Aggregate-Report zurück.

Dieselbe Nachricht mit psd=n eine Ebene tiefer

Ändern Sie eine einzige Sache: Das Team, das corp.example.co.uk betreibt, ergänzt seinen Record um psd=n. Sonst ändert sich in der Zone nichts.

Drei Abfragen statt fünf, und das Ergebnis für die Nachricht kippt von quarantine auf none. Der Apex-Record an example.co.uk und der PSD-Record an co.uk werden nie gelesen. Ein Tag an einem Record hat die administrative Grenze eine Ebene im Baum nach unten verschoben — genau der Fall dezentraler Verwaltung, den Abschnitt 5.1.8 beschreibt.

Wenn der maßgebliche Record eine ungültige Policy enthält

Einen Record zu finden ist nicht dasselbe wie eine Policy zu haben. Abschnitt 4.10.1 legt fest, was passiert, wenn der Record, der für die Nachricht maßgeblich wäre, syntaktisch vorhanden ist, seine Policy-Tags aber unbrauchbar sind — und die Regel hat eine harte Kante.

Zwei benachbarte Regeln vervollständigen das Bild. Abschnitt 4.7 sagt: Fehlt das p-Tag in einem ansonsten syntaktisch gültigen Record, wird der Record behandelt, als enthielte er p=none, und verweist für die Einzelheiten auf Abschnitt 4.10.1; wer p ausdrücklich veröffentlicht und immer eine gültige rua mitführt, kommt mit dieser Unterscheidung gar nicht erst in Berührung. Und wenn der Walk überhaupt keinen DMARC-Record hervorbringt — also eine eindeutige Antwort statt eines vorübergehenden DNS-Fehlers —, dürfen Empfänger den DMARC-Mechanismus laut Abschnitt 4.10.1 NICHT auf die Nachricht anwenden. Abschnitt 5.3.2 formuliert denselben Schluss von der Empfängerseite: Wird kein Record gefunden, endet die DMARC-Prüfung für diese Nachricht.

Vorübergehende DNS-Fehler überlässt der RFC ausdrücklich dem Empfänger. Abschnitt 4.10.1 stellt beide Möglichkeiten nebeneinander, ohne eine zu bevorzugen: die Nachricht zustellen, um Störungen gering zu halten, oder mit einem SMTP-4yx-Code antworten, damit der sendende MTA es erneut versucht, sobald ein eindeutiges Ergebnis erreichbar ist. Sie können sich auf keines der beiden Verhalten verlassen — ein Argument dafür, die _dmarc-Namen Ihres gesamten Baums auflösbar und schnell zu halten.

PSL gegen Tree Walk: was sich für Sie ändert

Abschnitt 4.10 ist ungewöhnlich deutlich darin, warum die Public Suffix List aufgegeben wurde. RFC 7489 definierte die Organisationsdomain als die bei einem Registrar registrierte Domain und beschrieb, sie über eine PSL zu ermitteln — schrieb den Empfängern aber keine bestimmte Liste vor und gab keine Hinweise, wie oft ein Empfänger seine Kopie auffrischen sollte. Er räumte ein, dass Empfänger mit unterschiedlichen Listen Interoperabilitätsprobleme verursachen können, und regte an, die PSL durch ein zuverlässigeres und sichereres Verfahren zu ersetzen, sofern sich eines schaffen lässt. Anhang A.5 nennt das zweite Motiv: Ein unbegrenztes Hochklettern im Baum lädt zu einem Denial-of-Service-Angriff über Author Domains voller Unsinns-Labels ein — genau dagegen richtet sich die Obergrenze von acht Abfragen.

Ihre Organisationsdomain ist jetzt etwas, das Sie veröffentlichen

Abschnitt 3.2.14 definiert die Organisationsdomain nicht mehr über die Registrierung. Er definiert sie als die Domain an der Spitze der Namensraum-Hierarchie eines Namens, die zugleich derselben administrativen Zuständigkeit unterliegt wie dieser Name, und stellt fest, dass sie durch Anwendung des Algorithmus aus Abschnitt 4.10 bestimmt wird. Die Grenze ergibt sich jetzt daraus, wo DMARC-Records existieren, und nicht aus einem Eintrag in einer Liste, über die Sie keine Kontrolle haben.

Im Normalfall stimmen beide Verfahren überein. Veröffentlicht Ihr Apex einen Record, veröffentlicht nichts zwischen Apex und Ihren sendenden Namen einen, und veröffentlicht keine PSD oberhalb von Ihnen einen, dann landet der Walk auf Ihrem Apex — genau das, was die PSL zurückgegeben hätte. Die Antworten gehen genau dort auseinander, wo Records auf anderen Ebenen existieren, und darum geht es im Rest dieses Abschnitts.

sp gilt an der Organisationsdomain und wird darunter ignoriert

Abschnitt 4.7 definiert sp als die Bewertungs-Policy für existierende Subdomains der jeweiligen Organisationsdomain; sie gilt nur für existierende Subdomains der Organisationsdomain der Nachricht und nicht für die Organisationsdomain selbst. Dieselbe Tag-Definition benennt dann die betriebliche Folge direkt: sp wird bei DMARC-Records ignoriert, die auf Subdomains von Organisationsdomains und PSDs veröffentlicht sind — wegen der Wirkung der Policy-Ermittlung aus Abschnitt 4.10.1.

Zwei Fälle machen das greifbar, unter der Annahme, dass example.com die Organisationsdomain ist und corp.example.com ebenfalls einen Record veröffentlicht:

Ein sp-Tag an corp.example.com bewirkt überhaupt nur dann etwas, wenn corp.example.com selbst die Organisationsdomain ist — was nach Abschnitt 4.10.2 heißt, dass es entweder psd=n trägt oder der kürzeste Name im Walk ist, der einen Record geliefert hat. sp=reject auf einer Subdomain zu veröffentlichen und zu erwarten, dass es die Namen darunter schützt, ist der häufigste Weg zu einer Policy, die nie angewendet wird.

psd=n macht einen Namen zur Organisationsdomain für sich und alles darunter

Abschnitt 4.7 definiert psd=n als Record, der für eine Domain veröffentlicht wird, die keine PSD ist, aber die Organisationsdomain für sich selbst und ihre Subdomains. Er tut zweierlei auf einmal: Er hält den Walk an diesem Namen an (Abschnitt 4.10, Schritte 2 und 6), und er gewinnt die Auswahl der Organisationsdomain unmittelbar als Regel 1 aus Abschnitt 4.10.2 — vor jedem psd=y oberhalb und vor der Regel der wenigsten Labels.

Abschnitt 5.1.8 nennt den vorgesehenen Zweck: In einer Organisation, die Teilbäume ihres Namensraums an lokale Abteilungen delegiert, erlaubt psd=n einer Abteilung, eine eigene Organisationsdomain zu erklären — typischerweise, weil sie andere Policy-Einstellungen oder andere Reporting-URIs möchte als der Apex-Record. Abschnitt 11.8 nennt einen defensiven Zweck: Veröffentlicht eine PSD oberhalb Ihrer Domain einen DMARC-Record ohne das zugehörige psd=y-Tag, kann ein Empfänger daraus schließen, dass die PSD Ihre Organisationsdomain ist — was relaxed Ausrichtung über Ihre administrative Grenze hinaus ausweitet; psd=n in Ihrem eigenen Record nimmt diese Möglichkeit weg. Abschnitt 11.8 empfiehlt außerdem, die DMARC-Records der PSDs oberhalb von Ihnen regelmäßig zu prüfen, da Sie keinen Einfluss darauf haben, wann sie sich ändern.

Was ein Record auf einer Subdomain beendet — und was nicht

Hier lohnt sich Genauigkeit, denn die Kurzfassung „ein Record auf einer Subdomain beendet den Walk" trifft nur in bestimmten Fällen zu.

• An der Author Domain selbst endet die Ermittlung, bevor der Walk beginnt. Abschnitt 4.10.1 startet mit einer Abfrage auf _dmarc vor der Author Domain, und wird dort ein gültiger Record gefunden, ist das der angewendete Record. Sein p-Tag liefert die Policy. Das ist die einzige Platzierung, die garantiert, dass ein bestimmter Record für einen bestimmten sendenden Namen gilt, und Abschnitt 5.1.8 macht sie für Author Domains mit mehr als acht Labels zur MUSS-Vorgabe.
• An einem Zwischen-Namen beendet nur psd den Walk. Die Schritte 2 und 6 aus Abschnitt 4.10 halten ausschließlich bei psd=n oder psd=y an. Ein Record ohne psd-Tag wird als Kandidat behalten, und der Walk läuft darüber hinaus weiter.
• Ein Zwischen-Record wird nur herangezogen, wenn er die Auswahl gewinnt. Nach Regel 3 aus Abschnitt 4.10.2 heißt das: der Record, der am Namen mit den wenigsten Labels gefunden wurde. Anhang B.4.1 spielt genau das durch: Records existieren sowohl an signing.example.com als auch an example.com, und example.com ist die Organisationsdomain, weil es das höchste Element im Baum mit einem Record ist.

Das Vererbungsbild lautet also nicht „der nächstgelegene Record oberhalb gewinnt". Es lautet: zuerst Ihr eigener Name, dann derjenige Record, den der Walk am höchsten findet — es sei denn, jemand auf dem Weg hat mit psd etwas anderes bestimmt. Wenn eine von Ihnen veröffentlichte Policy nie angewendet wird, liegt der Record meist an einem Namen, der weder die Author Domain noch die Organisationsdomain ist.

Nachmessen: das Feld discovery_method in Aggregate-Reports

Sie müssen nicht raten, welches Verfahren ein Empfänger gefahren hat. RFC 9990 Abschnitt 3.1.1.5 ergänzt den policy_published-Block des Aggregate-Reports um ein optionales Element namens discovery_method, das das Verfahren beschreibt, mit dem der bei der Bewertung verwendete DMARC-Policy-Record ermittelt wurde. Es hat genau zwei erlaubte Werte, festgelegt durch den Simple Type DiscoveryType im XML-Schema in Anhang A von RFC 9990: psl für das Verfahren aus RFC 7489 und treewalk für das Verfahren aus RFC 9989.

<policy_published>
  <domain>example.co.uk</domain>
  <p>reject</p>
  <sp>quarantine</sp>
  <np>reject</np>
  <testing>n</testing>
  <discovery_method>treewalk</discovery_method>
</policy_published>

Lesen Sie es zusammen mit dem domain-Element im selben Block, das RFC 9990 Abschnitt 3.1.1.5 als DMARC Policy Domain definiert, also als den Namen, an dem der maßgebliche Record gefunden wurde (RFC 9989 Abschnitt 3.2.5). Das Paar sagt Ihnen zwei Dinge, die ein Policy-Record allein nicht sagen kann: welchen Ihrer Records dieser Empfänger tatsächlich angewendet hat und wie er dorthin gelangt ist. Wenn Sie auf mehreren Ebenen veröffentlichen, ist das das Feld, das zeigt, ob Empfänger dort landen, wo Sie es beabsichtigt haben.

Das Element ist optional. Sein Fehlen bedeutet, dass der Empfänger kein Verfahren angegeben hat — nicht, dass er die PSL verwendet hat. Aggregate-Reports von Empfängern, die weiterhin das Verfahren aus RFC 7489 fahren, sind genauso gültige Reports, und policy_published/domain bleibt in diesem Fall das verlässliche Signal, weil es den tatsächlich verwendeten Record benennt, unabhängig davon, wie er gefunden wurde.

Welche Empfänger welcher Version folgen — und was das für Ihren Record bedeutet

Seit Mai 2026 gibt es genau eine gültige DMARC-Spezifikation: RFC 9989, zusammen mit ihren beiden Begleitdokumenten zum Aggregate-Reporting (RFC 9990) und zum Failure-Reporting (RFC 9991). RFC 7489 ist obsolet. Der RFC Editor stellt das auf der Informationsseite des Dokuments selbst mit genau diesen Worten fest: „This RFC is now obsolete, see RFC 9989, RFC 9990, RFC 9991.“

Obsolet ist eine Aussage über das Dokument, nicht über die Software im Feld. Jeder Record, den Sie heute veröffentlichen, wird von zwei Populationen von Empfängern zugleich gelesen: von denen, die RFC 9989 implementiert haben, und von denen, die noch eine RFC-7489-Implementierung betreiben. Keine der beiden Populationen gibt sich zu erkennen. Ein Record, der unter beiden korrekt ist, ist deshalb kein Kompromiss — er ist die einzige Art von Record, deren Verhalten Sie vorhersagen können.

Was sich im Mai 2026 tatsächlich geändert hat

Ein Detail übersieht man leicht, und es verändert, wie Sie den Übergang lesen sollten: Es war nie Standard gegen Standard. RFC 7489 war nicht das Ergebnis eines IETF-Arbeitsprozesses. Es wurde über den Independent Submissions Editor veröffentlicht und als Informational eingestuft. RFC 9989 sagt das in Appendix C.1 unmissverständlich und stellt sich selbst dem gegenüber als „an Internet Standards Track document“. Es ist das erste DMARC-Dokument auf dem Standards Track: RFC 7489 war Informational, und RFC 9091, das PSD DMARC eingeführt hat, war Experimental (Appendix C.3). In den elf Jahren zwischen RFC 7489 und RFC 9989 wurde DMARC im großen Maßstab betrieben, ohne dass eine Standards-Track-Spezifikation dahinterstand.

RFC 9989 macht RFC 7489 und RFC 9091 (das experimentelle PSD-DMARC-Dokument) obsolet. Die praktischen Folgen für einen veröffentlichten Record liegen an vier Stellen.

Keines der Tags in der rechten Spalte bringt das Parsing eines älteren Empfängers durcheinander. Beide Spezifikationen verlangen, dass unbekannte Tags ignoriert werden, und RFC 9989 §9.3 nennt die Entwurfsregel direkt: Tags, die zu DMARC hinzukommen, „are to avoid changing the semantics of existing records when processed by implementations conforming to prior specifications“. np, psd oder t hinzuzufügen ist unbedenklich. Sich für ein Ergebnis, das Sie heute brauchen, darauf zu verlassen, nicht.

1. pct — von der einen Population gelesen, für die andere unsichtbar

RFC 9989 hat pct entfernt (Appendix C.5.2). Die IANA-DMARC-Tags-Registry (§9.3) führt es jetzt mit dem Status historic, zusammen mit rf und ri. Appendix A.6 nennt den Grund, und es lohnt sich, ihn zu lesen, bevor Sie einem ausgerollten Prozentwert vertrauen: Die Betriebserfahrung zeigte, dass das Tag „was usually not accurately applied, unless the value specified was either 0 or 100“, und die Ungenauigkeiten bei anderen Werten „varied widely from one implementation to another“.

Ein Record, der heute pct=25 trägt, bedeutet also nicht, dass ein Viertel der fehlschlagenden Mail in Quarantäne kommt. Er bedeutet, dass es bei den Empfängern, die das Tag noch beachten, ein unbekannter Anteil ist — und bei jedem RFC-9989-Empfänger alles davon. Die schrittweise Rampe pct=10 → 25 → 50 ist nicht mehr teilweise wirksam; bei der neueren Population ist sie wirkungslos. Was an ihre Stelle tritt, steht im Abschnitt zum Rollout.

Das Tag stehen zu lassen richtet keinen Schaden an: Nach RFC 9989 §4.8 werden unbekannte Tags ignoriert, und verirrte Syntax wird verworfen, statt den Record ungültig zu machen. Das Risiko ist kein Defekt, sondern eine falsche Vorstellung davon, was Ihre Policy derzeit tut.

2. Organisationsdomain — Public Suffix List gegen Tree Walk

Das ist die Abweichung mit der größten Reichweite, denn die Organisationsdomain entscheidet über zwei getrennte Dinge: welcher Record für eine Subdomain gilt, die keinen eigenen hat, und ob ein DKIM- oder SPF-Identifier als relaxed ausgerichtet zur From:-Domain zählt.

RFC 7489 leitete sie aus einer Public Suffix List ab. RFC 9989 §4.10 hat das durch den DNS-Tree-Walk ersetzt: _dmarc an sukzessive kürzeren Namen abfragen, höchstens acht Abfragen, und die Organisationsdomain aus den tatsächlich gefundenen Records bestimmen (§4.10.2). Die Spezifikation benennt die Folge in Appendix C.3 selbst: „These algorithm changes introduce the possibility of interoperability issues where a Domain Owner expects a DMARC Policy Record or an Organizational Domain to be identified by the Tree Walk process, but a Mail Receiver using an implementation of DMARC based on [RFC7489] and relying on a PSL might arrive at a different answer“.

Zwei Situationen führen in der Praxis zu unterschiedlichen Antworten. Die erste ist ein Record, der auf einer Zwischenebene veröffentlicht ist: Nach §4.10.2 macht ein Record mit psd=n genau diesen Namen zur Organisationsdomain, was ein listenbasierter Empfänger nicht sehen kann. Die zweite ist weniger offensichtlich.

_dmarc.news.example.com.   TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
_dmarc.example.com.        TXT  (no record)

From: alerts@news.example.com
DKIM-Signature: ... d=bulk.example.com; ...   (valid signature)

3. np und psd — Tags, die die ältere Population nie gelernt hat

np setzt die Policy für nicht existierende Subdomains der Organisationsdomain (§4.7); „nicht existierend“ hat dabei die genaue Bedeutung aus §3.2.13, nämlich eine NXDOMAIN-Antwort. psd markiert einen Namen als Public Suffix Domain, und RFC 9989 §5.2 verlangt, dass ein Public Suffix Operator, der einen Record veröffentlicht, psd=y aufnimmt.

Ein RFC-7489-Empfänger ignoriert beide. Am schwersten wiegt das bei np, denn der Rückfall ist in §4.7 ausbuchstabiert: Fehlt np, gilt die Policy aus sp, sofern vorhanden, sonst die Policy aus p. p=none; np=reject gibt Ihnen also bei der einen Population Schutz für nicht existierende Subdomains und bei der anderen gar keinen. Wenn Ihnen dieser Schutz wichtig ist, muss er auch aus p oder sp kommen, nicht aus np allein.

Die drei Policy-Stufen: none, quarantine, reject

Das p-Tag trägt, was RFC 9989 die Domain Owner Assessment Policy nennt: Ihre Präferenz für die Behandlung von Mail, die Ihre Domain im From:-Header verwendet und die DMARC-Validierung nicht besteht. §4.7 definiert genau drei Werte, und man sollte den Wortlaut wörtlich nehmen, denn jeder davon sagt etwas anderes darüber aus, wie sicher Sie sind.

p=none — „The Domain Owner offers no expression of preference“

Das ist die vollständige Definition in §4.7. Es ist keine schwache Policy, es ist das Fehlen einer Policy. RFC 9989 stützt das auf der Empfängerseite in §5.4: Ermittelte Policies von p=none „MUST NOT modify existing mail handling processes“. Ein Empfänger, der an der Behandlung Ihrer fehlschlagenden Mail etwas ändert, weil Sie p=none veröffentlicht haben, verhält sich nicht konform.

Was p=none Ihnen einbringt, sind Daten. §3.2.12 definiert diesen Zustand als Monitoring Mode — die Policy ist in der gesamten Domain und ihren Subdomains none, und der Inhaber empfängt Aggregate-Reports und nutzt sie, um seine Authentifizierung zu korrigieren. Ohne rua-Tag ist p=none eine Messphase, die nichts misst.

p=quarantine — „considers such mail to be suspicious“

Der vollständige Satz in §4.7 lautet: „The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.“ Das Eingeständnis, dass die Mail gültig sein könnte, ist der Sinn dieser Stufe. Sie bitten darum, die Nachricht mit Misstrauen zu behandeln, nicht sie zu vernichten, weil Sie noch nicht sicher sind, dass sich alles Legitime authentifiziert.

Was Misstrauen in der Praxis bedeutet, definiert der RFC nicht und kann er nicht definieren. §5.4 beginnt mit dem Satz, der für alle drei Stufen gilt: „The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver.“ Der eine Empfänger legt die Nachricht in einen Junk-Ordner, der nächste ergänzt eine Warnung, der übernächste stellt sie zurück.

p=reject — „a clear indication that the use of the domain name is not valid“

§4.7: „The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.“ Beachten Sie den Umfang — alle solchen Fehlschläge. p=reject zu veröffentlichen ist die Aussage, dass Ihnen kein legitimer Mailstrom bekannt ist, der DMARC für Ihre Domain nicht besteht. Wenn es einen gibt, haben Sie ihn für ungültig erklärt.

§7.2 beschreibt, wie Empfänger das umsetzen und warum die Wahl nicht neutral ist. Eine vollständige Abweisung ist eine 5xy-Antwort auf das DATA-Kommando; die Fehlermeldung zu erzeugen bleibt dem sendenden Client überlassen. Ein stilles Verwerfen gibt eine 2xy-Antwort zurück und lässt die Nachricht fallen, was Backscatter vermeidet, aber bedeutet, dass der Server „has to be programmed to give a false result, which can confound external debugging efforts“. Derselbe Abschnitt schlägt vor, das Wort DMARC in den Antworttext aufzunehmen, damit der Grund maschinell erkennbar ist, zum Beispiel 550 5.7.1 Email rejected per DMARC policy for example.com.

Die drei Stufen nebeneinander

Report-Struktur nach RFC 9990: policy_published trägt den Record, der gefunden wurde (§3.1.1.5), policy_evaluated trägt die tatsächlich angewandte Disposition sowie die DMARC-Ausrichtungsergebnisse für DKIM und SPF (§3.1.1.9), und das reason-Element trägt einen vordefinierten Übersteuerungstyp aus der Liste in §3.1.6. RFC 9990 §3.1.1.9 ist eindeutig, dass die berichteten dkim- und spf-Werte „MUST be the evaluated values as they relate to DMARC, not the values the receiver may have used when overriding the policy“. Ihr Bild von der Ausrichtung bleibt ehrlich, auch dort, wo die Disposition Ihrer Policy nicht folgt.

Warum p=reject keine Garantie ist

Das ist das Folgenreichste, was RFC 9989 zur Policy sagt, und der Teil, der am häufigsten übersprungen wird: Ein konformer Empfänger darf nicht allein auf Ihr Wort hin abweisen.

Die Untergrenze, die RFC 9989 setzt, ist Absicht: „In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were ‘p=quarantine’ rather than ‘p=reject’“ (§7.4). Ein Empfänger ohne weitere Anhaltspunkte muss Sie um eine Stufe herabstufen. Und §5.4 deckt auch den umgekehrten Fall ab: Ein DMARC-Pass „does not carry an explicit or implicit value assertion about that message or the Domain Owner“ — Empfänger dürfen Mail, die besteht, also trotzdem abweisen oder in Quarantäne legen.

Die zwei Wege, auf denen Sie ungefragt bei p=none landen

§4.7 und §4.10.1 beschreiben beide Records, die unabhängig von der Absicht als p=none behandelt werden:

• Ein syntaktisch gültiger Record ohne p-Tag „is treated as if it included ‘p=none’“ (§4.7).
• Ein Record, dessen p-Tag ungültig ist oder dessen sp- oder np-Tag ungültig ist, wird nur dann gerettet, wenn er mindestens eine syntaktisch gültige rua-URI trägt. In diesem Fall gilt für den Empfänger: „MUST act as if a record containing ‘p=none’ was retrieved“. Ohne brauchbare rua wendet der Empfänger überhaupt keine DMARC-Verarbeitung auf die Nachricht an (§4.10.1).

Ein Tippfehler in p=rejcet fällt deshalb nicht auf Ihre vorherige Policy zurück und erzeugt an keiner Stelle, die Sie sehen würden, einen Fehler. Er wird still zu Monitoring — oder schaltet DMARC für Ihre Domain still ab.

Rollout: von p=none zu p=reject

RFC 9989 legt die Reihenfolge in §5.1 dar: SPF für eine ausgerichtete Domain veröffentlichen (§5.1.1), mit einer ausgerichteten DKIM-Domain signieren (§5.1.2), ein Report-Postfach einrichten (§5.1.3), den Record veröffentlichen (§5.1.4), die Reports lesen (§5.1.5), beheben, was sie zeigen (§5.1.6), und erst dann über Enforcement entscheiden (§5.1.7). Die Reihenfolge ist kein Schmuck: §5.1.6 stellt fest, dass Authentifizierungsmängel in legitimen Mailströmen „MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy ... of Enforcement“.

Die Phasen

Zwei Anmerkungen zur Spalte mit der Dauer. Erstens sind die Zahlen eine Untergrenze, keine Empfehlung. §7.4 nennt sie für Domains, die Nutzer beherbergen, die an Mailinglisten schreiben, und die ohnehin p=reject veröffentlichen wollen: Eine solche Domain „SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing ‘p=none’ for at least a month, followed by publishing ‘p=quarantine’ for an equally long period of time, and comparing the message disposition results“. Es ist die einzige Dauer, die RFC 9989 nennt.

Zweitens macht §5.1.7 klar, dass ein Monat oft bei Weitem nicht reicht: „Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail“. Jährliche Mail — eine Verlängerungsmitteilung, ein Steuerdokument, eine Jahresabrechnung — taucht in einem Monat Reports überhaupt nicht auf. Die Dauer, auf die es ankommt, ist die, die einen vollen Zyklus Ihres eigenen Versands abdeckt, nicht eine Zahl im Kalender.

Beachten Sie außerdem: Enforcement im Sinne von §3.2.9 verlangt, dass die Policy für die Organisationsdomain und alle Subdomains darunter etwas anderes als none ist. Ein Record mit p=reject; sp=none ist kein Enforcement, und er lässt jede Subdomain Ihres Namensraums für beliebige Dritte nutzbar.

Die t=y-Leiter ersetzt die pct-Rampe

Die vertraute Rampe pct=10 → 25 → 50 funktioniert nicht mehr, aus den Gründen im pct-Abschnitt oben. RFC 9989 ersetzt sie durch t=y, und Appendix A.6 erklärt die Überlegung: Die beiden brauchbaren Werte von pct waren 0 und 100, also wurde das Tag durch eines mit genau zwei Werten ersetzt, „meant to be analogous in their application by mailbox providers and intermediaries to the ‘pct’ tag values ‘0’ and ‘100’, respectively“.

Was t=y tut, ist in §4.7 definiert: Es bittet den prüfenden Empfänger, nicht die Policy anzuwenden, sondern seine eigenen Sonderregeln, in der Erwartung, dass die auf fehlschlagende Nachrichten angewandte Policy „will be one level below the specified policy“ ist. p=quarantine; t=y wird wie none behandelt, p=reject; t=y wie quarantine. Auf eine Policy von none hat das Tag keine Wirkung, weshalb es keine Sprosse p=none; t=y gibt.

Der Grund, warum das als Rollout-Instrument funktioniert und ein Prozentsatz es nie tat, ist, dass das Reporting nicht zusammen mit der Policy abschwächt. §4.7 stellt fest, dass das Tag „does not affect the generation of DMARC reports“. Mehr noch: Die Abschwächung ist in den Daten sichtbar. RFC 9990 §3.1.6 definiert den Übersteuerungstyp policy_test_mode so: „The message was exempted from application of policy by the testing mode (‘t’ tag) in the DMARC Policy Record“. Dasselbe Dokument trägt den Wert des t-Tags als testing in das policy_published-Element ein (§3.1.1.5). Eine Sprosse im Testmodus liefert Ihnen also eine beschriftete Zählung genau der Mail, die die nächste Sprosse getroffen hätte — mehr, als eine Stichproben-Rampe Ihnen je gesagt hat, denn Sie können jede ausgenommene Nachricht zuordnen.

Wenn Sie während des Übergangs dasselbe Verhalten auch bei RFC-7489-Empfängern brauchen, ist der entsprechende Wert dort pct=0, und beides zu veröffentlichen ist unbedenklich: Ein RFC-9989-Empfänger ignoriert pct, ohne den Record ungültig zu machen (§4.8). Behandeln Sie diese Kombination als vorübergehend und lesen Sie zuerst Appendix A.6 — dort ist festgehalten, dass pct=0 seine Bedeutung als unbeabsichtigter Nebeneffekt bekam, dass Implementierungen unterschiedlich darauf reagierten und dass das ausgelöste Verhalten meist ein Umschreiben des From-Headers war und keine Herabstufung der Policy. Die beiden sind analog, nicht identisch.

Zwei Bedingungen, die der RFC an p=reject knüpft

RFC 9989 behandelt p=reject nicht als das Ziel für jede Domain. Es knüpft zwei Anforderungen daran, beide in §7.4, und wiederholt die erste in der Konformitätsliste in §8.

Sie dürfen sich nicht allein auf SPF verlassen. §7.4 erklärt, warum: Wenn Mail über eine Alumni-Weiterleitung, eine Rollenadresse oder eine Mailingliste weitergereicht wird, ist die verbindende IP die des Relays, sodass sie „will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA“, während „DKIM signatures will generally remain valid in these relay situations“. Die Anforderung steht als hervorgehobene Regel: „It is therefore critical that domains that publish ‘p=reject’ MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.“ §8 führt dasselbe MUST NOT unter den Konformitätsanforderungen für Domaininhaber auf.

§7.4 ist auch offen darüber, wo das in der Praxis gelandet ist. Mailinglisten-Software hat das Umschreiben des From-Headers als Tatsache hingenommen; ARC (RFC 8617) und andere Versuche, den ursprünglichen Header zu erhalten, haben keine breite Verwendung gefunden; und „few Mail Receivers apply any mitigation techniques when receiving indirect mail flows“. Wenn Ihre Domain nur Transaktions- und Unternehmensmail versendet, betrifft Sie das Mailinglisten-Problem nicht und p=reject ist das richtige Ziel — beachten Sie allerdings, dass das durchgerechnete Beispiel in §7.4 selbst eine Bank ist, deren gezielt versandte Mail die Empfänger trotzdem über Alumni-Weiterleitungen und Rollenadressen erreicht. Weiterleitung ist kein reines Mailinglisten-Phänomen, und genau deshalb ist die DKIM-Anforderung oben nicht optional. Wenn Ihre Domain allgemeine Postfächer beherbergt, rät der RFC dazu, die Auswirkungen vorher aus den Aggregate-Reports zu ermitteln — wofür die Phasen oben da sind.

Beispiel-Records für reale Situationen

Jeder Record unten steht vollständig da. Nichts ist für die Seite gekürzt — was Sie hier lesen, ist genau das, was Sie veröffentlichen würden, und der DNS-Name vor jedem Record gehört zum Beispiel dazu: Ein DMARC-Record wird unter dem Namen veröffentlicht, für den er gilt, mit dem Label _dmarc davor, und ein Record, der an einer Organisationsdomain veröffentlicht ist, kann auch für Subdomains dieses Namens gelten (RFC 9989 §4.5).

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

_dmarc.newsletter.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

_dmarc.example.net.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"

_dmarc.tx.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-tx@example.com"

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com,mailto:example-com@reports.example.net"

RFC 9989 §11.6 empfiehlt, Reports nach Möglichkeit an eine Adresse zu schicken, die innerhalb Ihrer eigenen Domain Mail empfangen kann, und sie von dort weiterzuleiten — das erspart den externen Autorisierungsschritt vollständig. Für eine Domain, die überhaupt keine Mail empfangen kann, etwa die geparkte Domain oben, ist der Autorisierungs-Record der einzige Weg.

Aggregate-Reports lesen (RFC 9990)

Ein Aggregate-Report ist ein XML-Dokument, das ein Empfänger an die Adressen in Ihrem rua-Tag schickt. Er enthält gezählte Nachrichtengruppen, keine Nachrichten: für jede sendende IP-Adresse und jede Kombination von Authentifizierungsergebnissen eine Zeile mit einer Nachrichtenzahl, der angewendeten DMARC-Disposition und den rohen SPF- und DKIM-Ergebnissen dahinter. RFC 9990 Abschnitt 7.2 stellt ausdrücklich fest, dass diese Daten keine personenbezogenen Informationen tragen — keine einzelnen Mailadressen, keine IP-Adressen von Endnutzern, keine Nachrichteninhalte. Das ist der Handel: Aggregate-Reports zeigen Ihnen die Form Ihrer Mailströme und nichts über einzelne Nachrichten.

Abschnittsangaben in diesem Teil der Seite beziehen sich auf RFC 9990, sofern kein anderes Dokument genannt ist.

Ein Report deckt genau eine DMARC Policy Domain und eine Policy-Konfiguration ab (Abschnitt 3.1). Haben Ihre Subdomains keinen eigenen DMARC-Record, taucht ihr Verkehr als zusätzliche record-Elemente im Report der Organisationsdomain auf; eine Subdomain, die einen eigenen Record veröffentlicht, bekommt einen eigenen Report (Abschnitt 3.1.2). Ändern Sie Ihre Policy mitten im Zeitraum, kann ein Empfänger Ihnen einen einzelnen Report mit gemischten Dispositionen unter einem policy_published-Element schicken oder mehrere Reports für denselben Zeitraum — beides erlaubt Abschnitt 3.3, eine kurze Inkonsistenz nach einer Policy-Änderung ist also zu erwarten und kein Fehler.

Zeitraum und Häufigkeit

Das date_range-Element trägt begin und end als Sekunden seit der Epoche, in UTC. Abschnitt 3.1.1.4 legt fest, dass diese den Berichtszeitraum bezeichnen und nicht die erste und letzte beobachtete Nachricht, dass Zeiträume einander nicht überlappen SOLLEN und dass der Zeitraum typischerweise einen einzelnen UTC-Tag ab 0000 UTC umfasst. Abschnitt 3.1 beschreibt den Takt als täglich oder häufiger, und RFC 9989 Abschnitt 8 führt „SHOULD send aggregate reports on at least a daily basis“ unter den Konformitätsanforderungen für Empfänger auf.

Ein anderes Intervall können Sie nicht mehr anfordern. Das ri-Tag, das in der alten Spezifikation ein Berichtsintervall anforderte, steht in RFC 9989 Anhang C.5.2 unter „Tags Removed“ und trägt in der DMARC-Tags-Registry den Status „historic“ (RFC 9989 Abschnitt 9.3). ri=3600 heute zu veröffentlichen ist wirkungslos: Es ist ein unbekanntes Tag, kein stündlicher Report.

Wie die Reports zu Ihnen kommen

Per E-Mail. RFC 9989 Abschnitt 8 verlangt von einem konformen Empfänger, die mailto:-URI für den Versand angeforderter Reports zu unterstützen, und RFC 9990 Abschnitt 3.5.2 legt die Mechanik fest: Der Report ist eine XML-Datei im Anhang einer MIME-Nachricht, er SOLLTE GZIP-komprimiert sein und MUSS den Medientyp application/gzip tragen, wenn er komprimiert ist, und text/xml, wenn nicht. Der Dateiname folgt einer festen ABNF — receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].xml.gz — und das Subject-Feld ebenfalls, beide sind also auswertbar, ohne den Anhang zu öffnen.

Zwei Konsequenzen sind wissenswert. Erstens MUSS der Mailstrom, der die Reports trägt, selbst DMARC mit Ausrichtung (Alignment) bestehen (Abschnitt 3.5.2); einem Report, der unauthentifiziert ankommt, sollten Sie nicht trauen. Zweitens wertet ein Empfänger die URIs in Ihrem rua-Tag in der angegebenen Reihenfolge aus, ignoriert fehlerhafte und versucht die Zustellung an jede verbleibende URI bis zu seinem eigenen Limit an unterstützten URIs (Abschnitt 3.5). Wo die URI nichts anderes sagt, SOLLTE er einen Kanal mit TLS verwenden (SMTP mit STARTTLS).

Ein vollständiger Report, kommentiert

Der Namensraum ist urn:ietf:params:xml:ns:dmarc-2.0, von der IANA in RFC 9990 Abschnitt 6.1 registriert. Das Dokument unten ist ein UTC-Tag für example.com mit zwei Records: Mail von der eigenen Plattform der Domain und Mail, die den Empfänger über eine Mailingliste erreicht hat.

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>

  <report_metadata>
    <org_name>Example Receiver</org_name>
    <email>dmarc-reports@receiver.example.net</email>
    <extra_contact_info>https://receiver.example.net/postmaster</extra_contact_info>
    <!-- Unique among reports to this domain; used to spot duplicates. -->
    <report_id>1735689600-example.com@receiver.example.net</report_id>
    <date_range>
      <begin>1735689600</begin>  <!-- 2025-01-01 00:00:00 UTC -->
      <end>1735775999</end>      <!-- 2025-01-01 23:59:59 UTC -->
    </date_range>
    <!-- An optional <error> element would sit here, carrying problems
         the receiver hit while reading your DMARC record itself. -->
    <generator>Example Aggregate Reporter v2.1</generator>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <discovery_method>treewalk</discovery_method>  <!-- or "psl" -->
    <p>quarantine</p>
    <sp>quarantine</sp>
    <np>reject</np>
    <fo>1</fo>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <testing>n</testing>  <!-- value of the "t" tag -->
  </policy_published>

  <!-- Record 1: the domain's own sending platform. Everything aligned. -->
  <record>
    <row>
      <source_ip>192.0.2.24</source_ip>
      <count>4213</count>
      <policy_evaluated>
        <!-- "pass" means: DMARC passed under an enforcing policy. -->
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>bounces.example.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <selector>mail202601</selector>  <!-- REQUIRED since RFC 9990 -->
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounces.example.com</domain>
        <scope>mfrom</scope>  <!-- the only valid value -->
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <!-- Record 2: your mail relayed by a discussion list on example.org.
       Read the two blocks against each other before drawing conclusions. -->
  <record>
    <row>
      <source_ip>2001:db8::a12</source_ip>
      <count>17</count>
      <policy_evaluated>
        <!-- Published policy is quarantine, applied disposition is none,
             so a reason element is mandatory here. -->
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>mailing_list</type>
          <comment>Message arrived via a known list; failure expected.</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <!-- The list rewrote the envelope sender to its own domain. -->
      <envelope_from>lists.example.org</envelope_from>
    </identifiers>
    <auth_results>
      <!-- Passing signatures first, per the priority list in 3.1.3. -->
      <dkim>
        <domain>lists.example.org</domain>
        <selector>list2026</selector>
        <result>pass</result>  <!-- valid, but not your domain -->
      </dkim>
      <dkim>
        <domain>example.com</domain>
        <selector>mail202601</selector>
        <result>fail</result>
        <human_result>body hash did not verify</human_result>
      </dkim>
      <spf>
        <domain>lists.example.org</domain>
        <scope>mfrom</scope>
        <result>pass</result>  <!-- SPF passed for the list, not for you -->
      </spf>
    </auth_results>
  </record>
</feedback>

Der zweite Record ist der, über den viele stolpern. Innerhalb von auth_results sagt SPF pass, und eine DKIM-Signatur sagt ebenfalls pass. Innerhalb von policy_evaluated sagen beide fail. Das ist kein Widerspruch: Abschnitt 3.1.1.11 definiert auth_results als die rohen SPF- und DKIM-Ergebnisse „uninterpreted with respect to DMARC“, während Abschnitt 3.1.1.9 verlangt, dass die Werte in policy_evaluated die DMARC-bewerteten sind. Der SPF-Pass der Liste gehört zu lists.example.org, das nicht zur From-Domain ausgerichtet ist, und die Signatur, die ausgerichtet gewesen wäre, ist zerbrochen, als die Liste den Body verändert hat. Wann immer Sie die beiden Blöcke vergleichen: policy_evaluated ist das Urteil, auth_results ist die Beweislage.

Zwei strukturelle Details sind wichtig, wenn Sie einen Parser schreiben statt einen Report zu lesen. Die Elemente der ersten Ebene sowie die Kindelemente von record, policy_evaluated und auth_results MÜSSEN in der Reihenfolge stehen, die der RFC auflistet; das Schema in Anhang A modelliert die übrigen Gruppen als xs:all, die Reihenfolge der Kindelemente von policy_published, row, identifiers und eines einzelnen dkim-Blocks ist also nicht festgelegt. Ein Report darf bis zu 100 Signaturen pro Zeile tragen, geordnet nach der Prioritätsliste in Abschnitt 3.1.3: strikt ausgerichtete bestandene Signaturen zuerst, nicht bestandene zuletzt.

Die neuen Felder in RFC 9990 und was sie verraten

RFC 9990 ersetzt das Report-Format, das innerhalb von RFC 7489 definiert war. Die meisten Änderungen sind klein, und jede von ihnen beantwortet eine Frage, die Sie vorher nicht beantworten konnten. Anhang C von RFC 9990 listet die Unterschiede auf; die Tabelle ergänzt, wofür jeder einzelne gut ist. Durchgestrichene Zeilen sind Werte, die es nicht mehr gibt — wenn Sie sie noch sehen, haben Sie einen Report aus einem älteren Generator vor sich.

Häufige Muster und was sie bedeuten

Vier Situationen machen den größten Teil dessen aus, was Sie in den ersten Monaten beim Lesen von Reports sehen werden. In jedem Fall sagt Ihnen die Zeile in policy_evaluated, was passiert ist, und der Block in auth_results, warum.

Eine unbekannte IP mit SPF-Pass und DKIM-Fail. Die Domain in auth_results/spf ist zu Ihrer From-Domain ausgerichtet, die Mail kommt also von etwas, das Ihr SPF-Record autorisiert, aber es existiert keine ausgerichtete Signatur — meist eine sendende Plattform, die eine Abteilung freigeschaltet hat, die in ein include: aufgenommen wurde und für die nie ein DKIM-Schlüssel eingerichtet wurde. Die zweite Möglichkeit ist schlimmer: Ihre include:-Kette deckt den IP-Bereich eines geteilten Anbieters ab, und ein anderer Mandant auf dieser Plattform besteht SPF für Ihre Domain. Prüfen Sie, ob die IP zu einem Anbieter gehört, mit dem Sie einen Vertrag haben, und sorgen Sie dann dafür, dass diese Plattform signiert. RFC 9989 Abschnitt 8 stellt fest, dass ein Domaininhaber sich für einen DMARC-Pass NICHT allein auf SPF verlassen darf, wenn die Policy p=reject lautet; ein reiner SPF-Strom ist damit ein Blocker für das Enforcement und kein Detail.

DKIM besteht, SPF nicht. Das ist die normale Signatur weitergeleiteter Mail: Der Weiterleiter hat den Envelope-Absender durch seine eigene Domain ersetzt, SPF wurde also für diese Domain ausgewertet und kann nicht ausgerichtet sein, während Ihre Signatur den Sprung überlebt hat. RFC 9989 Abschnitt 4.4.1 stellt klar, dass jeder ausgerichtete DKIM-authentifizierte Identifier für einen DMARC-Pass genügt; diese Records sind also kein Fehler, den man beheben müsste. Prüfen Sie das Muster nach, bevor Sie es abheften: envelope_from sollte die Domain eines anderen sein, das ausgerichtete DKIM-Ergebnis sollte pass sein und die Disposition pass. Steht dort stattdessen none mit einem trusted_forwarder- oder mailing_list-Grund, hat der Empfänger die Nachricht gerettet, nicht DMARC.

Beides schlägt fehl, bei geringem Volumen. Kleine, verstreute Zählungen von IPs, die Sie nicht kennen, oft auf einer Subdomain, von der Sie nie senden, sind das Grundrauschen einer Domain, die existiert: direkte Domainfälschung, Backscatter und kaputte Weiterleitungswege. Prüfen Sie zuerst, ob die Zahlen über mehrere Tage stabil sind und ob die IPs sich in einem Netz häufen — ein beständiges Cluster ist ein vergessener Absender, eine breite Streuung mit ein oder zwei Nachrichten je IP ist Missbrauch. Denken Sie daran, dass count alle Nachrichten umfasst, die der Empfänger angenommen hat, auch die, die seine eigenen Filter später blockiert haben (Abschnitt 3.1); eine Zeile mit einem Wert größer null ist also kein Beleg dafür, dass irgendetwas zugestellt wurde. Verzögern Sie das Enforcement nicht wegen dieses Ausläufers; genau dafür ist p=reject da.

Es kommen keine Reports mehr an. Arbeiten Sie sich von der eigenen Seite nach außen vor. Nimmt das rua-Postfach noch Mail an, und lässt Ihre Filterung application/gzip-Anhänge noch durch? Erreicht Sie der Report-Strom überhaupt noch — Reports MÜSSEN aus einem DMARC-ausgerichteten Mailstrom kommen (Abschnitt 3.5.2), eine Änderung auf der Seite des Reporters kann sie also zum Bouncen bringen. Prüfen Sie dann Ihren Record: Ein Empfänger ignoriert fehlerhafte Reporting-URIs (Abschnitt 3.5), und enthält der Record kein gültiges p-Tag mehr, wird er wie p=none behandelt, solange eine syntaktisch gültige rua-URI übrig bleibt (RFC 9989 Abschnitt 4.10.1) — Reports können also weiter eintreffen, während Ihre Policy klammheimlich nicht mehr greift, und sie hören auf, wenn das rua selbst kaputtgeht. Und wenn Ihre Reports an einen Dritten gehen, vergewissern Sie sich zuletzt, dass der im nächsten Abschnitt beschriebene Autorisierungs-Record noch existiert.

Reports woanders hinschicken: Verifikation externer Ziele

Reporting-Adressen müssen nicht in Ihrer eigenen Domain liegen. Das ist Absicht — es erlaubt einer Domain ohne Mail-Infrastruktur, Reports über einen Dienstleister zu empfangen — und es ist zugleich ein Angriff: Ohne Prüfung könnte jeder einen Record veröffentlichen, der rua auf die Adresse eines Opfers zeigt, und dann eine Flut fehlschlagender Mail senden, damit das Opfer in Reports ertrinkt. RFC 9990 Abschnitt 4 definiert die Verifikation, die das verhindert.

Die Prüfung läuft, wenn sich die Organisationsdomain des Records von der Organisationsdomain des URI-Hosts unterscheidet. Ein rua, das auf einen anderen Namen unter Ihrer eigenen Organisationsdomain zeigt, braucht keinen zusätzlichen Record. Unterscheiden sich die Domains, baut der Empfänger aus dem URI-Host, der Labelfolge _report._dmarc und der Domain, aus der die Policy stammt, einen Namen zusammen und sucht dort nach einem TXT-Record:

; DMARC record of the domain that wants reports
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; "
                           "rua=mailto:dmarc@reports.example.net"

; Authorization published by the report processor
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

; Or, to accept reports for any domain:
*._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

Der Record wird als Tag-Wert-Paare im selben Format wie ein DMARC-Policy-Record geparst; v=DMARC1 ist Pflicht und MUSS zuerst stehen, ein abschließendes Semikolon ist optional, und alles, was diesen Test nicht besteht, wird verworfen. Ein einziger überlebender Record genügt, um die Konstruktion zu autorisieren. Würde der zusammengesetzte Name die DNS-Längengrenzen überschreiten, lässt sich keine positive Feststellung treffen und der Empfänger bricht ab — eine echte Einschränkung bei langen Domainnamen und der Grund, den Hostnamen des Dienstleisters kurz zu halten.

Der Autorisierungs-Record darf auch ein eigenes rua-Tag enthalten, das das vom Domaininhaber gewünschte Ziel überschreibt. Diese überschreibende URI MUSS denselben Zielhost verwenden wie das Original, und benennt sie erneut einen anderen Host, DARF der Empfänger an keine der beiden URIs einen Report schicken. Genau das erlaubt es einem Dienstleister, Reports zwischen seinen eigenen Postfächern zu verschieben, ohne dass jeder Kunde seinen Record ändert, und hält die Konstruktion zugleich davon ab, als Umleitung missbraucht zu werden. RFC 9991 Abschnitt 5 verlangt für Failure-Reports das identische Verfahren, mit ruf anstelle von rua.

Wenn Sie das Reporting delegieren, ist der Record des Delegierten Teil Ihrer Konfiguration, auch wenn er in der Zone eines anderen liegt. Hören Reports nach einem Anbieterwechsel auf, ist der fehlende _report._dmarc-TXT-Record beim neuen Host das Erste, wonach Sie suchen sollten.

Failure-Reports (RFC 9991) und das fo-Tag

Ein Failure-Report betrifft eine einzelne Nachricht, die die DMARC-Auswertung nicht bestanden hat, und trägt so viel von dieser Nachricht, wie die berichtende Partei preiszugeben bereit ist. RFC 9991 §2 beschreibt sie als nahezu unmittelbar nach dem Erkennen des Fehlschlags durch den empfangenden Server erzeugt und versendet und hält fest, dass sie so viel wie möglich von den Header-Feldern und vom Body der Nachricht enthalten sollen, soweit die Datenschutzrichtlinien der berichtenden Partei das zulassen. Genau darin liegen zugleich der ganze Nutzen und das ganze Problem: Ein Aggregate-Report sagt Ihnen, dass 42 Nachrichten von einer IP-Adresse durchgefallen sind, ein Failure-Report legt Ihnen eine dieser Nachrichten vor, damit Sie sehen können, warum.

Failure-Reports sind für den Empfänger in einer Weise optional, wie es Aggregate-Reports nicht sind. RFC 9989 §5.3.5 definiert, wann eine Nachricht an DMARC scheitert; §5.3.8 formuliert für Aggregate-Reports ein SHOULD — empfangende Server sollen sie mindestens alle 24 Stunden erzeugen und versenden; §5.3.9 formuliert für Failure-Reports nur ein MAY — und ergänzt, dass Empfänger, die zu Recht um den Schutz der Privatsphäre ihrer Nutzer besorgt sind, sich entweder dafür entschieden haben, die Informationen in solchen Reports stark zu schwärzen, was deren Nutzen beeinträchtigen kann, oder sie überhaupt nicht zu versenden.

Zwei Tags in Ihrem DMARC-Record steuern das, und sie wirken nur als Paar. Das ruf-Tag benennt die Ziele; das fo-Tag nennt die Bedingungen, unter denen ein Report erzeugt werden soll (RFC 9989 §4.7). Das Report-Format ist das Abuse Reporting Format aus RFC 6591, erweitert durch RFC 9991 §4.

Die vier fo-Werte

Das fo-Tag hat den Standardwert 0. Die Werte 0 und 1 schließen einander aus; jede andere Kombination wird als doppelpunktgetrennte Liste geschrieben, und die Werte dürfen in beliebiger Reihenfolge stehen — fo=0:d und fo=d:0 bedeuten also dasselbe (RFC 9989 §4.7). Report-Generatoren können sich an die angeforderten Optionen halten — das Tag ist eine Bitte, keine Anweisung.

Die Richtung von 0 und 1 lohnt zweimaliges Lesen, denn kommerzielle Dokumentation vertauscht sie häufig. 0 verlangt, dass alle Mechanismen scheitern, bevor ein Report entsteht; 1 verlangt nur, dass irgendeiner von ihnen scheitert. fo=1 ist damit die Einstellung, die strikt mehr Reports erzeugt als der Standard — einschließlich Reports über Nachrichten, die DMARC bestanden haben.

Für d und s macht RFC 9991 §3 den Zusammenhang ausdrücklich: Ein empfangender Server, der DMARC-Failure-Reports erzeugt, kann sich dafür entscheiden, Failure-Reports speziell zu dem gescheiterten Authentifizierungsmechanismus auszustellen — anstelle des DMARC-Failure-Reports oder zusätzlich dazu — und entscheidet anhand seiner eigenen Policy, des konkreten Fehlschlags und des Inhalts des fo-Tags, welche Typen er versendet. Dieselben Reports lassen sich über die Mechanismen aus RFC 6651 und RFC 6652 auch unabhängig von DMARC anfordern.

Ohne ruf wird fo vollständig ignoriert

Das ist der mit Abstand häufigste Weg, auf dem eine Failure-Report-Konfiguration am Ende gar nichts tut. RFC 9989 §4.7 formuliert es als harte Bedingung: Der Inhalt des fo-Tags MUSS ignoriert werden, wenn nicht zugleich ein ruf-Tag angegeben ist. Und das ruf-Tag selbst trägt die dazu passende Regel — fehlt es, dürfen empfangende Server für die Domain keine Failure-Reports erzeugen (MUST NOT).

Beachten Sie: fo=0:1 ist nicht gültig — die beiden Werte schließen einander aus (RFC 9989 §4.7).

Warum die meisten großen Empfänger nichts davon versenden

Die Offenlegung beschränkt sich nicht auf Ihre eigene Mail. RFC 9991 §7.1 nennt zwei Folgen, die die meisten Betreiber überraschen. Erstens erhält ein Domaininhaber, der Reports anfordert, Informationen über Mail, die seine Domain benutzt, deren Versand er aber nicht veranlasst hat — ein wertvoller Einblick in missbräuchliche Inhalte, aber eben auch möglicherweise personenbezogene oder nicht-öffentliche Informationen aus legitimen Nachrichten, die versehentlich an der Authentifizierung gescheitert sind. Zweitens können Informationen über das endgültige Ziel einer Nachricht offengelegt werden, das sonst durch zwischengeschaltete Systeme verdeckt wäre: Das im RFC genannte Beispiel ist die Offenlegung der Mitglieder einer Mailingliste, wenn ein Listenmitglied schreibt und bei der Zustellung dieser Nachricht an die übrigen Mitglieder Failure-Reports erzeugt werden. Weiterleitungen haben denselben Effekt und machen Ziele sichtbar, die dem Domaininhaber vorher unbekannt waren.

RFC 9991 §7 zählt auf, wozu Betreiber, die Failure-Reporting doch einschalten, nachdrücklich angehalten werden: Umfang und Dauer der Nutzung auf gezielte Diagnosevorgänge begrenzen, die Report-URIs sorgfältig kontrollieren und validieren, Minimierungstechniken wie das Schwärzen von Nachrichten-Bodys und Header-Feldern anwenden und Reports stets über sichere Kanäle übertragen. §7.3 ergänzt die Anforderungen an den Umgang auf der Empfangsseite, denn teilweise oder gar nicht geschwärzte Reports können Spam-, Phishing- oder Malware-Inhalte weitertragen: Report-Ströme von anderen Mail-Strömen trennen, Reports in Sandboxes auswerten, Netzsegmentierung einsetzen und den Zugriff auf befugte Personen mit angemessener Sicherheitsschulung beschränken.

Es gibt ein Folgerisiko im DNS selbst. RFC 9989 §11.6 merkt an, dass die Adressen im ruf-Tag mehr Informationen erhalten, die als private Daten gelten können, was diese URIs zu attraktiveren Zielen für Einbruchsversuche macht als die im rua-Tag, und dass ein Angriff auf das DNS der betroffenen Domain, um Failure-Daten auf die Systeme eines Angreifers umzuleiten, eine attraktive Aussicht sein kann; wo das ein Thema ist, empfiehlt sich der Einsatz von DNSSEC.

PSDs dürfen keine Failure-Reports anfordern

Für Public Suffix Domains gelten zwei Regeln, und sie stehen in unterschiedlichen Dokumenten.

• RFC 9991 §2, an den Report-Generator gerichtet: Report-Generatoren dürfen ruf-Tags in DMARC-Policy-Records mit einem psd=y-Tag nicht berücksichtigen (MUST NOT), sofern es keine besonderen Vereinbarungen zwischen den Beteiligten gibt. Ein PSD-Record mit ruf ist damit bei jedem regelkonformen Empfänger standardmäßig wirkungslos.
• RFC 9989 §10.2, an den Veröffentlichenden gerichtet: DMARC-Policy-Records für organisationsübergreifende PSDs dürfen das ruf-Tag überhaupt nicht enthalten (MUST NOT).

Die Begründung ist dieselbe, die RFC 9989 §10.2 für Failure-Reports allgemein gibt: Sie geben Einblick in E-Mail-Sendemuster bis hinunter zu einzelnen Nutzern, und bevor Failure-Reports überhaupt angefordert werden, müssen solche Risiken des Datenabflusses durch Kontrollen der Datenverwaltung adressiert werden. Die entsprechende Regel für Aggregate-Reports ist schwächer — §10.1 warnt, dass organisationsübergreifende PSDs, die ihren Registranten DMARC nicht vorschreiben, mit einem rua-Tag die Offenlegung privater Registrantendaten riskieren; das ist aber eine Warnung, kein Verbot.

Was der Report selbst enthält

RFC 9991 §4 ergänzt das Report-Format aus RFC 6591 um eine Reihe DMARC-spezifischer Header-Felder des Abuse Reporting Format. Zu wissen, welche davon erforderlich sind, ist das, was einen regelkonformen Report von einem unvollständigen unterscheidbar macht.

RFC 9991 §4 definiert außerdem den Authentifizierungs-Fehlschlagstyp dmarc für das ARF-Feld Auth-Failure; er wird verwendet, wenn ein Failure-Report erzeugt wird, weil einige oder alle Authentifizierungsmechanismen keine ausgerichteten Identifier geliefert haben.

Reports an eine andere Domain schicken: die _report._dmarc-Autorisierung

Nichts im DNS hindert Sie daran, rua=mailto:reports@thirdparty.example.net in Ihrem eigenen DMARC-Record zu veröffentlichen. Genau dieses Problem löst RFC 9990 §4. Ohne Prüfung könnte ein Angreifer einen DMARC-Policy-Record veröffentlichen, der Reports an die Adresse eines Opfers anfordert, und anschließend große Mengen Mail, die sowohl DKIM als auch SPF verfehlt, an die unterschiedlichsten Ziele senden; das Opfer würde dann mit unerwünschten Reports überflutet. Die empfangende Domain muss also zustimmen — und sie stimmt in ihrem eigenen DNS zu.

Wann die Prüfung ausgelöst wird

Ausgelöst wird sie durch einen Vergleich von Organisationsdomains, nicht von Hostnamen. RFC 9990 §4: Wenn ein empfangender Server einen DMARC-Policy-Record findet und die Organisationsdomain, unter der dieser Record gefunden wurde, nicht mit der Organisationsdomain des Host-Teils der Authority-Komponente der URI im rua-Tag identisch ist, müssen die Verifikationsschritte durchlaufen werden.

Wie der Name gebildet wird

RFC 9990 §4 gibt die Bildung als geordnetes Verfahren an:

1. Den Host-Teil der Authority-Komponente der URI extrahieren. Das ist der Ziel-Host, da er auf einen Report-Empfänger verweist.
2. Die Zeichenfolge _report._dmarc voranstellen.
3. Den Domainnamen voranstellen, von dem die Policy geholt wurde — nötigenfalls nach Umwandlung in ein A-Label.
4. Überschreitet die Länge des gebildeten Namens die DNS-Grenzen, lässt sich die externe Report-Beziehung nicht positiv feststellen; Abbruch.
5. Das DNS nach einem TXT-Record unter dem gebildeten Namen abfragen. Ist das Ergebnis ein vorübergehender DNS-Fehler wie ein Timeout, kann der empfangende Server die Zustellung vorübergehend scheitern lassen, damit die Prüfung später wiederholt werden kann.

Durchgespielt am Beispiel aus RFC 9989 Anhang B.2.3, in dem example.com einen Dritten bittet, seine Failure-Reports entgegenzunehmen:

; published by example.com
_dmarc.example.com.  IN  TXT  ( "v=DMARC1; p=none; "
                                "rua=mailto:dmarc-feedback@example.com; "
                                "ruf=mailto:auth-reports@thirdparty.example.net" )

; published by the report consumer, in the zone thirdparty.example.net
example.com._report._dmarc.thirdparty.example.net.  IN  TXT  "v=DMARC1;"

Was als gültiger Autorisierungs-Record zählt

Die Schritte 6 bis 8 aus RFC 9990 §4 definieren den Annahmetest, und er ist bewusst minimal. Jeder zurückgelieferte TXT-Record wird als Folge von tag=value-Paaren im selben Gesamtformat wie ein DMARC-Policy-Record geparst; das Tag v=DMARC1 ist verpflichtend und MUSS in der Liste an erster Stelle stehen, und jeder Record, der daran scheitert, wird verworfen. Ein abschließendes Semikolon ist optional. Besteht kein zurückgelieferter TXT-Record das grundlegende Parsen, lässt sich nichts positiv feststellen, und das Verfahren bricht ab. Bleibt nach dem Parsen mindestens ein Record übrig, wurde die externe Report-Beziehung vom Report-Empfänger autorisiert.

Ein Report-Empfänger, der Reports für beliebige Domains annehmen will, kann eine Wildcard verwenden: Ein TXT-Record unter *._report._dmarc.example.net, der mindestens v=DMARC1 enthält, bestätigt, dass example.net bereit ist, DMARC-Reports für jede beliebige Domain zu empfangen (RFC 9990 §4). Wird der Empfänger vom Volumen überrollt, kann er den bestätigenden Record einfach entfernen — wegen des positiven Cachings greift die Änderung allerdings erst, wenn die TTL des Records abgelaufen ist.

Die Längengrenze

Schritt 4 des Verfahrens ist ein echter Fehlerfall und keine Formalie, denn der gebildete Name ist die Aneinanderreihung zweier vollständiger Domainnamen plus zweier fester Labels. RFC 9990 §4 sagt dazu nur, dass sich die externe Report-Beziehung bei Überschreiten der DNS-Längengrenzen nicht positiv feststellen lässt und das Verfahren abbricht — was zusammen mit der Regel, dass eine unbestätigte URI ignoriert werden MUSS, bedeutet: Die Reports werden stillschweigend nicht versendet. Der Rat des RFC für diesen Fall lautet, dass der Domaininhaber möglicherweise einen kürzeren Domainnamen in Betracht ziehen oder sich mit einer anderen Partei abstimmen muss, die ein kürzeres DNS-Label ermöglicht. Wenn ein Report-Dienstleister einen kurzen Reporting-Hostnamen anbietet, hat das seinen Grund.

Wenn der Autorisierungs-Record das Ziel umleitet

Schritt 9 aus RFC 9990 §4 erlaubt es dem Ziel, den Report-Empfang umzuleiten. Findet sich im Autorisierungs-Record ein rua-Tag, ersetzt der empfangende Server den Wert aus Ihrem DMARC-Record durch den aus dem Autorisierungs-Record. Damit kann der Report-Empfänger das Report-Ziel überschreiben — nützlich, wenn der Dienstleister sein Postfach gewechselt hat oder gegen einen Tippfehler im DMARC-Record eines Kunden robust sein will (RFC 9989 Anhang B.2.4).

Zwei Grenzen umgeben das, beide gegen Schleifen und indirekten Missbrauch gerichtet:

• Die Umleitung muss auf demselben Host bleiben. RFC 9990 §4: Um Schleifen oder indirekten Missbrauch zu verhindern, MUSS die überschreibende URI denselben Ziel-Host aus dem ersten Schritt verwenden. Ein Dienstleister kann reports@thirdparty.example.net auf aggregate-reports@thirdparty.example.net umleiten; auf eine andere Domain kann er nicht umleiten.
• Eine domainübergreifende Umleitung vergiftet beide URIs. Enthält der bestätigende Record eine URI, deren Host wiederum von der Domain abweicht, die diese Umleitung veröffentlicht, darf der empfangende Server weder an die ursprüngliche noch an die überschreibende URI einen Report erzeugen (MUST NOT). Der Umleitungsversuch scheitert nicht bloß — er kostet Sie zusätzlich das ursprüngliche Ziel.

; zone file for thirdparty.example.net
; accept DMARC reports on behalf of example.com and override the mailboxes
example.com._report._dmarc.thirdparty.example.net.  IN  TXT  (
        "v=DMARC1; "
        "rua=mailto:aggregate-reports@thirdparty.example.net; "
        "ruf=mailto:failure-reports@thirdparty.example.net" )

Für ruf gilt dasselbe Verfahren

RFC 9991 §5 definiert keinen eigenen Mechanismus. Ein empfangender Server, der Failure-Reports an ein externes Ziel erzeugt, MUSS das Verfahren „Verifying External Destinations“ aus RFC 9990 §4 anwenden und dabei überall dort, wo in diesem Verfahren das rua-Tag steht, das ruf-Tag einsetzen. Der gebildete Name ist identisch — das Label-Paar _report._dmarc trägt beide Report-Typen, und ein einziger Autorisierungs-Record deckt rua und ruf gleichermaßen ab, sofern er nicht eines von beiden überschreibt.

RFC 9991 §5 gibt dieselbe Begründung in beide Richtungen: Die Prüfung verhindert, dass ein Angreifer einen DMARC-Policy-Record veröffentlicht, der Failure-Reports an ein externes Ziel anfordert, und diese Reports dann absichtlich als Form des Missbrauchs erzeugen lässt; und sie verhindert, dass ein Domaininhaber einem externen Ziel einseitig unerwünschte Nachrichten und mögliche Datenschutzprobleme aufzwingt. Angesichts dessen, was §7.1 über den Inhalt eines Failure-Reports sagt, wiegt die zweite Hälfte dieses Satzes genauso schwer wie die erste.

Unser Scanner führt dieses Verfahren für die mailto:-Ziele Ihrer rua- und ruf-Tags aus — für die ersten acht verschiedenen Ziel-Hosts, gezählt noch vor der Entscheidung extern/intern. Eine Report-URI mit anderem Schema wird hier nicht aufgelöst: mailto: ist das einzige Schema, das ein Report-Erzeuger unterstützen muss, und RFC 9990 §3.5.3 überlässt weitere Schemata späteren Fassungen. Für jeden dieser Hosts bestimmt er die Organisationsdomain, bildet für die als extern erkannten den _report._dmarc-Namen, prüft den Namen gegen die DNS-Längengrenze, schlägt den Autorisierungs-Record nach und wendet die Regel aus Schritt 9 an, nach der eine auf einen anderen Host zeigende Umleitung die Reports vollständig unterbindet. Siehe die Prüfung dmarc-rua-ext.

Fehlersuche: ein Entscheidungsbaum

Fast jedes DMARC-Problem, das in der Praxis gemeldet wird, geht auf eine kleine Zahl von Ursachen zurück, und der schnellste Weg zur richtigen führt über das Symptom statt über den Record. Wählen Sie unten das Symptom und arbeiten Sie sich durch die Zweige: Jeder endet damit, wie der Fehler aussieht, wie Sie ihn bestätigen und was Sie ändern müssen. Die einschlägigen Abschnitte aus RFC 9989, RFC 9990 und RFC 9991 sind dort genannt, wo das Verhalten normativ ist — so können Sie die Begründung nachlesen, statt sie glauben zu müssen.

Mailinglisten, Weiterleitung und ARC

DMARC hat eine strukturelle Schwäche, und sie ist nicht kryptografisch: Das Protokoll wurde für Mail entworfen, die vom System des Autors zum System des Empfängers läuft — und ein großer Teil der legitimen Mail tut das nicht. RFC 9989 §7.4 benennt die betroffenen Wege — Alumni-Weiterleiter, rollenbasierte Aliase und Mailinglisten — und stellt unmissverständlich fest, dass p=reject mit ihnen unvereinbar sein und Interoperabilitätsprobleme verursachen kann.

Warum eine Liste die Authentifizierung bricht

Die beiden Mechanismen scheitern auf einem indirekten Weg unterschiedlich. SPF scheitert am ersten Hop, der nicht Ihrer ist: Die verbindende IP-Adresse gehört dem Weiterleiter, und sofern dieses Relay die MAIL-FROM-Adresse nicht umschreibt, wird die SPF-Prüfung für Ihre Domain aus dem Netz eines anderen heraus durchgeführt (§7.4). DKIM übersteht einfache Weiterleitung meist — RFC 9989 hält fest, dass DKIM-Signaturen in solchen Relay-Situationen in der Regel gültig bleiben —, und genau deshalb verlangt derselbe Abschnitt, dass Domains mit p=reject sich NICHT allein auf SPF verlassen DÜRFEN und ihre Nachrichten mit gültigen DKIM-Signaturen versehen MÜSSEN.

Eine Mailingliste ist aber keine einfache Weiterleitung. Listensoftware verändert die Nachricht routinemäßig: ein Tag vor dem Subject:-Feld, eine Fußzeile am Ende des Nachrichtenkörpers, mitunter ein geändertes Content-Transfer-Encoding oder ein Header, den die Liste für ihre eigene Buchführung ergänzt. Jeder dieser Eingriffe berührt Material, das die DKIM-Signatur abdeckt; die Signatur, die den Weiterleiter überstanden hat, übersteht die Liste also nicht, und damit sind beide Identifier weg. Ob eine bestimmte Signatur bricht, hängt davon ab, welche Header-Felder der Signierer abgedeckt hat und ob der Nachrichtenkörper vollständig signiert wurde — deshalb kann eine Liste Ihre Mail brechen und eine andere sie unversehrt lassen.

Die Folge trifft nicht nur den Absender. RFC 9989 §7.4 beschreibt, was passiert, wenn ein Empfänger p=reject bei Listenverkehr ohne weitere Analyse befolgt: Für die Listensoftware sieht die Ablehnung wie eine tote Adresse aus, und der Abonnent wird automatisch ausgetragen. Deshalb verlangt derselbe Abschnitt, dass Empfänger eingehende Nachrichten NICHT allein auf Grundlage einer p=reject-Policy ablehnen DÜRFEN und dass sie solche fehlschlagende Mail mangels anderer Kenntnisse und Analysen so behandeln MÜSSEN, als wäre die Policy p=quarantine.

Deshalb hat sich die Listensoftware angepasst, statt zu warten. RFC 9989 §7.4 beschreibt die Behelfslösungen als fest etabliert und von Listenbetreibern als gegeben hingenommen: In den zehn Jahren, seit große Consumer-Mailsysteme p=reject veröffentlichen, hat Listensoftware das Umschreiben des From:-Header-Felds übernommen, sodass es DMARC-ausgerichtet ist — die einen mit der Adresse der Liste selbst, die anderen mit einer umkehrbaren Form je Adresse wie bob=example.com@user.somelist.example. Ihre Domain erscheint dann nicht mehr als Autor der Nachricht; das ist der Preis, den die Liste für die Zustellung zahlt, und ein Grund, warum RFC 9989 §7.4 rät, dass Domains mit Nutzern, die in Mailinglisten schreiben, p=reject NICHT veröffentlichen SOLLTEN und dass diejenigen, die es doch tun, ihren Nutzern sagen sollten, dass ihre Listenteilnahme beeinträchtigt sein kann.

ARC: das frühere Urteil weitertragen

Die Authenticated Received Chain (ARC, RFC 8617) geht das Problem von der anderen Seite an. Statt zu versuchen, die ursprüngliche Signatur intakt zu halten, hält ein Vermittler die Authentifizierungsergebnisse fest, die er beim Empfang der Nachricht gesehen hat, versiegelt diesen Vermerk kryptografisch und gibt ihn weiter. Ein nachgelagerter Empfänger, der eine Kette vorfindet, in der das Siegel jedes Hops gültig ist, kann sehen, was SPF, DKIM und DMARC ergeben haben, bevor die Nachricht verändert wurde, und kann sich entscheiden, eine Nachricht anzunehmen, deren eigene DMARC-Auswertung inzwischen scheitert.

Die Grenze liegt dort, wo die ganze Idee aufsitzt: Eine ARC-Kette ist eine Behauptung des Vermittlers, kein Beweis über die Nachricht in ihrem jetzigen Zustand. Eine gültige Kette sagt, dass eine bestimmte siegelnde Domain behauptet, ein bestimmtes Urteil gesehen zu haben — sie sagt nicht, dass diese Domain ehrlich ist. Ein Empfänger profitiert von ARC also nur, wenn er den siegelnden Domains in der Kette vertraut, und dieses Vertrauen aufzubauen ist Sache der lokalen Policy des Empfängers, nichts, was der Absender veröffentlichen könnte. Die makellose Kette eines unbekannten Vermittlers bringt Ihnen bei einem Empfänger, der keinen Grund hat, ihm zu vertrauen, nichts.

Seien Sie ebenso vorsichtig damit, wie weit ARC verbreitet ist. RFC 9989 §7.4 stellt fest, dass Mail-Entwickler seit einem Jahrzehnt versuchen, technische Verfahren zu erfinden, mit denen Mailinglisten ohne Veränderung des From:-Header-Felds funktionieren — ARC als prominentes Beispiel —, und dass zum Zeitpunkt der Veröffentlichung keines dieser Verfahren breite Verwendung gefunden hat; das Dokument fügt hinzu, dass es aktualisiert werden kann, falls das doch geschieht. Behandeln Sie ARC als etwas, das dort hilft, wo der Empfänger bereits mitmacht, nicht als Grund, eine strengere Policy zu veröffentlichen, als Ihre indirekten Mailwege tragen können.

Wenn Sie eine echte Kette sehen wollen, statt über eine nachzudenken: Der Sende-Test prüft ARC-Ketten der von Ihnen gesendeten Nachricht. Er listet jeden Hop mit seiner siegelnden Domain auf und meldet getrennt, ob Siegel und Nachrichtensignatur dieses Hops kryptografisch gültig sind. Diese Unterscheidung zählt, wenn Sie selbst einen weiterleitenden Hop betreiben, denn sie trennt eine Kette, die Sie gebrochen haben, von einer, die schon gebrochen ankam.

DMARC und BIMI

BIMI — Brand Indicators for Message Identification — erlaubt einem Domaininhaber, einen Indikator zu veröffentlichen, den teilnehmende Mail-Clients neben authentifizierten Nachrichten anzeigen dürfen. Es ist nicht Teil von DMARC und wird separat spezifiziert, im Internet-Draft draft-brand-indicators-for-message-identification (Revision 14, 1. Mai 2026; er hat den früheren draft-blank-ietf-bimi abgelöst), der weiterhin ein Entwurf ist und weiterhin auf die ältere DMARC-Spezifikation RFC 7489 statt auf RFC 9989 verweist. Relevant ist es hier, weil BIMI keine eigene Authentifizierung mitbringt: Es leiht sich die von DMARC — und zwar nur dort, wo die Policy auch wirklich durchgesetzt wird (Enforcement, also p=quarantine oder p=reject statt p=none).

Der Draft nennt die Voraussetzung in seiner Einleitung: Um an BIMI teilzunehmen, müssen Domaininhaber eine starke DMARC-Policy — quarantine oder reject — sowohl auf der Organisationsdomain als auch auf der From:-Domain der Nachricht haben. Seine empfängerseitigen Anforderungen in §7.1 machen daraus konkrete Bedingungen, die eine Nachricht erfüllen muss, bevor überhaupt eine BIMI-Verarbeitung stattfinden darf:

• Das DMARC-Ergebnis für die Author Domain muss pass sein; ist es das nicht und rettet es auch kein zusätzliches Authentifizierungsverfahren, DARF keine BIMI-Verarbeitung stattfinden.
• Lautet die Policy für die Author Domain oder deren Organisationsdomain p=none, DARF keine BIMI-Verarbeitung stattfinden.
• Enthält der Record eine Subdomain-Policy und lautet diese sp=none, DARF keine BIMI-Verarbeitung stattfinden.
• Lautet die Policy p=quarantine und definiert der Record ein Prozent-Tag, MUSS dieses pct=100 sein, sonst DARF keine BIMI-Verarbeitung stattfinden.

Lesen Sie die letzte Bedingung genau, denn sie wird regelmäßig in einer falschen Form weitergegeben. Die Anforderung ist bedingt: Falls ein solches Tag vorhanden ist, muss sein Wert 100 sein. Nichts in der Spezifikation verlangt, dass Sie ein pct-Tag ergänzen, und es gibt keinen Grund, eines zu haben. RFC 9989 hat pct ganz aus dem Standard entfernt (Appendix C.5.2), die IANA-Registry der DMARC-Tags führt es inzwischen als historisch (§9.3), und unbekannte Tags MÜSSEN von Empfängern ignoriert werden, die der aktuellen Spezifikation folgen (§4.7). Trägt Ihr Record aus einer älteren Installation noch pct=100, erfüllt er die BIMI-Bedingung und kostet nichts; der sauberere Record ist der ohne.

Eine Abweichung ist es wert, bekannt zu sein, denn sie entscheidet darüber, was Werkzeuge Ihnen melden. Die Bedingung des Entwurfs ist konditional und auf p=quarantine beschränkt; der Implementierungsleitfaden der BIMI Group ist das nicht und hält schlicht fest, „None“-Policies oder ein „pct“ unter 100 Prozent werden nicht akzeptiert. Ein Record mit p=reject; pct=25 erfüllt also die Spezifikation und scheitert an der Branchen-Leitlinie. Unser eigener Scanner folgt bewusst der strengeren Lesart und meldet einen solchen Record als nicht BIMI-tauglich. Das ist eine Abwägung, keine Aussage über das Protokoll, und sie beruht auf der ungleichen Kostenlage: Ein pct-Tag zu löschen ist billig, aber nicht gratis — konforme Empfänger ignorieren es zwar, Empfänger auf RFC-7489-Stand nicht, das Löschen hebt sie also auf volle Durchsetzung, weshalb vorher jeder Versandweg ausgerichtet sein muss — ein Logo, das nie erscheint, hat dagegen bereits ein Mark-Zertifikat gekostet. Von außerhalb eines Mailanbieters lässt sich nicht beobachten, welche Regel ein Postfach tatsächlich anwendet; behandeln Sie jede selbstbewusste Aussage in die eine oder andere Richtung — unsere eingeschlossen — daher als Positionsbezug und nicht als Messung.

Ein Tag verdient eine eigene Warnung, und es ist eines, das der BIMI-Draft überhaupt nicht erwähnt: t=y. RFC 9989 §4.7 definiert t=y als Bitte an den prüfenden Akteur, die deklarierte Policy nicht anzuwenden, sondern fehlschlagende Nachrichten eine Stufe darunter zu behandeln — reject wird als quarantine angewendet und quarantine als none. Ein Record mit p=quarantine; t=y bittet Empfänger also um genau die Behandlung, die BIMIs eigener §7.1 ausschließt. Da der Draft gegen RFC 7489 geschrieben wurde, das kein t-Tag kannte — und Revision 14 vom 1. Mai 2026 ist das durchgehend noch immer —, sagt er nichts darüber, wie ein Empfänger diese Kombination lesen soll, und unsere eigenen Werkzeuge lassen sie nicht offen. t=y gilt im Domain-Scan und im Record Studio als „DMARC nicht durchgesetzt“, selbst p=reject; t=y wird also als nicht BIMI-tauglich gemeldet. Anders als bei der pct-Regel oben wählen wir hier nicht zwischen zwei veröffentlichten Quellen; es ist unser eigenes Urteil in einer Lücke des Entwurfs, und es beruht auf einem Gedanken: Eine Sprosse einer Rollout-Leiter ist keine Policy, an der ein Logo hängen sollte. Der Ausweg ist, den Rollout abzuschließen, nicht die Sprosse zu entfernen.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

Die DMARC-Seite ist die Voraussetzung, nicht die ganze Arbeit — der Indikator selbst, sein SVG-Profil und das Verified Mark Certificate, das manche Mailbox-Anbieter verlangen, sind eigene Themen. Der BIMI-Check bewertet einen veröffentlichten BIMI-Record zusammen mit der DMARC-Policy, die ihn tragen muss, und der BIMI-Generator baut den Record.

Wie DMARC zum Rest des Mail-Stacks passt

DMARC beantwortet eine Frage: Darf dieser Absender diese Domain im From:-Header-Feld verwenden? Es sagt nichts darüber, wie die Nachricht gereist ist, und die Transportprotokolle sagen nichts darüber, wer sie geschrieben hat. Beides auseinanderzuhalten ist der Unterschied zwischen einer Diagnose und einer Vermutung: MTA-STS und DANE können keinen gefälschten Absender aufhalten, und DMARC kann keine abgefangene Verbindung aufhalten.

Prüfungen für all das liegen in eigenen Werkzeugen: SPF-, DKIM- & DMARC-Check für die Absenderidentität, MTA-STS-Test und DANE-Test für den Transport und der Domain-Scan für alles auf einmal.

Häufige Fragen

Quellen

RFC 9989 – DMARC (aktueller Standard) ↗ · RFC 9990 – DMARC Aggregate Reporting ↗ · RFC 9991 – DMARC Failure Reporting ↗ · RFC 7489 – DMARC (obsolet) ↗ · RFC 9091 – PSD DMARC (obsolet) ↗ · RFC 7208 – SPF ↗ · RFC 6376 – DKIM ↗ · RFC 8617 – ARC ↗ · RFC 8601 – Authentication-Results ↗