How to Read a DMARC Report and Build a Sender Investigation List

TL;DR

• Treat a DMARC aggregate report as evidence about observed sending and use it to create an investigation list rather than making immediate DNS changes based on one report.
• Build a sender ownership worksheet: one investigation row per source grouping with interval, source IP, counts, visible and authentication domains, disposition, suspected owner and operational next actions.
• Do not change policy from a single observation; treat each report as one receiver's evidence and close investigations only when the team can explain the source and the action taken or assign an owner.

Read the report as evidence about observed sending

A DMARC aggregate report helps investigate mail claiming to use your domain. It is not an inbox-placement report, a list of everyone who read a message or proof that every source IP belongs to an attacker. Start by identifying the reporting organization, reported domain and time interval.

Keep those fields with the original report. Comparing records without their intervals can make a recurring sender look like a sudden spike or cause the same reporting period to be counted twice. The first useful output is an organized investigation list, not an immediate DNS change.

Separate authentication results from alignment

A source can have an authentication result without satisfying the domain relationship that DMARC evaluates. Inspect both the authentication details and the evaluated policy results instead of treating every visible “pass” as equivalent.

RFC 7489 describes the aggregate-report structure, including source addresses, counts, identifiers and authentication results. Its alignment model relates authenticated identifiers to the visible From domain. A DMARC pass requires an aligned authentication path; an unrelated authenticated domain does not establish that relationship by itself.

If those concepts are unfamiliar, review the SPF, DKIM and DMARC explanation before deciding how a report row should be classified.

Build a sender ownership worksheet

Create one investigation row for each source grouping that needs attention. Include the report interval, source IP, message count, visible domain, relevant authentication domains, observed disposition and suspected owner.

Add three operational fields: evidence for the owner, next action and responsible person. A reverse lookup or recognizable network name can suggest a provider, but it is not sufficient proof that your organization authorized that particular sending activity.

Match the observation against your actual inventory: application delivery, support tools, billing systems, employee mail and any other approved senders. Ask the owning team to confirm configuration and recent activity rather than broadening authorization based on a guess.

Work through three illustrative rows

Imagine a report contains a high-volume source that matches your application's known provider and shows aligned authentication. Record it as a recognized path, while preserving the evidence used to identify it. This is a baseline for later investigation, not a guarantee about message placement.

A second source appears to belong to a recently introduced billing system but fails alignment. Assign it to the billing integration owner for verification. The fix might involve the provider's documented domain setup, but the report alone does not tell you which configuration change is correct.

A third source has no known business owner. Keep it unknown while investigating. Do not add it to SPF merely to reduce the failure count; that could authorize sending you never intended to permit.

Prioritize uncertainty with business context

Investigate known critical workflows promptly, especially when their configuration changed recently. Also examine unexpected sources and abrupt pattern changes. Message count is useful context, but it should not be the only prioritization rule.

A low-volume password-reset path may matter more operationally than a large stream of obvious unauthorized traffic. Conversely, a previously unseen source can deserve attention even when it does not correspond to a customer complaint.

Document the reason for the priority. This helps the next person distinguish an urgent customer-facing issue from a lower-risk inventory cleanup without inferring severity from one number.

Avoid changing policy from one isolated observation

A report is one receiver's observation over a particular interval. It cannot reveal every legitimate sender or prove that an entire rollout is ready for stronger enforcement. Review coverage across your actual sending workflows and the available reporting periods.

For subdomain behavior, use the separate DMARC subdomain policy guide and verify the relevant DNS records. Keep report interpretation separate from the approval to change authentication or policy settings.

When a configuration change is made, record the exact sender and the expected evidence of improvement. Otherwise later reports may look different without anyone knowing which intervention was intended to produce that difference.

Handle report data as operational information

Store reports where authorized operators can investigate them, with retention appropriate to your organization's needs. Avoid posting raw files into public issues or exposing unrelated domain and infrastructure details in screenshots.

A summarized case can usually communicate the problem: recognized sender, observed alignment failure, affected interval and a sanitized example. Keep the original available to the people who need the detailed evidence.

Close investigations with a verified explanation

An investigation is complete when the team can explain the source and the action taken, or explicitly retain it as unresolved with an owner. Recheck subsequent evidence after a legitimate sender configuration is corrected.

The resulting worksheet should make the next report easier to interpret. Over time, it becomes a maintained inventory of authorized sending paths and known exceptions. That operational knowledge is more useful than chasing a perfect-looking percentage without understanding who is sending mail for the domain.