How to Read DMARC Reports and Fix Email Deliverability

Do not index

A team can spend days polishing a cold email sequence, only to discover that replies have collapsed because messages are landing in spam. The warning signs often appear together, domain reputation weakens, SPF or DKIM fails, a blacklist flags the sending infrastructure, or transactional messages stop reaching users during onboarding.

Then the DMARC reports arrive. They're compressed XML files filled with sending IPs, message counts, pass and fail results, and receiver actions. The data is useful, but a report doesn't tell a busy team which failure is urgent, which one comes from forwarding, and which one belongs to a forgotten CRM integration.

This guide shows how to read DMARC reports as a deliverability operator would. The focus is prioritization, not just XML syntax, so teams can identify material failures, fix legitimate senders, investigate spoofing, and move toward enforcement without breaking important mail flows.

Table of Contents

Why DMARC Reports Matter for Inbox Placement Understanding RUA and RUF Report Types RUA aggregate reports RUF failure reports How to Triage Sending Sources and Spot Failures Classify the source before judging the failure Remediation Actions for Common DMARC Failures SPF failures from legitimate senders DKIM alignment failures Forwarding and mailing-list paths Common Mistakes That Break Deliverability What operators should avoid Automating DMARC Report Analysis with Modern Tools Policy Rollout and Monitoring Best Practices

Why DMARC Reports Matter for Inbox Placement

A team publishes a DMARC record with rua reporting enabled and starts receiving daily summaries. One report lists a corporate mail platform, a customer relationship management system, a helpdesk, a marketing service, and unfamiliar IP addresses. Some rows pass SPF and DKIM. Others fail one or both checks.

The first mistake is treating every failure as an incident. The second is treating the report as background noise. A DMARC aggregate report is a map of every source that claimed to send mail from the domain during the reporting window, including sending IPs, message volume, and authentication outcomes. It doesn't provide a single health score, so the operator must classify sources before changing policy. DMARC was formally published as RFC 7489 in March 2015, creating the framework for authentication, alignment, and reporting used in modern analysis.

Unread reports create two opposite risks:

Unprotected spoofing: Unknown sources can continue impersonating the domain, damaging trust and giving mailbox providers more suspicious traffic to evaluate.

Broken legitimate mail: A team can tighten policy before identifying every CRM, helpdesk, sales tool, or transactional provider, causing authentic messages to be quarantined or rejected.

That matters for inbox placement because DMARC is evaluated alongside SPF and DKIM authentication, domain alignment, sender reputation, and receiving-server signals. A technically valid message can still face filtering, but unresolved alignment failures remove an important trust signal and make delivery problems harder to diagnose.

The broader email program is affected too. Newsletter operators can pair DMARC review with this playbook for newsletter deliverability to assess authentication alongside list quality, sending behavior, and engagement. Teams that need a plain-language definition before opening reports can review what a DMARC record does.

DMARC reporting has become operationally important as adoption expands. A 2026 scan found 937,931 domains with valid DMARC records, representing 52.1% of 1.8 million top domains analyzed, compared with 47.7% in 2025; the same report identified more than 553,000 domains configured for aggregate reporting (EasyDMARC's 2026 adoption report). Publishing a record is no longer the finish line. Teams need to understand what receivers are seeing and decide which failures deserve action.

Understanding RUA and RUF Report Types

DMARC reporting has two distinct channels. RUA sends aggregate reports, while RUF requests failure or forensic reports. The primary focus for monitoring should be RUA, as it provides broad visibility without requiring message-level investigation.

RUA aggregate reports

An aggregate report is a compressed XML document sent by a receiving organization. It summarizes the mail that receiver saw claiming to come from the domain during a reporting window. The report normally includes:

Reporting organization: The receiver that generated the report.

Time range: The period covered by the summary.

Published policy: The DMARC policy and alignment settings observed by the receiver.

Sending sources: Each source IP and its message count.

Authentication results: SPF, DKIM, and DMARC outcomes, including alignment.

Disposition: The receiver's reported action, such as no action, quarantine, or reject.

The ri tag requests the reporting interval in seconds. The standard and default value is 86400 seconds, equal to 24 hours, so aggregate reports are typically daily (DMARC interval guidance). A receiver can choose to ignore a shorter requested interval.

The XML should be read in three blocks:

report_metadata: Identifies the reporting organization, report identifier, and date range. This confirms whose view is represented and when the mail activity occurred.

policy_published: Shows the domain, p policy, subdomain policy, and SPF and DKIM alignment modes as evaluated by the receiver.

record: Represents a source grouping. Inspect source_ip, count, policy_evaluated.disposition, aligned SPF and DKIM results, identifiers.header_from, and auth_results.

A simplified record might look like this:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>45</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

This row says that the receiver grouped 45 messages from one source, SPF aligned and passed, DKIM did not pass alignment, and the receiver reported no enforcement action. The result isn't automatically a spoofing event. It may represent a legitimate service that hasn't configured custom DKIM.

RUF failure reports

RUF reports are intended to describe individual authentication failures, sometimes with message headers or other potentially sensitive material. Receivers may limit or omit them because of privacy concerns, so availability is inconsistent. For most organizations, aggregate reporting offers the more dependable foundation for source discovery, trend analysis, and policy decisions.

How to Triage Sending Sources and Spot Failures

The useful workflow begins after the report has been decompressed and parsed. Raw XML can be opened for a quick inspection, but the operator should first sort records by message volume, then examine SPF and DKIM alignment for each source.

Volume provides context. A high-volume failure from a known CRM can affect many customer-facing messages and deserves immediate remediation. A low-volume failure from an unknown IP may be a spoofing probe, a newly deployed tool, or an isolated forwarding path. It should be recorded, then compared with later reports instead of triggering an instant policy change.

Classify the source before judging the failure

Map each source_ip to a business owner or sending service. Useful categories include:

Corporate mailbox platform: Employee mail may pass through a familiar provider, but the domain and alignment still need verification.

CRM or sales platform: These systems often send with a visible From address while requiring domain authentication configuration.

Transactional provider: Password resets, receipts, and onboarding mail may use a separate infrastructure path.

Marketing platform: Campaign traffic can be high volume and needs consistent SPF and DKIM alignment.

Forwarding path: SPF may fail after forwarding because the envelope sender changes, while DKIM survives if the signature remains valid.

Unknown source: An unfamiliar IP with both checks failing is a candidate for spoofing or an undisclosed sender.

The report groups traffic by source rather than showing a message-by-message log. Analysts should aggregate across days or weeks because a one-day report can hide recurring low-volume sources or make a newly added sender look more suspicious than it is. Header review can add context when a source is unclear, so teams can use this guide to read email headers when investigating a specific message.

SPF Result	DKIM Result	Typical Meaning	Action
Pass	Pass	Usually a legitimate, correctly aligned sender	Document the source and continue monitoring
Fail	Pass	Often forwarding, a mailing list, or an SPF configuration gap	Preserve DKIM, verify alignment, and investigate the sending path
Pass	Fail	Often a known service without custom DKIM	Configure aligned DKIM or confirm the service's supported setup
Fail	Fail	Potential spoofing, forwarding damage, or a misconfigured sender	Identify the owner, compare historical volume, and prioritize unknown high-volume sources

The key distinction is between authentication failure and business impact. A failure from a service sending critical onboarding mail may be more urgent than a larger number of isolated probes, even if the probe volume looks alarming. The final classification should be legitimate, forwarding-related, or unauthorized.

Remediation Actions for Common DMARC Failures

Remediation should happen before policy tightening. The operator needs to preserve at least one aligned authentication path for every legitimate sender, then verify the change through live DNS checks and later aggregate reports.

SPF failures from legitimate senders

If a recognized third-party provider sends mail for the domain and SPF fails, confirm the provider's documented authorization method. The usual options are an approved include mechanism or a dedicated sending subdomain.

A conceptual SPF record can be valid when it contains one SPF policy with authorized mechanisms and a final policy qualifier. A record becomes invalid when a domain publishes separate SPF TXT records instead of combining authorized mechanisms into one record. SPF also has a 10 DNS lookup limit, so adding providers without reviewing nested lookups can create a permanent error and hurt authentication.

A practical fix sequence is:

Identify the service owner: Confirm that the source IP belongs to the CRM, helpdesk, or transactional provider.

Use the provider's authorization value: Add the supported include or authorized source through the SPF record.

Watch lookup consumption: Review nested DNS lookups instead of adding mechanisms blindly.

Verify the live record: Run an SPF record check after publication.

If the service sends high-value mail, a dedicated subdomain can reduce interactions with the primary domain's sender map. It also gives the team a clearer boundary for policy and reputation monitoring.

DKIM alignment failures

A provider can authenticate a message with its own domain while the visible From address uses the customer's domain. That may produce a DKIM authentication result without DMARC DKIM alignment. The fix is usually to enable custom DKIM signing, publish the selector record supplied by the provider, and configure the service to sign with the customer's domain.

A selector is the DNS label used to find the public key. Teams should document selectors by provider, because multiple services can use distinct selectors without overwriting one another. After configuration, run a DKIM check and confirm that the signing domain aligns with the visible From domain.

Forwarding and mailing-list paths

Forwarding often breaks SPF because the forwarder becomes the immediate sender. DKIM may remain valid, which is why an SPF-fail and DKIM-pass row shouldn't be treated like a spoofing event by default. Teams should preserve DKIM signing at the original sender and test whether the forwarded message retains its signature and aligned domain.

Common Mistakes That Break Deliverability

DMARC policy changes can create more damage than the failures they're meant to address when teams skip source classification. The most common error is moving to p=reject because an operator sees unknown failures in a first report. That policy can block legitimate mail from a new sender that hasn't yet been discovered or aligned.

A single report also isn't a reliable picture of the domain. Receiving organizations produce summaries for their own traffic, and a one-day window can miss a periodic campaign, an infrequent invoice system, or a newly deployed sales tool. Trend analysis is safer because it distinguishes a recurring operational issue from an isolated observation.

What operators should avoid

Treating every fail as malicious: A third-party sender may be legitimate but misconfigured, and forwarding can break SPF without indicating abuse.

Ignoring low-volume sources: Small rows may be attacker probes or an unregistered tool. Keep them in the source inventory and compare them across later reports.

Tightening policy before fixing senders: Quarantine or reject can affect newsletters, support replies, receipts, and onboarding messages when alignment isn't complete.

Reading raw XML forever: Once a domain has more than a few dozen senders, manual parsing makes source ownership and trend detection difficult.

Relying only on a spam score: A score can't explain whether the actual problem is SPF, DKIM, DMARC alignment, DNS, blacklist status, or SMTP infrastructure.

Adoption is rising faster than enforcement. EasyDMARC's 2025 report recorded top-domain adoption increasing from 27.2% to 47.7% between 2023 and 2025, while 7.6% of 10 million popular domains in Fortra's Q2 2025 dataset used enforcement policies and 81.6% had no DMARC record (the 2025 adoption report). Those figures explain why many teams operate in monitoring mode and see failures without having a policy that changes delivery.

The correct prioritization order is straightforward: identify legitimate high-volume senders, fix their alignment, monitor unknown sources, and use sustained trends to decide when enforcement is safe.

Automating DMARC Report Analysis with Modern Tools

Raw XML stops being practical when a domain has more than a few dozen sending sources. The issue isn't merely file volume. Operators must normalize reports from different receivers, compare dates, identify IPv4 and IPv6 sources consistently, and map changing IPs to stable business sender names.

A useful normalized dataset should include:

UTC timestamps: Reporting windows remain comparable across receiving organizations.

Consistent address handling: IPv4 and IPv6 sources are stored and searched in a predictable way.

Canonical sender naming: Multiple addresses belonging to one CRM or provider appear under one recognizable owner.

Historical outcomes: Pass and fail trends can be reviewed without opening each attachment.

A parsed DMARC report analyzer can turn source IPs, message counts, alignment outcomes, and receiver dispositions into a view that supports decisions. mailX is one option for this workflow. Its free diagnostic suite runs live checks across SPF, DKIM, DMARC, BIMI, MX, DNS records, blacklist status, SMTP and IMAP connectivity, and related email infrastructure, then returns plain-English explanations and remediation steps.

That model is useful for both technical founders and developers because it connects report findings to the surrounding deliverability system. A DMARC failure may be caused by a missing DNS record, an incorrect selector, an unrecognized sender, or an infrastructure issue that a DMARC-only view cannot explain.

AI agents create another reason to automate. An agent can draft, send, monitor, and optimize messages, but it shouldn't send blindly. A pre-send workflow can check authentication, domain health, blacklist status, and DNS configuration through a structured API or an MCP connection for an AI agent, then route risky changes for human review.

Policy Rollout and Monitoring Best Practices

A safe rollout starts with p=none, which provides visibility without asking receivers to quarantine or reject failing mail. During this stage, the team should map every legitimate sender, fix SPF or DKIM alignment, and track each sender's pass rate over time instead of reacting to one report.

Move to p=quarantine only after legitimate traffic remains clean and unknown sources are the remaining failures. Move to p=reject after quarantine operates without unexpected legitimate-mail failures. The available data supports the direction, but it doesn't provide a universal pass-rate threshold or a fixed waiting period, so policy decisions must reflect the domain's sender complexity and business risk.

During rollout, monitor sending behavior as closely as authentication. Sudden volume spikes can hurt sender reputation even when SPF, DKIM, and DMARC are configured correctly. Teams should also watch bounce rate, spam complaints, blacklist status, and inbox placement. A practical deliverability benchmark is a bounce rate below 2% and a spam complaint rate below 0.1%, but context matters (industry guidance on DMARC aggregate reporting).

The complete workflow is: check SPF, check DKIM, check DMARC, inspect aggregate reports, classify sources, repair alignment, tighten policy gradually, and run a full deliverability audit to verify the surrounding DNS and infrastructure.

Use mailX to run a free live deliverability audit that checks DMARC, SPF, DKIM, DNS, blacklist status, and mail infrastructure in one place. It gives humans and AI agents clear explanations and exact remediation steps, so the next DMARC report leads to a fix instead of more guesswork.