Reading DMARC aggregate reports: what they tell you and which ones to ignore
DMARC reports look like XML dumps. They are actually one of the highest-signal deliverability data sources you have access to. Here is what to read first.
Rejwan Nirob·May 23, 2026·6 min readDMARC aggregate reports are XML files that mailbox providers send to a designated address whenever they evaluate mail for your domain. They land in your inbox daily. Most cold-email operators ignore them because the format is awful. That is a mistake - the reports surface SPF and DKIM alignment failures that are otherwise invisible.
What is in a DMARC report
A 24-hour summary of every IP that sent mail claiming to be from your domain, with per-message counts of how SPF and DKIM evaluated. The fields you care about: source IP, message count, SPF result (pass/fail), DKIM result (pass/fail), and the disposition the receiver applied (none, quarantine, reject).
The format is XML, which is the main reason these reports get ignored. Free parsers exist (DMARCian has a free tier, MXToolbox has one, Postmark has one). At agency scale a hosted parser is worth the small cost.
What to look for first
- Source IPs you do not recognize - someone may be spoofing your domain
- High failure count from your own legitimate sender - something is misconfigured
- Sustained DKIM failures - usually a rotation issue or a forwarding chain
- Mailbox providers applying quarantine disposition - your policy is being enforced
The forwarding chain problem
DKIM signatures break when mail is forwarded through certain intermediaries. A recipient on a mailing list, or with a forwarding rule on their personal address, will produce DKIM-fail reports in your aggregate data. These are not your problem - they are forwarding-infrastructure problems - but they will show up in reports.
The way to distinguish: forwarding-chain failures usually originate from named intermediary IPs (Mailman, Sympa, common forwarders). Failures from sending IPs you actually use are the ones to investigate.
Cadence
Reports arrive daily from major providers, less frequently from smaller receivers. The signal is most useful when reviewed weekly - daily can be noisy. Set a Friday review cadence: scan for new source IPs, investigate sustained failures, archive the rest.
“DMARC aggregate reports are the single most underused deliverability signal in cold email. Half the providers do not even subscribe to them. The other half subscribe and never read them.”
What Inboxlee does with reports
Every domain Inboxlee provisions ships with DMARC reports routed to dmarc@inboxlee.com - our shared intake address. We parse them, surface per-customer failures in the dashboard, and flag suspicious source IPs. You do not have to learn XML. You do not even need to know reports exist - the signal arrives in the dashboard as a per-mailbox health flag.
DMARC reports already arrive at the Inboxlee shared inbox for every domain we provision. Per-mailbox alignment failures and suspicious source IPs are surfaced in the infrastructure dashboard - no XML reading required.
See infrastructure monitoringFrequently asked
What are DMARC aggregate reports?
XML files that mailbox providers send to a designated address whenever they evaluate mail for your domain. They contain a 24-hour summary of every IP that sent mail claiming to be from your domain, with per-message counts of how SPF and DKIM evaluated. Sent daily by major providers, less frequently by smaller receivers.
Do I have to read DMARC reports manually?
No. Free parsers from DMARCian, MXToolbox, and Postmark convert the XML into a readable dashboard. At agency scale, a hosted parser is worth the small cost. Inboxlee routes reports to a shared intake address, parses them automatically, and surfaces per-customer failures in the infrastructure dashboard - no XML reading required.
What is the most important thing to look for in DMARC reports?
Four signals in priority order: (1) source IPs you do not recognize - someone may be spoofing your domain, (2) high failure count from your own legitimate sender - something is misconfigured, (3) sustained DKIM failures - usually a key rotation issue or a forwarding chain, (4) mailbox providers applying quarantine disposition - your policy is being enforced.
Why do DMARC reports show DKIM failures even though my mail is configured correctly?
Forwarding chains. DKIM signatures break when mail is forwarded through certain intermediaries (Mailman, Sympa, personal forwarding rules). These are not your problem - they are forwarding-infrastructure problems - but they show up in reports. The way to distinguish: forwarding-chain failures originate from named intermediary IPs; failures from your own sending IPs are the ones to investigate.
How often should I review DMARC reports?
Weekly is the right cadence. Daily review is noisy - the signal is most useful averaged over 5 to 7 days. Set a Friday review block: scan for new source IPs, investigate sustained failures, archive the rest. Inboxlee surfaces the signal in real-time on the dashboard so you can also catch urgent issues without waiting for the weekly review.