Reading DMARC Reports
Reading DMARC Reports
Overview
DMARC generates two types of reports that tell you who is sending email from your domain and whether they're authenticated. DMARC+ processes these reports and presents them in readable dashboards — but understanding what the underlying data means helps you act on it faster.
Aggregate reports (RUA)
Aggregate reports are XML files sent daily by every major mail provider (Google, Microsoft, Yahoo, etc.) to your rua= address. They summarise authentication results for all email claiming to be from your domain during the previous day.
Each report contains:
- The receiving organisation (who sent the report)
- The IP addresses that sent email from your domain
- How many emails each IP sent
- Whether SPF and DKIM passed or failed for each IP
- Whether DMARC passed (combining SPF/DKIM with alignment)
- What action was taken (none, quarantine, reject)
DMARC+ aggregates these across all providers and presents them in the Dashboard.
Forensic reports (RUF)
Forensic reports are per-message failure reports sent (when an email fails DMARC) to your ruf= address. They contain the email headers (and sometimes the full message) that failed.
Note: Many major providers (including Google) no longer send forensic reports due to privacy concerns. Don't rely on them as your primary analysis tool.
Reading the DMARC+ Dashboard
Pass rate
The most important metric. Your goal:
| Pass rate | Status |
|---|---|
| < 70% | Critical — significant unauthorised sending or misconfiguration |
| 70–90% | Needs work — fix failing sources before enforcing |
| 90–95% | Almost ready — investigate remaining failures |
| > 95% | Ready to advance policy |
Sending sources
The table of IP addresses sending from your domain. For each source:
- Pass — this source is properly authenticated
- Fail — this source is failing SPF or DKIM alignment
For every failing source, answer: do I want this source sending email from my domain?
- Yes, it's legitimate — configure SPF and DKIM for it
- No, it shouldn't be sending — note it; once you enforce, it will be blocked automatically
- Not sure — investigate the IP (use IP lookup tools to identify the owner)
Common patterns in DMARC reports
High volume from an unknown IP failing DMARC
Someone is spoofing your domain. They won't be blocked until you enforce p=reject — this is your motivation to get there.
Low volume from an unfamiliar service passing SPF
Probably a service you forgot about (an old newsletter tool, a developer's personal Mailchimp account, etc.). Decide whether to keep or remove it.
A legitimate service failing alignment
SPF or DKIM is set up, but the alignment isn't working. Common cause: the service is signing with its own domain, not yours. Fix: configure the service to use your domain for both the envelope From and DKIM signing.
Sudden spike in failures
Usually means something changed:
- A new sending service was added without SPF/DKIM setup
- A DNS change broke an existing record
- A third-party service changed their SPF record without notice (check your
include:chains)
Acting on report data
Prioritise by volume. Fix the highest-volume failing sources first — they have the most impact on your pass rate.
Fix one source at a time. After each fix, wait 24 hours for new reports and verify the source is now passing before moving to the next.
Keep a changelog. Note every DNS change you make and when. This makes it much easier to debug unexpected failures later.
Set a weekly review cadence. Spend 15 minutes each week reviewing the DMARC+ dashboard. New services get added, records change — regular review catches issues before they affect deliverability.