Mailbox providers send the owner of a DMARC-protected domain aggregate reports: one XML document per receiver and day, listing every IP address that sent mail under your domain, how many messages it sent, and whether DKIM, SPF and DMARC held. Drop the reports here and read them decoded – every source with its own red, orange or green light, every result explained, every field named with its RFC section.
Drop report files here – .xml, .xml.gz or .zip, several at once.
Every sending IP address gets green, orange or red from its DMARC pass rate, and the report as a whole from the message-weighted rate – with the number of red and orange sources next to it, so one spoofed message colours its source, not your month.
Per record the viewer says what actually happened: DKIM valid but signed with the wrong domain, SPF passing for the bounce domain instead of yours, a source without any authentication, a forwarder, a mailing list, a policy override by the receiver.
RFC 9990 reports (namespace dmarc-2.0, with discovery_method, testing, np, generator) and the RFC 7489 format most receivers still send (with pct and the retired override reasons). The format is shown as a badge; values outside the RFC lists are flagged, not silently dropped.
An own XML reader that knows no DOCTYPE and no entity declarations, byte-counted decompression for .gz and .zip, and ceilings on size, depth and record count – the attacks RFC 9990 §8.1 warns report processors about cannot reach a browser tab that never expands an entity.
The pass rate is the share of messages whose policy_evaluated says DKIM or SPF passed in alignment – the DMARC result as RFC 9989 §5.3.5 defines it. The thresholds are our choice, not an RFC value:
| Level | Green | Orange | Red |
|---|---|---|---|
| Source (IP) | pass rate ≥ 98 % and at least one message with aligned DKIM | pass rate 90–98 %, or ≥ 98 % without a single aligned DKIM pass (“SPF only”) | pass rate below 90 % |
| Report | pass rate ≥ 98 % | 90–98 % | below 90 % |
“SPF only” is orange because SPF breaks at the first forwarder while an aligned DKIM signature survives it (RFC 9989 §7.4). The SPF column itself is never coloured: sending services with their own bounce domain and forwarders are regularly SPF-unaligned and still pass through DKIM.
The light measures what receivers saw, not how your domain is configured. A correctly configured domain under a spoofing campaign shows red sources on purpose – the source table says whether those IPs are yours.
Section numbers refer to RFC 9990 unless another document is named. The DMARC reference walks through a complete report line by line.
report_metadata – who sent the report (§3.1.1.3)org_name, email, extra_contact_inforeport_iddate_range → begin, enderrorrua or several records at one name (§3.1.5).generatorpolicy_published – the record the receiver applied (§3.1.1.5)domaindiscovery_methodtreewalk = found by the RFC 9989 DNS tree walk, psl = found the RFC 7489 way via the Public Suffix List. New in RFC 9990.p, sp, npsp follows p, np follows sp.adkim, aspfr relaxed (organizational domain suffices) or s strict (exact match). Default r.psd= tags cut the walk. Relaxed alignment compares organizational domains. The optional DNS check determines it the same way the site’s scan does; receivers still on RFC 7489 use the Public Suffix List and may differ.fo0.testingt tag: y asks receivers to apply the policy one level lower than published (RFC 9989 §4.7). New in RFC 9990.pctrecord → row – one IP, one result combination (§3.1.1.8, §3.1.1.9)source_ip, countpolicy_evaluated → dispositionnone, quarantine, reject – or pass, new in RFC 9990, for a message that passed under an enforcing policy.policy_evaluated → dkim, spfauth_results. DMARC passes when at least one of the two is pass.reason → type, commentlocal_policy, mailing_list, trusted_forwarder, policy_test_mode (your t=y), other; RFC 7489 also had forwarded and sampled_out (from pct).identifiers – the domains the checks were made against (§3.1.1.10)header_fromenvelope_fromenvelope_toauth_results – the raw DKIM and SPF checks (§3.1.1.11 to §3.1.1.13)dkim → domain, selector, result, human_resultd= and s= of the signature, the result per RFC 8601 §2.7.1 (pass, fail, neutral, policy, temperror, permerror, none) and free text from the receiver. RFC 9990 makes the selector mandatory and asks for at most 100 signatures per row (§3.1.3).spf → domain, scope, result, human_resultmfrom; RFC 7489 also allowed helo), the result per RFC 8601 §2.7.2 (adds softfail) and free text.extension and namespaced elements (§3.2)Extensions may add namespaced elements at the top level or at the end of a record. The viewer counts them and ignores their content; elements without a namespace that the schema does not define are listed under format notes.
Receivers send them to the addresses in the rua= tag of your DMARC record, as a mail attachment named receiver!your-domain!begin!end.xml.gz (RFC 9990 §3.5.2). The XML should be gzip-compressed; some large receivers send a ZIP instead, and this page reads both. No rua, no reports: the DMARC generator adds the tag, the domain security check tells you whether yours is set and whether an external report address is authorised.
Forensic (failure) reports – the ruf= tag, RFC 9991 – are a different format and are not read here.