How to Read a DMARC Report and Investigate Unexpected Senders
Read DMARC aggregate reports, investigate unfamiliar senders and distinguish alignment problems from legitimate mail that needs configuration.
TL;DR
- DMARC aggregate reports describe authentication observations for mail using your domain; they are not an inbox-placement report.
- Group records by source and identify which systems are authorised to send for you.
- An authentication pass and a DMARC-aligned pass are different checks, so inspect the domains involved.
- Investigate legitimate senders before tightening policy, and keep monitoring after changes.
Read reports as evidence about your sending systems
A DMARC report can look intimidating because it arrives as structured data rather than a normal dashboard. Its practical purpose is to help you understand who is sending mail using your domain and how receivers evaluated that mail.
The current aggregate-reporting specification is RFC 9990, alongside the core DMARC rules in RFC 9989. These May 2026 standards replace the earlier RFC 7489 framework. Reports can include source IPs, message counts, the visible From domain, authentication results and the disposition applied. They do not establish whether an individual recipient read the message or where every message appeared in the mailbox.
Treat each report as an observation from one reporting organisation over a stated period. Missing reports do not automatically mean that no mail was sent, and a single report is not a complete inventory of every receiver.
Build a sender inventory first
Before interpreting unfamiliar IP addresses, list the systems that legitimately send mail for your organisation. Include account notifications, customer support, marketing, invoicing and internal business tools. Record the owner of each system and the From domain it uses.
This inventory makes investigation faster. An unfamiliar source might be an old vendor, a new tool configured by another team, forwarded mail or unauthorised use. The report alone does not tell you which explanation is correct.
Ask the system owner to compare the report period with their sending activity. Use provider documentation and message headers from a controlled test to confirm the path. Avoid authorising a source merely because its IP appears frequently.
Work through a small example
Consider this simplified, fictional report summary:
| Source label | Messages | Observed result | Investigation |
|---|---|---|---|
| Primary delivery provider | 800 | Aligned authentication passes | Confirm it matches the intended stream |
| Old support tool | 45 | Authentication present but not aligned | Check the tool's domain configuration |
| Unknown source | 12 | Alignment fails | Determine whether it is legitimate before changing DNS |
The most important next step is not to maximise a green percentage. It is to explain each legitimate stream and correct any mismatch. A low-volume password-reset service may matter more operationally than a high-volume newsletter.
Keep the raw report and your interpretation separate. If you later discover that a source was misidentified, you can update the explanation without losing the original evidence.
Understand alignment before changing policy
DMARC relates authentication to the domain visible in the From header. A message may pass an authentication check for some other domain while still failing the relevant alignment requirement. That is why “SPF passed” on its own may not answer the question you are investigating.
Check which domain was authenticated and how the sending provider expects you to configure your domain. Do not add unrelated services to DNS records as a trial-and-error fix. Changes should correspond to a known, authorised sending path.
If a tool cannot support your intended domain configuration, discuss an appropriate sending arrangement with its owner. Document that decision so the next person does not undo it while trying to clean up a report.
Use a controlled rollout
Our suggested operational sequence is inventory, observe, repair, validate and then adjust policy. The appropriate timing depends on your actual sending patterns. A monthly billing stream needs to be included in the observation period; a quiet week may miss it completely.
Before a stricter policy change, confirm that critical legitimate streams pass the intended checks. Save the prior configuration and define what evidence would trigger an investigation. After the change, continue reviewing reports and customer delivery issues.
Do not confuse a monitoring policy with a guarantee that receivers will accept every message. Receivers apply their own checks, and DMARC is one part of the broader delivery system.
Make the report actionable for the team
For each unresolved source, assign an owner, a next step and a review date. A useful ticket says which domain and stream are affected, includes a redacted example and identifies the configuration question. “DMARC score is bad” is much harder to act on.
Our email bounce guide explains how to connect delivery failures to specific events. Use the MailBlastr blog for related operational guidance, and keep the reporting workflow tied to your real sender inventory rather than treating it as a one-time DNS task.