How to Read DMARC Reports and Fix Deliverability Issues

Do not index

You wrote a strong email campaign, the copy is clean, and the sender dashboard still shows campaigns sliding into spam. That's the moment DMARC reports stop being “security paperwork” and start becoming the fastest way to see who's sending mail as your domain, who's failing authentication, and what's hurting inbox placement.

DMARC is the policy layer that sits on top of SPF and DKIM. It tells mailbox providers like Gmail, Outlook, and Yahoo what to do when mail doesn't align, and the reports show what those receivers saw, not what your ESP hoped would happen. A good read of those files often explains reputation damage long before the inbox starts to collapse, and the broader deliverability context pairs well with how email deliverability works and the mailX full email deliverabilty guide if the technical path from authentication to placement needs a fuller map.

Table of Contents

Why Your DMARC Reports Hold the Key to Inbox Placement Anatomy of an Aggregate Report Explained Field by Field Read the metadata first Decode each source row DMARC Aggregate Report Field Reference Your Weekly DMARC Review Workflow Sort sources before you judge them Use alignment to separate forwarding from spoofing A review checklist that actually helps Manual Reading Versus Automated Report Processing Where automation helps and where it stops When manual review is still the right move Common Mistakes That Sabotage Your DMARC Strategy What teams miss most often Turning Report Findings Into Deliverability Fixes Match the fix to the failure Move policy in stages Frequently Asked Questions About DMARC Reports

Why Your DMARC Reports Hold the Key to Inbox Placement

A lot of teams treat DMARC like a compliance checkbox until mail starts disappearing. Then the usual clues, open rates, inbox screenshots, and ESP summaries, don't say much about why legitimate messages are underperforming while a forgotten tool, a vendor, or a spoofing source is still sending as the same domain.

That's where DMARC aggregate reports earn their keep. They're 24-hour receiver-generated summaries built around authentication outcomes, not campaign narratives, and they show the sending sources that mailbox providers observed across SPF and DKIM checks. The IETF standardized the reporting model in 2015 with RFC 7489, and the core DMARC specification was updated in May 2026 by RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991 (DMARC reporting background).

A practical definition is enough to keep the mental model straight. DMARC is the policy that evaluates whether mail aligns with your visible From domain, SPF checks the sending path, and DKIM checks the signature. The report tells you which sources passed, which ones didn't align, and which receivers chose to quarantine or reject based on policy.

That framing matters because lost alignment costs more than a technical mismatch. It pushes legitimate campaigns closer to the spam folder, weakens sender reputation, and gives spoofers room to borrow trust from your domain. A clean read of the reports turns DMARC from passive monitoring into a deliverability control surface.

Anatomy of an Aggregate Report Explained Field by Field

An aggregate report is easiest to understand when it's treated as a structured XML inventory, not a blob of tags. The file usually arrives as a ZIP-compressed XML attachment, most often on a daily cadence, and the XML extension is either xml or xml.gz when compressed (DMARC aggregate report format).

Read the metadata first

The opening block tells you who sent the report and what time window it covers. In practice, that means looking for the reporting organization, a report ID, and the covered date range. NIST describes aggregate reports as receiver-generated files that summarize authentication outcomes by source IP and domain, so the metadata exists to establish whose view you're reading before any troubleshooting starts (NIST TN 1945).

The next block is the published policy. That's where the receiver records the DMARC settings it evaluated at the time, including the domain, the policy, the subdomain policy, and the alignment modes. A key detail is that the receiver is reflecting the record it saw during evaluation, so policy drift or late DNS changes can make one day's report look different from the next.

Decode each source row

Each per-source record shows one sending source and the number of messages tied to it. That count matters because a large sender can dominate the daily picture, which is why aggregate data should be read as a volume-weighted view, not as a message-by-message log. The row also includes the DMARC disposition and the raw SPF and DKIM authentication results.

Here's the part you need to understand. A raw SPF pass doesn't automatically mean DMARC pass. If the authenticated domain doesn't align with the visible From domain, the message can still fail DMARC. The same logic applies to DKIM, which is why the aligned verdict in the policy-evaluated section matters more than the standalone authentication result (DMARC alignment behavior).

DMARC Aggregate Report Field Reference

XML Tag	What It Means	What to Check
`report_metadata`	Who sent the report, when it covers	Reporting organization, report ID, date range
`policy_published`	The DMARC policy in effect	Domain, `p`, `sp`, `adkim`, `aspf`
`record`	One source and its message volume	Whether the source should exist
`source_ip`	The sender observed by the receiver	Map it to a vendor, app, or internal system
`count`	Messages tied to that source	High-volume sources deserve first review
`policy_evaluated`	Aligned DMARC result	`pass` or `fail` after alignment
`auth_results`	Raw SPF and DKIM checks	Whether the underlying auth passes but misaligns
`header_from`	The visible From domain	Compare it to the authenticated domains

Use the counts to prioritize. One unknown source sending a trickle of mail can be a forgotten system, while one misconfigured high-volume platform can drown out everything else and drag legitimate mail into reputation trouble.

Your Weekly DMARC Review Workflow

A weekly review only works if it's mechanical. The process should start with pulling reports from the major receivers, then decompressing each file and grouping records by source IP and published policy so the same sender doesn't get reviewed as three different problems.

Sort sources before you judge them

After grouping, sort every source into three buckets. Known legitimate senders are the systems that should be there and need to pass cleanly. Unknown but possibly legitimate sources are the shadow IT systems, product trials, or vendor mail streams that nobody documented. Suspicious sources are the ones with no business reason to exist, especially when they appear with meaningful volume.

That triage matters because DMARC reporting is really an inventory problem. If the team can't identify the sender, the fix isn't policy first, it's source discovery.

Use alignment to separate forwarding from spoofing

Forwarding artifacts often break SPF while DKIM still holds, because the message leaves one path and arrives through another. That's a different failure mode from spoofing, where both alignment and authorization usually look broken. If the row shows SPF failing but DKIM passing and the source is a mail-forwarding path, the remediation is usually structural, not punitive.

A review checklist that actually helps

Collect every receiver file: Pull the daily aggregate reports from all major mailbox providers and anything else generating reports.

Decompress and group: Unzip the XML files, then group rows by source IP and policy.

Review counts first: Start with the highest-volume sources, because they're the most likely to affect reputation.

Classify every source: Tag each one as legitimate, unknown, or suspicious.

Inspect alignment: Compare raw SPF and DKIM results against the aligned verdict, not just the auth result.

Log fixes immediately: Record who owns the sender, what changed, and what should be visible in next week's reports.

The best workflow turns report reading into a habit, not a fire drill. That's how teams catch vendor drift, unauthorized tools, and reputation problems before inbox placement falls off a cliff.

Manual Reading Versus Automated Report Processing

Manual XML review is honest, but it's slow. Automated processing is faster, and that speed matters when reports arrive every day from multiple receivers and the same sender appears under different source IPs, policies, and outcomes.

The trade-off is context. Automation can parse structure, cluster sources, and surface trends, but it often can't tell whether a failing source is a newly onboarded vendor, a shadow IT system someone forgot to mention, or a spoofing attempt that deserves immediate containment. The difference is operational, not cosmetic, because each case leads to a different fix and a different deliverability risk.

Where automation helps and where it stops

Automation helps when the task is repetitive. It reduces the time spent opening files, scanning tags, and sorting obvious pass/fail records. It also makes it easier to spot volume shifts and recurring failures without reading every line of XML.

Human review becomes essential when the domain is moving from monitoring to enforcement, when a new sender is being onboarded, or when inbox placement drops and the usual dashboards don't explain why. That's also the moment to make sure the DMARC record is being published and interpreted correctly, which is a good place to validate your DMARC record before assuming the reports are the only problem.

MailAdept uses a subscription model that combines AI agents with human experts, so the work doesn't stop at parsing. That matters because a report is only useful when the team can connect the source, the alignment result, and the business owner behind the sending stream.

When manual review is still the right move

Manual reading is still the safer option when policy changes are under review. It's also the right call when one sender is critical to revenue, because a misread here can push a valid stream into the spam folder or break a transactional flow that customers rely on.

For teams scaling faster than their email governance, the question isn't whether automation is useful. It's whether automation alone can identify the sender, explain the failure, and recommend the correct next action. Most of the time, it can't do all three.

Common Mistakes That Sabotage Your DMARC Strategy

The biggest DMARC mistake is reading a raw auth result as if it were the whole verdict. A message can pass SPF and still fail DMARC if the authenticated domain does not align with the visible From domain, and that misunderstanding leads teams to approve broken mail or miss misaligned vendor traffic.

The second mistake is rushing to enforcement before the inventory is clean. A move to p=reject with unknown senders still active can break legitimate mail from forgotten platforms, forwarding paths, or business units that never told IT what they were using. That does not just create technical noise. It can block real sends, hurt revenue, and make the email program harder to trust.

What teams miss most often

Confusing auth with alignment: A passing SPF check is not enough if the domain does not line up with the From address.

Ignoring DKIM: DKIM often survives forwarding better than SPF, so dropping it removes one of the clearest clues in the report.

Overreacting to one failure: One failing row can be noise, but repeated failures from the same source are a pattern worth triage.

Treating aggregate files like message logs: Aggregate reports do not show body text or subject lines, so they cannot explain content quality or engagement.

A source with low volume still deserves attention if it is unknown. Spoofing does not need volume to do damage, especially when a receiver sees repeated attempts from an unapproved sender and starts degrading trust in the domain.

Cold Email Mistakes often come from the same root cause, poor sender discipline. If outbound teams launch new tools without telling the people who own authentication, DMARC reports become the first place the mismatch shows up.

Marketing and sales teams get expensive surprises here. They assume quiet sources are harmless, then discover that a small stream of misaligned mail has been weakening sender reputation for weeks.

Turning Report Findings Into Deliverability Fixes

Once the report tells the truth, the fix usually falls into one of three paths. The first is a legitimate sender with broken SPF alignment, which means the SPF record needs to include the correct mail path or the sender needs to be removed if it doesn't belong.

The second is a DKIM issue, which usually means the signing domain doesn't match the visible From domain or the sender isn't signing consistently. The aligned result is what matters here, not just whether a signature exists, because a signature that doesn't align can still leave DMARC failing.

Match the fix to the failure

If SPF is failing for a sender that should exist, the business owner of that platform needs to confirm the sending architecture before DNS changes happen. If DKIM is failing, the sender needs to use the correct signing domain and keep that behavior stable across all sending paths. If both fail, the source deserves a hard look before it's allowed back into production.

For teams that want a deeper review of the mechanics behind these outcomes, the guide on SPF, DKIM and DMARC explained is a useful companion to the report itself.

Move policy in stages

The reporting data should drive the move from p=none to p=quarantine and then to p=reject, but only after the legitimate sources are understood and the unknowns are resolved. The point isn't to flip policy for its own sake, it's to make sure mail that should pass is passing, and mail that shouldn't exist stops appearing in the logs.

Every change should be validated with test sends and header inspection before production rollout. If the fix doesn't show up in the next report cycle, it isn't fixed yet, and the reputation cost keeps accumulating.

Frequently Asked Questions About DMARC Reports

Why are forensic reports mostly dead in practice? Major receivers generally rely on aggregate reporting because it exposes less message-level detail and fits privacy expectations better. For day-to-day operations, aggregate reports are the primary source of visibility.

How often should reports be reviewed? Daily data arrives on a 24-hour cadence from major receivers, so a weekly review is the minimum useful rhythm for operations. Daily checks are better during onboarding or policy changes.

What if a source appears that nobody recognizes? Classify it before you act. It could be shadow IT, a forgotten vendor, forwarding, or spoofing, and the report alone won't tell you which one without source ownership review.

When should outside help be brought in? Escalate when multiple senders are failing, policy changes are risky, or the same source keeps reappearing with unclear ownership. That's usually a sign the issue is about system design, not a single broken tag.

Can DMARC reports show why a campaign failed? Not by themselves. Aggregate reports show authentication, alignment, source IPs, counts, and disposition, but not message content or user experience.

Still facing deliverability issues? Get a free deliverability audit.

MailAdept helps teams turn DMARC reports into a clear sending inventory, then into fixes that protect inbox placement. If report review keeps exposing unknown senders, alignment failures, or policy risk, visit Mailadept to see how a deliverability team can clean up the system before reputation slides further.