How to Read a DMARC Report and Know What to Fix

A DMARC report is an aggregate account of mail that claimed to come from your domain. To read one, confirm the reporting organization and date range, check the policy that was published, then work through each source IP by message count. Classify the source as known or unknown. For known sources, fix SPF or DKIM alignment failures. For unknown sources, determine whether the record shows harmless failed spoofing or a sender that can authenticate as your domain.

The XML looks harder than the decision. Read it in that order and most rows fall into a small set of actions.

What a DMARC Aggregate Report Contains

RFC 7489 defines aggregate reports as receiver-generated feedback about messages that passed and failed DMARC. A domain requests them through the rua tag in its DMARC DNS record. The standard requires receivers to support mailto: destinations and describes daily reporting, although implementations can vary.

Reports usually arrive as compressed XML attachments. They group messages with the same relevant results instead of listing every email. This matters because the count field carries the traffic weight. Counting XML rows will give you the wrong picture.

Aggregate reports are authentication evidence, not inbox-placement reports. They tell you which source connected, which domains SPF and DKIM evaluated, whether DMARC alignment passed, and what disposition the receiver applied. They do not prove that accepted mail reached the primary inbox or that recipients wanted it.

This article begins after collection is working. It does not repeat how to publish SPF, DKIM, or the DMARC record itself. If you are still building the records, use our deliverability resources first, then return with a real XML file.

Read the XML From the Outside In

A report has three useful layers: metadata about the report, the policy the receiver found, and one or more message records. Preserve that order. It prevents you from treating a result from the wrong date, domain, or policy as a current incident.

1. Confirm report_metadata

The report_metadata block identifies the organization that generated the report, a contact address, the report ID, and the covered date range. The RFC defines begin and end as Unix timestamps for a UTC time range.

Check these fields before comparing files:

• org_name: the receiving organization that produced the data
• report_id: the identifier used to detect duplicate reports
• date_range: the UTC period covered by the report
• error: an optional field for report-generation problems

Do not add duplicate reports to your totals. Match the report_id, reporting organization, and date range before combining data. Also avoid comparing a partial day with a complete day without labeling the difference.

2. Check policy_published

This block records the DMARC policy the receiver found for the reported domain. It can include:

Compare this block with the policy you expected during that UTC period. DNS changes can propagate during a report window, so one report may contain results influenced by an older policy even though policy_published shows one value. The RFC explicitly warns report consumers to allow for mixed results while policy changes propagate.

3. Read each record

Every record contains row, identifiers, and auth_results.

The row gives you the connecting source_ip, the number of matching messages in count, and policy_evaluated. That policy result includes disposition, plus DMARC-aligned SPF and DKIM results. It may also include a reason when the receiver overrode the requested policy.

The identifiers block includes the visible header_from domain and the envelope sender domain. The auth_results block shows the underlying DKIM domain, selector, and result, plus the SPF domain, scope, and result.

Authentication Pass Is Not the Same as DMARC Pass

This distinction causes the most confusion. SPF and DKIM can pass their own checks without satisfying DMARC. DMARC requires at least one passing mechanism whose authenticated domain aligns with the visible From domain.

For SPF, compare the authenticated envelope sender domain with header_from. Under relaxed alignment, the domains can share the same organizational domain. Under strict alignment, they must match exactly.

For DKIM, compare the signature's d= domain in auth_results with header_from. A valid signature from a sending platform's own domain can produce dkim=pass in the raw authentication result but still produce dkim=fail under policy_evaluated because it does not align with your From domain.

That is why you should read the two blocks together:

In this example, both mechanisms authenticate vendor.example, but neither aligns with yourcompany.example. The vendor's custom-domain authentication is the likely repair path. Do not loosen the DMARC policy just to hide the mismatch.

Turn Every DMARC Report Row Into an Action

Classify by source identity first, then by DMARC result. Our working matrix is deliberately small.

Known source with a DMARC failure

Find the expected service in your source inventory. If raw DKIM fails, check whether the platform signed the message, whether the selector exists, and whether the signature domain is yours. If raw DKIM passes but policy-evaluated DKIM fails, the signing domain does not align.

For SPF, check the envelope sender shown in the report. A platform can pass SPF through its own Return-Path and still fail DMARC alignment. Configure a custom Return-Path if the provider supports it, but remember that one aligned DKIM pass is enough for DMARC even when forwarding later breaks SPF.

Unknown source with a DMARC failure

Do not treat every unknown IP as an attack. It may belong to a legitimate vendor, a forwarded copy, or an old system nobody documented. Look up the provider that owns the source network, compare the date with internal changes, and ask the system owner for proof of the sending path.

If no owner exists and the traffic fails alignment, your quarantine or reject policy may be handling spoofing as intended. Record the volume using count and watch whether the pattern persists. Do not add an unknown source to SPF simply to make a red row turn green.

Unknown source with a DMARC pass

This deserves the fastest response because the source has an aligned authentication path. It may be a forgotten authorized platform, a shared service using an old key, or access that should have been removed.

Trace the DKIM selector and aligned domain first. Review who controls the platform account and DNS records. Rotate or revoke credentials and keys only after confirming which legitimate streams depend on them, because an unplanned rotation can break valid company mail.

Read Disposition and Overrides Carefully

disposition records what the receiver applied to the grouped messages: none, quarantine, or reject. It does not always match your requested policy. The report may include an override reason such as forwarding, a mailing list, trusted-forwarder treatment, sampling, local policy, or another reason defined by the receiver.

Forwarding deserves special attention. A forwarder changes the connecting IP, which commonly breaks SPF. DKIM may survive if the forwarded message remains unchanged, giving DMARC an aligned DKIM pass. An override reason is context, not permission to ignore the row.

Build a Repeatable Review Process

Review by source and message count, not by attachment. First deduplicate report IDs. Then combine the counts for identical source, header From domain, authentication outcome, and disposition during the same period. Rank known failures and unknown passing sources ahead of low-volume failed spoofing.

Assign each finding to a system owner and require a verification step. A repaired source should produce fresh mail with an aligned pass in message headers, followed by clean aggregate results from receivers after the reporting interval. Keep the old row, the change made, and the confirmation together.

A company can publish correct records and still lose control when a new CRM, scheduler, or sending domain appears without an owner. We connect authentication records, sender inventory, campaign operations, and monitoring in one outbound system, while the client keeps ownership of every domain and mailbox.

Ready to Turn Authentication Data Into Action?

We can map your ICP, campaign fit, sending sources, and ownership gaps before another undocumented route creates a deliverability problem. Book your free ICP and campaign-fit discovery call →