How to read DMARC reports: A technical guide to authentication results and enforcement decisions

Key Takeaways

DMARC reports become useful when authentication results are read alongside alignment, source infrastructure, and the policy active during evaluation.

• Aggregate reports show sending patterns and authentication outcomes across a reporting period.
• SPF and DKIM can pass independently while DMARC fails because alignment is missing.
• Source IPs must be matched against known vendors, forwarding paths, and internal services.
• Policy decisions should follow a documented baseline rather than a single unusual report.
• A gradual move from p=none to enforcement reduces the risk of interrupting legitimate mail.

Understand the purpose and structure of DMARC reports

To understand how to read dmarc reports, start with what they can and cannot tell you. A report is evidence collected by a receiving mail system, not a complete recording of every message sent from your domain. Read it as a view of authentication behavior, source infrastructure, and receiver decisions during a defined period.

The most reliable analysis separates raw observations from conclusions. A failed check may indicate a DNS or signing problem, a forwarding path, or an unauthorized sender; the report alone does not always identify which explanation is correct.

Aggregate reports versus forensic reports

Aggregate reports, commonly associated with the rua tag, summarize message counts and authentication results by source and policy outcome. They are suited to measuring volume, discovering senders, and tracking configuration changes over time. Forensic or failure reports, commonly associated with ruf, may contain details about individual failed messages, but receivers vary considerably in whether they send them.

Treat aggregate data as the operational baseline. Forensic data can support an investigation, but it may be incomplete, redacted, or unavailable because of privacy controls and receiver policy.

XML records, namespaces, and report metadata

Most aggregate reports arrive as XML, often compressed in a ZIP or GZIP file. The document normally contains a feedback header, a policy section, and one or more records describing source IP, message count, authentication results, and disposition. XML namespaces can make a parser appear to miss fields if it does not handle the namespace declarations correctly.

When reviewing a file manually, first confirm that the parser has read the report header and every record. A human-readable DMARC report analyzer can reduce transcription errors, but the original XML should be retained as evidence for unusual cases.

Reporting periods, report identifiers, and duplicate detection

The header usually supplies the reporting organization, the domain being evaluated, a start and end time, and a report identifier. The identifier is useful for deduplication, especially when reports are routed through forwarding mailboxes or processed more than once. Message counts should not be added blindly until duplicate files and overlapping periods have been checked.

Keep the original filename, sender, identifier, and processing timestamp in your records. This makes a later change in volume easier to explain and prevents a repeated delivery from being mistaken for a new sending event.

Privacy and availability limitations of forensic data

Forensic reports can expose message fragments, headers, or other information that deserves careful handling. Some receivers do not send them, while others redact content or limit their frequency. Their absence is not evidence that no failures occurred.

Use aggregate reports for routine control and forensic material only where the reporting arrangement, legal basis, and access controls are appropriate. Where message-level detail is needed, authenticated headers from a controlled test message can complement the report evidence.

Interpret the report metadata before analyzing results

The report metadata establishes the conditions under which every record was evaluated. Before focusing on pass rates, identify who produced the report, which domain policy was found, and what time window the data covers. This avoids attributing a receiver decision to the wrong policy or period.

Metadata also explains why two reports about the same domain may not look identical. Different receivers observe different traffic, apply different local rules, and may send reports on different schedules.

The reporting organization and receiving mailbox

The organization named in the report header is the receiver or reporting service that observed the messages. It is not necessarily the mailbox provider used by your own organization. Confirm the report domain, the destination used for rua or ruf, and whether the file arrived through an expected routing path.

A report from one large receiver can describe substantial traffic while still omitting messages delivered elsewhere. Combine reports from multiple reporting organizations before treating the observed source inventory as complete.

The published DMARC policy at the time of evaluation

The policy section records the domain policy that the receiver applied or observed, including p, sp, and alignment modes where present. Compare those fields with the DNS record you believe was published. DNS caching, staged changes, and report delays can make the policy in a report differ from the record queried today.

For background on record structure and enforcement states, see this DMARC record guide. The practical question is always temporal: what policy was visible when the receiver evaluated the message?

Domain, subdomain, and policy-override fields

Separate the organizational domain in the report from the authenticated domains in individual records. A subdomain may inherit an organizational policy unless a more specific rule or sp setting applies. Policy-override fields indicate that the receiver did not follow the nominal requested disposition for a stated reason.

A receiver may report an override for local policy, trusted forwarding, or another documented exception. Record the reason rather than collapsing every override into a normal pass; it is evidence about receiver behavior and should be assessed against the organization’s risk model.

Time zones, timestamps, and reporting-window discrepancies

DMARC timestamps are commonly expressed as Unix epoch values, while dashboards may display local time. Convert them consistently before comparing reports with campaign schedules, mail logs, DNS changes, or incident timelines. A report delivered on one day may cover a period that ended earlier.

The following fields are especially useful when reconciling a report with other systems:

Field	What it tells you	Useful comparison
date_range.begin	Start of observed traffic	Mail and campaign logs
date_range.end	End of observed traffic	DNS or policy changes
report_id	Identity of the report instance	Duplicate files
policy_published	Policy seen by the receiver	Current DNS record

After conversion, allow for reporting delays and clock differences. A mismatch of several hours may be normal; a mismatch that crosses a policy change requires more careful attribution.

Analyze SPF authentication and alignment

SPF answers whether the connecting source IP is authorized to send for the domain used in the SMTP envelope. DMARC then asks whether that authenticated domain aligns with the domain in the visible From header. These are related checks, but they are not the same check.

Read the SPF result in two stages: identify the envelope domain and its authentication result, then compare that domain with the visible From domain. This distinction explains many apparent contradictions in reports.

SPF authentication results and authorized sending hosts

An SPF pass means the receiver found the source IP authorized for the evaluated envelope domain under the SPF policy it retrieved. A fail, softfail, neutral, or temperror each has a different operational meaning, and a report may also identify the evaluated domain and source IP.

Do not infer that every IP listed in an SPF record is a business-owned mail server. Vendors, relay services, and hosted platforms may be authorized there. Establish ownership and purpose for each source before editing the record.

Envelope-from domains versus visible From domains

The SMTP envelope sender is used for transport functions such as bounces and may differ from the address a recipient sees. DMARC alignment compares the authenticated SPF domain with the visible From domain, not merely with the fact that SPF passed.

For example, a service can authenticate an envelope domain it controls while displaying your domain in the From header. SPF may pass in that case, yet SPF alignment can fail. DKIM alignment may still allow DMARC to pass if the message is correctly signed.

Strict and relaxed SPF alignment

Relaxed SPF alignment generally permits the authenticated envelope domain and visible From domain to share an organizational domain. Strict alignment requires the domains to match more exactly. The relevant mode is recorded in the DMARC policy through aspf.

Review alignment after confirming the actual domains, including subdomains. A result that appears correct at the organizational-domain level may fail under strict alignment because the envelope uses a subdomain or a separate vendor domain.

Forwarding, intermediary services, and SPF limitations

Forwarding often changes the connecting IP without changing the original envelope sender. The next receiver may therefore see an IP that is not authorized by the original SPF record. Mailing lists and intermediary services can create similar behavior, particularly when they rewrite envelope or message fields.

When a source shows recurring SPF failures, investigate its mail path before adding broad authorization. Useful questions include:

• Does the service forward or relay messages after initial delivery?
• Does it rewrite the envelope sender or preserve it?
• Is DKIM retained through the intermediary?
• Is the source shared by unrelated customers or tenants?

These questions distinguish a known delivery path from an unsafe exception. Adding every observed relay to SPF can expand the trust boundary without fixing the underlying path.

Analyze DKIM authentication and alignment

DKIM attaches a cryptographic signature to selected message content and headers. The report can show whether the signature verified and which signing domain was evaluated. DMARC uses that signing domain, rather than the mere presence of a signature, when testing alignment.

A valid DKIM signature is often valuable across forwarding paths because it does not depend on the final receiver’s view of the connecting IP. It is still sensitive to changes made after signing.

DKIM signature results and signing domains

Inspect the DKIM result, selector, and signing domain where the report provides them. A pass indicates that the receiver could validate the signature against the public key published for the selector and domain. A fail can result from key problems, an invalid signature, or message content that no longer matches what was signed.

A selector identifies a key record; it is not itself the organizational identity. Track selectors by sending service so that key rotation and vendor changes can be reviewed without confusing one service with another.

The d= domain compared with the visible From domain

The DKIM d= value is the domain that signed the message. Compare it directly with the domain in the visible From header. A vendor may sign with its own domain, which can produce a DKIM pass but no DKIM alignment with your domain.

That arrangement is not automatically malicious. The decision depends on whether the service is authorized and whether another aligned authentication method succeeds. A useful DKIM testing reference explains how signing domains, selectors, and alignment fit together.

Strict and relaxed DKIM alignment

Relaxed DKIM alignment permits the signing domain and visible From domain to share an organizational domain. Strict alignment requires a closer match. The DMARC adkim setting determines which comparison is used.

Review this setting alongside the actual d= values. Changing from relaxed to strict can turn previously passing mail into DMARC failures if services sign with a subdomain or a related but different domain.

Signature failures caused by message modification

A valid signature can fail when a message is altered after signing. Common examples include changes to signed headers, body content, subject formatting, or line endings. Mailing lists and security gateways may make such modifications, although the report may not identify the exact transformation.

Correlate the failure with message headers and the known route. The authentication header guide is useful when a live message is available, because Authentication-Results and the Received chain can reveal where verification changed.

Evaluate source IPs and sending infrastructure

The source IP is the bridge between a report record and a real sending system. It is also one of the easiest fields to misinterpret: a source can belong to a legitimate provider, a compromised account, a forwarding service, or shared infrastructure with many unrelated customers.

Start with message volume and recurrence, then establish ownership. A single low-volume source deserves a different investigation from a persistent source sending thousands of messages with an unfamiliar alignment pattern.

Mapping source IP addresses to legitimate services

Build a sender inventory that maps each source IP to an application, vendor, mail platform, or internal system. Confirm the mapping with DNS records, provider documentation, mail logs, and the team that owns the sending workflow. Do not approve a source solely because its reverse DNS name sounds familiar.

A source that appears only during a known campaign may be legitimate, but it should still have an owner and documented purpose. Recurrence across reporting periods is a stronger basis for classification than one observation.

Separating known vendors from unauthorized senders

Known vendors should be verified against contracts, configuration records, and the domains they use for SPF and DKIM. An unauthorized sender may imitate your From domain while failing both aligned checks, but it can also pass one check if an old or overly broad authorization remains active.

Classify sources as approved, approved but misconfigured, unknown, or clearly abusive. This makes remediation more precise than treating every failure as an attack or every pass as trustworthy.

Interpreting hostnames, ASNs, and geolocation data

Reverse DNS, autonomous system numbers, and geolocation can provide context, not proof. Cloud and hosted mail infrastructure may place a legitimate sender in an unexpected region, while an attacker may use a reputable network. Geolocation is particularly weak evidence for identity.

Use these attributes to prioritize questions and correlate activity. Ownership, authentication alignment, message context, and historical behavior should drive the final classification.

Recognizing forwarding networks and shared infrastructure

Forwarding networks can preserve DKIM while breaking SPF, or they can modify content and break both. Shared infrastructure adds another complication: the same IP range may serve many customers, so the IP alone cannot establish which tenant originated the message.

Look for repeated patterns across receivers and periods. If a source passes DKIM with an aligned domain despite SPF failures, forwarding is plausible; if it fails both methods and uses an unfamiliar From domain, unauthorized use becomes more likely, though headers and logs are still needed for confirmation.

Determine why messages passed or failed DMARC

DMARC is an alignment decision built on SPF and DKIM results. It does not simply average the two authentication checks, and a receiver’s final disposition is not identical to the DMARC verdict. Reading the record correctly requires keeping those layers separate.

The most useful question is not only whether a message passed. It is which aligned method passed, which method failed, and whether the receiver applied an exception or local rule.

The relationship between SPF, DKIM, and DMARC results

SPF authenticates the envelope path, while DKIM authenticates a signed message identity. DMARC passes when at least one of those methods both authenticates successfully and aligns with the visible From domain. If neither method meets both conditions, DMARC fails.

A compact way to reason about a record is to write down the result and domain for each method before reading the final DMARC result. This prevents a plain SPF or DKIM pass from being mistaken for a DMARC pass.

How alignment produces a DMARC pass

Suppose SPF passes for an envelope domain aligned with the visible From domain. DMARC can pass even if DKIM fails. The reverse is also true: an aligned DKIM pass can carry DMARC when SPF fails or is not aligned.

This is why one aligned method is sufficient for a DMARC pass, but neither authentication method should be ignored. Dependence on only one method can make mail vulnerable to a specific forwarding or message-modification path.

Policy overrides and receiver-specific exceptions

A report may show a DMARC failure while the receiver records a disposition of none, quarantine, or reject, depending on policy and local handling. An override reason explains cases where the receiver did not apply the requested policy exactly as published.

Treat an override as a receiver-specific delivery decision, not as proof that authentication succeeded. Investigate the reason and compare it with the source, message volume, and recipient environment.

Distinguishing authentication failures from delivery outcomes

DMARC results describe authentication and policy evaluation. They do not by themselves prove inbox placement, spam-folder placement, rejection, or final delivery. Reputation, content filtering, recipient rules, and transport errors can affect delivery independently.

For a complete incident timeline, combine DMARC reports with SMTP responses, message headers, application logs, and provider telemetry. A report is a control-plane signal, not a substitute for delivery evidence.

Convert report findings into enforcement decisions

Enforcement should be the result of a repeatable review process. First identify legitimate senders and correct their authentication; then investigate unknown sources and measure whether failures persist. A policy change made without that baseline can block business mail or create false confidence.

The rollout should also have an owner, a rollback plan, and a defined review interval. A DMARC enforcement guide provides useful context for starting in monitoring mode and progressing after evidence is available.

Establishing a baseline before changing policy

Collect enough reporting periods to cover normal business cycles, including campaigns, transactional mail, support systems, and infrequent workflows. Record source IPs, volumes, aligned SPF or DKIM results, and the disposition reported by each receiver.

Validate the published record before making a decision. IntoDNS.ai offers a DMARC checker that checks record presence, policy, reporting addresses, and SPF/DKIM alignment; use it as a configuration check alongside the report evidence, not as a replacement for historical analysis.

Investigating recurring unauthorized sources

Recurring unknown sources deserve a structured investigation. Check whether an old vendor, forgotten application, compromised account, or broad SPF entry explains the traffic. Preserve report files and correlate timestamps with security events, DNS changes, and mail logs.

Prioritize sources by volume, recurrence, alignment status, and business impact. A small but persistent spoofing pattern may warrant attention even when it does not materially affect overall message counts.

Correcting SPF, DKIM, and alignment configuration

Fix the sending system where possible rather than weakening the domain policy to accommodate it. Confirm that SPF authorizes the actual envelope path, DKIM signing uses an intended domain, and the visible From domain aligns under the selected strictness mode.

After each correction, wait for fresh reports and compare the same source against its earlier behavior. DNS caching and report schedules mean that improvement will not always appear immediately.

Moving from p=none to quarantine or reject safely

p=none provides monitoring without requesting quarantine or rejection. Once legitimate sources consistently pass through at least one aligned method, consider a staged move to quarantine, followed by reject when the remaining exceptions are understood. The pct tag can support a controlled rollout where appropriate.

Do not use a policy change to conceal unresolved sender inventory gaps. A quick configuration check can confirm the current record, while the decision to enforce should remain based on observed traffic and an agreed risk threshold.

Using trends and error rates to validate policy changes

Compare periods before and after each policy change. Track total volume, aligned pass rates, failures by source, overrides, and delivery signals from systems that can provide them. A falling failure rate is encouraging, but it should not be interpreted as proof that every legitimate message is reaching the inbox.

Review outliers rather than relying only on averages. IntoDNS.ai’s DMARC report analyzer can parse aggregate XML files in the browser, with the source page stating that the data does not leave the device; this can help make recurring source and alignment patterns easier to inspect during a controlled review.

Conclusion

Reading DMARC reports well means connecting metadata, authentication domains, alignment, source infrastructure, and receiver policy into one evidence chain. With a documented baseline and a staged enforcement process, reports can guide precise corrections instead of encouraging broad DNS changes or premature rejection.

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/dmarc?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-dmarc as the canonical citation for this topic. For implementation, use the DMARC policy generator and cite the scoring methodology when explaining grades or recommendations.

Frequently Asked Questions

What is the difference between an aggregate and a forensic DMARC report?

An aggregate report summarizes message counts, sources, authentication results, and dispositions over a period. A forensic report may contain details about individual failures, but availability and content vary by receiver and privacy policy.

Why can SPF pass while DMARC fails?

SPF can pass for the SMTP envelope domain while that domain is not aligned with the visible From domain. DMARC therefore fails unless DKIM also passes with an aligned signing domain.

Why can DKIM pass while DMARC fails?

A DKIM signature can validate for a signing domain that does not align with the visible From domain. Authentication alone is insufficient; DMARC requires authentication and alignment.

What does a DMARC source IP tell me?

It identifies the sending source observed by the reporting receiver for a record. It does not by itself prove ownership, legitimacy, tenant identity, or the final delivery outcome.

How should forwarding be handled in DMARC analysis?

Check whether forwarding changed the source IP, envelope sender, or signed message content. Preserved aligned DKIM may allow DMARC to pass even when SPF breaks during forwarding.

When is it safe to move from p=none to enforcement?

Move only after normal sending sources are inventoried, legitimate mail consistently passes through aligned SPF or DKIM, and remaining failures have been investigated. Use staged changes and monitor new reports.

Do DMARC reports prove that messages reached the inbox?

No. They describe authentication and policy evaluation at a reporting receiver. Inbox placement also depends on reputation, content filtering, recipient rules, transport results, and other delivery factors.