DMARC aggregate report (RUA)
Periodic XML summaries from participating receivers, each listing the IPs it saw sending as your domain and how SPF, DKIM, and alignment went.
See it
What it is
Add rua=mailto:you@yoursite.com to your DMARC TXT record and the mailbox providers that choose to report start mailing you gzipped XML summaries, typically once a day. Each report is one receiver's view of one time window: the source IPs that receiver saw using your domain in the From line, message counts, what SPF and DKIM returned, whether either aligned, and what it did about them. Not every provider reports, schedules slip, and no report or pile of reports adds up to every IP that ever sent as you. It is still the best view available of people spoofing you and of the forgotten systems mailing on your behalf.
The workflow is fixed: publish p=none with rua, watch for two to four weeks, and use the reports to find every legitimate sender nobody documented (the CRM, the invoicing tool, the helpdesk, a WordPress plugin from 2019). Fix their alignment one by one, then step the policy up to quarantine and finally reject. Skipping the reporting phase and jumping to p=reject is how companies silently kill their own invoices.
Gotchas: it is aggregate data, so no subject lines, recipients, or content (that was RUF, the failure report, which almost nobody sends any more for privacy reasons). Raw XML is unreadable past a handful of reports, so pipe it into a parser or a hosted dashboard. And expect alarming SPF failures from forwarders and mailing lists, which break SPF by design: judge yourself on DKIM alignment, not on raw pass rates.
Ask AI for it
Compare at least 14 days of DMARC aggregate (rua) data against the inventory of authorized senders I am pasting alongside it. Build a table of source IP, reverse DNS, message volume, SPF result and aligned domain, DKIM result and d= domain, and the disposition each receiver applied. Classify every row as a match to a known sender, an alignment failure on a known sender (with the SPF or DKIM change that would fix it), or an unknown source. Where ownership is not proven by the inventory, label it unverified rather than guessing the vendor from reverse DNS. Note which receivers are reporting and roughly what share of my volume they cover, and treat forwarding-shaped SPF-only failures as expected. Recommend a policy move only if coverage is broad enough and every legitimate source is either aligned or scheduled for remediation; otherwise say what is still missing.