A DMARC aggregate report is a daily XML file, usually zipped and emailed to the address in your record’s rua tag. It is not a list of spam you received. It is a list of messages other servers accepted that claimed to be from your domain, and whether those messages passed SPF or DKIM in a way DMARC counts. If you published p=none and never opened a report, you do not yet know who sends as you.
Drafting the record is how to draft SPF and DMARC records. The DNS shape of the mistakes is SPF, DKIM, and DMARC mistakes. This article assumes the record exists and a report has arrived. Moving from monitor to quarantine is the decision at the end, not the first click.
Open one small report, not the whole mailbox
Pick a single day’s file from one receiver. You do not need a paid dashboard to learn the format. Unzip it and look for a handful of repeated blocks. Each block is one source: an IP address, a count of messages, the SPF domain, the DKIM domain if any, and a disposition. Disposition is what the receiver did under your policy. While you are on p=none, disposition is usually none, which means “I counted it and I did not reject it.”
Here is a fictitious block, shortened so the fields are visible. The IP 203.0.113.20 sent 40 messages with a From domain of example.com. SPF passed and aligned. DKIM passed and aligned. The policy result is pass. A second block, IP 198.51.100.8, sent 6 messages. SPF failed. DKIM was absent. The result is fail. Those six messages are the ones to identify before you change policy. The numbers are an illustration, not a threshold.
Aligned is the word that matters
SPF can pass for a mailing vendor’s own domain and still fail DMARC, because DMARC cares whether the authenticated domain matches the From domain customers see. The same is true of DKIM. A report line that says SPF pass and DMARC fail is common when a vendor is authorized to send but is not aligned to you. Fix alignment by configuring that vendor’s custom domain and its DKIM key, then watch the next report. Do not “fix” it by adding the vendor’s IP to a place DMARC does not use.
Forwarding breaks SPF on purpose and can break a DKIM signature if the forwarder rewrites the message. A fail from a forwarding host is not automatically an attacker. Daily SPF, DKIM, DMARC, and blacklist monitoring is how you notice a sudden new failure. The aggregate report is how you see whether that failure is a forwarder, a new app, or a stranger.
Group senders before you judge volume
Make three piles. Known and aligned: your own mail host, and vendors you configured. Known and not aligned: a tool you use that has not been set up with your domain yet. Unknown: an IP you do not recognize. The unknown pile is the one that might be spoofing, a forgotten server, or a vendor someone added without telling you. Look up the IP’s operator only to get a clue. The clue is not proof. Ask the team whether a new product started sending that week.
A large count on a known aligned sender is normal. A small count on an unknown sender can still be the important line. Readiness for enforcement is not “95 percent passed.” A single legitimate billing system that fails will lose invoice mail the day you quarantine. Identify every legitimate path first. The percentage is a side effect of that list, not the goal.
What the report does not contain
Aggregate reports do not include the message body, the subject, or the recipient. They will not show you the phishing text. Forensic reports, the ruf address, are a different subscription and many receivers never send them. Do not wait for a forensic copy before you act on a clear unknown sender in the aggregate file.
The report is also late. It describes yesterday, or the last day, from each receiver that bothered to send one. A new campaign that started this morning is not in the file yet. Give a new sender two or three report cycles after you fix DKIM before you decide the fix failed. The email security checker can confirm the live SPF and DMARC policy. It does not open the XML.
When quarantine is honest
Move from p=none toward quarantine when every system that should send as your domain shows aligned passes, and the remaining failures are sources you are willing to have junked. Start with a percentage tag if you want a slow ramp, and read the next reports to see who landed in the junked slice. Raise the percentage only when those reports stay boring. Jumping to p=reject because a blog said reject is how invoices disappear.
If you change mail providers, expect a week of new IPs and a new DKIM selector. Why forwarded email breaks SPF and DMARC explains rows that look like spoofing and are not. That does not replace this report, and it does not tell you who is allowed to send. Publish them after you can name your senders, not before.
Keep a sender list next to the mailbox
The report is useless if the only person who can explain an IP left the company. Write a short list: product name, sending domain, whether DKIM is on, and who owns the vendor account. When a new block appears, the list is how you tell a support desk you added from a sender you did not. Update the list the same day a tool starts sending, not after the first failure.
Receivers do not all report. A quiet week from one mailbox provider does not mean that provider saw no mail. Compare two receivers before you declare a source gone. If one receiver still fails a source that another passes, the difference is often alignment on a subset of messages, not a broken file. Open that source's block and read the pass and fail counts inside it instead of trusting the subject line of the email that delivered the zip.
If the rua mailbox is a shared inbox, give it an owner and a weekly reminder. Reports that nobody opens are the same as a record with no rua tag. The policy can say monitor forever while spoofed mail keeps landing, because the file that would have shown it was deleted unread. Put the sender list in the same folder as the latest zip so the next review starts from names, not from a raw XML dump.
Frequently asked questions
I have no reports. Is DMARC on?
Maybe the record is published and no receiver has sent a file yet, or the rua address is wrong, or the mailbox is discarding XML attachments. Check the live record, then check the mailbox’s spam folder for the report sender.
Is a 100 percent pass required?
No. You need to recognize the legitimate senders and accept what will happen to the rest. A perfect percentage with an unnamed billing host still failing is not ready.
Can Vulnify read the XML for me?
No. The email and DNS tools read the published records. You, or a mailbox you trust, read the aggregate file. The tools tell you whether the policy you think you published is the one on the internet.