Mailbox-Anbieter schicken dem Inhaber einer DMARC-geschützten Domain Aggregate-Reports: ein XML-Dokument je Empfänger und Tag, das jede IP-Adresse nennt, die Mail unter Ihrer Domain verschickt hat, wie viele Nachrichten es waren und ob DKIM, SPF und DMARC gehalten haben. Legen Sie die Reports hier ab und lesen Sie sie entschlüsselt – jede Quelle mit eigener Ampel in Rot, Orange oder Grün, jedes Ergebnis erklärt, jedes Feld mit seinem RFC-Abschnitt.
Report-Dateien hier ablegen – .xml, .xml.gz oder .zip, auch mehrere auf einmal.
Jede versendende IP-Adresse bekommt Grün, Orange oder Rot aus ihrer DMARC-Pass-Quote, der Report als Ganzes aus der nachrichtengewichteten Quote – daneben die Zahl roter und oranger Quellen, damit eine gefälschte Nachricht ihre Quelle färbt und nicht Ihren Monat.
Je Record sagt der Viewer, was wirklich passiert ist: DKIM gültig, aber mit der falschen Domain signiert; SPF besteht für die Bounce-Domain statt für Ihre; eine Quelle ganz ohne Authentifizierung; ein Weiterleiter, eine Mailingliste, ein Override durch den Empfänger.
Reports nach RFC 9990 (Namensraum dmarc-2.0, mit discovery_method, testing, np, generator) und das Format nach RFC 7489, das die meisten Empfänger noch schicken (mit pct und den zurückgezogenen Override-Gründen). Das Format erscheint als Badge; Werte außerhalb der RFC-Listen werden markiert, nicht still verworfen.
Ein eigener XML-Leser, der weder DOCTYPE noch Entity-Deklarationen kennt, byteweise gezählte Dekompression für .gz und .zip und Deckel für Größe, Tiefe und Record-Zahl – die Angriffe, vor denen RFC 9990 §8.1 Report-Verarbeiter warnt, erreichen einen Browser-Tab nicht, der nie eine Entity expandiert.
Die Pass-Quote ist der Anteil der Nachrichten, bei denen policy_evaluated DKIM oder SPF im Alignment als bestanden meldet – das DMARC-Ergebnis, wie RFC 9989 §5.3.5 es definiert. Die Schwellen sind unsere Entscheidung, kein RFC-Wert:
| Ebene | Grün | Orange | Rot |
|---|---|---|---|
| Quelle (IP) | Pass-Quote ≥ 98 % und mindestens eine Nachricht mit aligned DKIM | Pass-Quote 90–98 %, oder ≥ 98 % ohne eine einzige aligned DKIM-Nachricht („nur SPF“) | Pass-Quote unter 90 % |
| Report | Pass-Quote ≥ 98 % | 90–98 % | unter 90 % |
„Nur SPF“ ist orange, weil SPF beim ersten Weiterleiter bricht, während eine aligned DKIM-Signatur ihn übersteht (RFC 9989 §7.4). Die SPF-Spalte selbst wird nie gefärbt: Versanddienste mit eigener Bounce-Domain und Weiterleiter sind regulär SPF-unaligned und bestehen trotzdem über DKIM.
Die Ampel misst, was Empfänger gesehen haben, nicht, wie Ihre Domain konfiguriert ist. Eine korrekt konfigurierte Domain unter Spoofing-Beschuss zeigt rote Quellen mit Absicht – die Quellentabelle sagt, ob diese IPs Ihre sind.
Abschnittsnummern beziehen sich auf RFC 9990, wenn kein anderes Dokument genannt ist. Die DMARC-Referenz geht einen vollständigen Report Zeile für Zeile durch.
report_metadata – wer den Report geschickt hat (§3.1.1.3)org_name, email, extra_contact_inforeport_iddate_range → begin, enderrorrua oder mehrere Records an einem Namen (§3.1.5).generatorpolicy_published – der Record, den der Empfänger angewandt hat (§3.1.1.5)domaindiscovery_methodtreewalk = über den DNS-Tree-Walk aus RFC 9989 gefunden, psl = nach RFC 7489 über die Public Suffix List. Neu in RFC 9990.p, sp, npsp folgt p, np folgt sp.adkim, aspfr relaxed (Organisationsdomain genügt) oder s strict (exakt gleich). Default r.psd=-Tags schneiden den Walk ab. Relaxed Alignment vergleicht Organisationsdomains. Der optionale DNS-Check bestimmt sie so wie der Scan der Seite; Empfänger nach RFC 7489 benutzen die Public Suffix List und können abweichen.fo0.testingt-Tags: y bittet Empfänger, die Policy eine Stufe milder anzuwenden als veröffentlicht (RFC 9989 §4.7). Neu in RFC 9990.pctrecord → row – eine IP, eine Ergebniskombination (§3.1.1.8, §3.1.1.9)source_ip, countpolicy_evaluated → dispositionnone, quarantine, reject – oder pass, neu in RFC 9990, für eine Nachricht, die unter einer durchgesetzten Policy bestand.policy_evaluated → dkim, spfauth_results. DMARC besteht, wenn mindestens eines der beiden pass ist.reason → type, commentlocal_policy, mailing_list, trusted_forwarder, policy_test_mode (Ihr t=y), other; RFC 7489 kannte zusätzlich forwarded und sampled_out (aus pct).identifiers – die Domains, gegen die geprüft wurde (§3.1.1.10)header_fromenvelope_fromenvelope_toauth_results – die rohen DKIM- und SPF-Prüfungen (§3.1.1.11 bis §3.1.1.13)dkim → domain, selector, result, human_resultd= und s= der Signatur, das Ergebnis nach RFC 8601 §2.7.1 (pass, fail, neutral, policy, temperror, permerror, none) und Freitext des Empfängers. RFC 9990 macht den Selector zur Pflicht und empfiehlt höchstens 100 Signaturen je Zeile (§3.1.3).spf → domain, scope, result, human_resultmfrom; RFC 7489 erlaubte auch helo), das Ergebnis nach RFC 8601 §2.7.2 (zusätzlich softfail) und Freitext.extension und Elemente mit Namensraum (§3.2)Erweiterungen dürfen Elemente mit eigenem Namensraum auf oberster Ebene oder am Ende eines Records ergänzen. Der Viewer zählt sie und ignoriert ihren Inhalt; Elemente ohne Namensraum, die das Schema nicht kennt, stehen in den Formathinweisen.
Empfänger schicken sie an die Adressen im rua=-Tag Ihres DMARC-Records, als Mail-Anhang mit dem Namen empfaenger!ihre-domain!begin!end.xml.gz (RFC 9990 §3.5.2). Das XML soll gzip-komprimiert sein; einige große Empfänger schicken stattdessen ein ZIP, diese Seite liest beides. Ohne rua keine Reports: der DMARC-Generator ergänzt das Tag, der Domain-Sicherheitscheck sagt Ihnen, ob Ihres gesetzt und eine externe Report-Adresse autorisiert ist.
Forensik-Reports (Failure-Reports) – das ruf=-Tag, RFC 9991 – sind ein anderes Format und werden hier nicht gelesen.