Why a DMARC Pass Is Not Proof of Inbox Delivery

Read authentication, alignment, aggregate-report counts and provider requirements as separate evidence.

A DMARC pass means that a passing SPF or DKIM identity aligns with the visible From domain. It does not certify inbox placement or a reader opening the message. Current DMARC and aggregate reporting are specified in RFC 9989 and RFC 9990, published in May 2026; RFC 7489 is the earlier specification.

Follow the domain behind each result
Strict and relaxed alignment are different comparisons
An original hypothetical 100-message example
Read aggregate reports without inventing delivery evidence
Provider requirements extend beyond the DMARC pass rule
A practical order for an existing delivery problem

Follow the domain behind each result

For From: alerts@example.com, the Author Domain is example.com. SPF can evaluate both HELO and MAIL FROM, but DMARC uses SPF validation of the MAIL FROM identity. DKIM's authenticated identity is a validated signature's d= domain. Authentication of an unrelated domain is not alignment with the visible sender.

The pass condition is an aligned SPF pass OR an aligned DKIM pass. Both mechanisms can pass for an unrelated domain while DMARC fails. Conversely, a failing SPF check does not force DMARC failure if a valid aligned DKIM signature supplies the other path. A pass validates domain use; it does not establish that the content is safe, desirable or delivered to an inbox. These distinctions follow RFC 9989, sections 2.4 and 4.3–4.4.

Strict and relaxed alignment are different comparisons

Strict alignment requires the same domain. Relaxed alignment compares Organizational Domains. In an ordinary example.com example, mail.example.com and news.example.com may align in relaxed mode while failing strict comparison. Do not implement this by comparing the last two labels: public suffixes, delegated namespaces and DMARC policy discovery matter. RFC 9989 describes a DNS tree-walk method, so an old explanation that treats the public suffix list as the only current method is incomplete.

aspf controls SPF alignment and adkim controls DKIM alignment. DKIM's separate simple and relaxed canonicalization settings describe signature processing, not this domain comparison. An alignment decision also requires the underlying authentication to pass.

An original hypothetical 100-message example

These invented groups illustrate the logic. They are not Ithy customer mail, a real XML report or a deliverability measurement. All display alerts@example.com.

Authentication and alignment must be read together

Group/count	SPF result and identity	DKIM result and identity	DMARC result
A / 80	Pass for example.net; unaligned	Pass for example.com; aligned	Pass through DKIM
B / 10	Pass for example.net; unaligned	Pass for example.net; unaligned	Fail despite two raw passes
C / 10	Fail for example.com	Pass for example.com; aligned	Pass through DKIM

The passing groups total 90 observations out of 100. That arithmetic is a 90% authentication result within this example, not a 90% inbox or open rate. Group C could occur on a forwarding path, but its outcomes are stipulated; forwarding does not guarantee that DKIM survives every modification.

Read aggregate reports without inventing delivery evidence

RFC 9990 defines the report fields. row/count records message observations to which the policy evaluation applied. policy_evaluated/spf and dkim are alignment-aware DMARC results; auth_results separately records underlying authentication. The report also identifies its reporting interval and reporter. It has no inbox-open measurement.

The current schema includes none, pass, quarantine and reject dispositions. Older RFC 7489 reports and deployed receivers may differ. Read the actual report version, policy and override reasons rather than translating a dashboard's “delivered” label into proof of a particular mailbox folder.

Deduplicate repeated reports by reporter and report identity before summing comparable periods. One reporter's observations do not account for every destination. Counts from overlapping windows, multiple reporting sources or an imported duplicate are not automatically unique sent messages.

Provider requirements extend beyond the DMARC pass rule

Google's sender guidance separately covers infrastructure, reputation, spam rates and applicable unsubscribe practices. Its bulk-sender requirements should not be reduced to “DMARC passed, therefore inbox.”

Microsoft's Outlook.com high-volume sender announcement applies to domains sending over 5,000 messages per day to the consumer service. It requires passing SPF and DKIM plus DMARC with at least p=none and alignment through either mechanism. That service requirement is stricter than the generic either-mechanism DMARC pass condition. Microsoft updated its announcement to specify rejection of non-compliant messages from May 5, 2025, using 5.7.515; do not rely on its struck-through earlier junk-folder rollout text.

A practical order for an existing delivery problem

Identify the visible From, MAIL FROM and DKIM signing domains in an existing message. Record raw authentication and alignment separately.
Match the relevant source and time period to aggregate reports, accounting for duplicate imports and missing reporters.
Read existing SMTP rejection or deferral responses. Acceptance, folder placement and a human opening are different events.
Check the recipient provider's current sender rules, reputation feedback and recipient-side observations.
Change configuration only after identifying the failure. Tightening a domain policy without accounting for legitimate senders can affect real mail.

This article explains interpretation. It changes no DNS record, sender policy, signing key or customer mail and uses no private report data. See the email domain and provider distinctions and how to verify a source's current version.

Generated with Ithy Pro; AI-assisted editorial and primary-source checks completed October 23, 2026. The three independent model perspectives are retained with corrections. Original examples and test limits are identified.

Primary references

Compare the AI responses

Read each model’s complete response below.

GPT-6 Luna

Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.

A DMARC pass establishes an aligned authentication path, not inbox placement or an open. The checked article uses RFC 9989 and aggregate-report RFC 9990, published in May 2026, plus direct Google and Microsoft guidance. Its examples are hypothetical, with no private message or report data.

The short answer: DMARC pass is not an inbox-delivery receipt. RFC 9989 says receivers compare the RFC5322.From domain with SPF and DKIM results and the DMARC policy, then determine how to handle the message. Its delivery flow allows inbox delivery or other local action based on the DMARC result. So authentication success does not, by itself, establish inbox placement. [1.2] [4.1]
The visible From domain, SPF MAIL FROM domain and DKIM d= signing domain are different identities. SPF itself can check HELO and MAIL FROM; current DMARC relies solely on the validated MAIL FROM identity for its SPF path. Compare that authenticated domain, or a validated DKIM d= domain, with the visible Author Domain.
Strict alignment requires identical domains; relaxed alignment requires a shared Organizational Domain. Current RFC 9989 specifies policy discovery and a DNS tree walk; a simplistic last-two-label comparison is inadequate. Alignment modes are distinct from DKIM signature canonicalization. At least one aligned authentication path must pass.
Illustrative example—not a real incident: a message has visible From `alerts@example.com`, SPF MAIL FROM `bounce@example.net`, and a DKIM signature with `d=example.com`. Suppose SPF passes but is not aligned, while DKIM passes and is aligned. DMARC passes through DKIM even though SPF’s authenticated domain differs. This example illustrates the either/or rule; it does not assert how any real provider would deliver the message. [1.3] [1.4] [5.1]
Illustrative aggregate-report table (invented counts; not a real report): | Example row | Reported message count | SPF result/alignment | DKIM result/alignment | DMARC result | Disposition | |---|---:|---|---|---|---| | A | 80 | pass / no | pass / yes | pass | none | | B | 20 | fail / no | fail / no | fail | quarantine | These rows show how counts can be grouped with authentication results and disposition; they are not inbox-open counts or proof that a recipient saw a message in a particular folder. RFC 9989 describes reports as feedback to domain owners, and the RFC’s delivery flow allows local recipient action beyond inbox delivery. [1.2] [4.1] [4.2]
Read the report's own version and fields instead of assuming a dashboard label measures a mailbox folder. RFC 9990 includes none, pass, quarantine and reject dispositions and distinguishes DMARC alignment results from underlying authentication. A report still is not recipient engagement telemetry.
Inspect existing headers, record the visible From and authenticated SPF/DKIM identities, and check which path aligns. Compare relevant aggregate observations without treating them as inbox opens. Investigate forwarding using the actual route: SPF can fail at a relay while DKIM may survive unchanged content. Then examine existing rejection and recipient-side evidence separately.

The excerpts do not establish how aggregate reports handle forwarding in detail, nor do they provide a universal mapping from reported disposition to inbox, spam-folder, or open outcomes.

Claude Haiku 5.5

Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.

DMARC was built on SPF and DKIM, which provide domain-level authentication so cooperating receivers can detect mail authorized to use a domain and handle it differently. [1.1]
The visible From domain, SPF MAIL FROM domain and DKIM d= signing domain are different identities. SPF itself can check HELO and MAIL FROM; current DMARC relies solely on the validated MAIL FROM identity for its SPF path. Compare that authenticated domain, or a validated DKIM d= domain, with the visible Author Domain.
Identifier alignment means the RFC5322.From domain matches a domain validated by SPF or DKIM. DMARC requires the From domain to be aligned with an Authenticated Identifier, and DKIM alignment may be strict or relaxed. [1.3] [10.5]
The RFC5322.From domain is the central identity because it is a required header guaranteed to be present and is what most mail clients show users as the originator, making it a prime target for abuse. [10.3] [10.4]
Receivers compare the RFC5322.From address to SPF and DKIM results and the DMARC policy, then use that outcome to decide handling and send reports. Recipient transport may still deliver to the inbox or take other local policy action based on the result. [1.2] [4.1]
Gmail requires the From domain to align with either the SPF domain or the DKIM domain for DMARC alignment, but its guidance separately warns that messages may still be sent to spam or blocked due to sender practices and reputation. [5.1] [5.2]
Microsoft's Outlook.com consumer-service requirements for domains sending over 5,000 messages per day require passing SPF and DKIM, plus DMARC at least p=none aligned through either mechanism. Its updated announcement specifies 5.7.515 rejection for non-compliance. This provider requirement is separate from the generic either-mechanism DMARC pass rule.
Aggregate reports describe observations for their stated interval, not necessarily a complete daily population. Read reporter, interval, counts, authentication and alignment results. RFC 9990 defines those fields; neither message counts nor disposition measure inbox opens.

Microsoft's Outlook.com consumer-service requirements for domains sending over 5,000 messages per day require passing SPF and DKIM, plus DMARC at least p=none aligned through either mechanism. Its updated announcement specifies 5.7.515 rejection for non-compliance. This provider requirement is separate from the generic either-mechanism DMARC pass rule.

No real aggregate report data or deliverability measurements were supplied, so the sample table in the illustrative example is hypothetical and cannot show actual inbox placement rates.

Reputation and content filter weighting is not specified in the supplied RFC excerpts; the relative weight of these factors is unverified.

Claude Sonnet 5.5

Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.

The short answer is that DMARC tests identity alignment, not mailbox placement. RFC 9989 describes receivers comparing the RFC5322.From address with SPF and DKIM results and the published policy, then using those results to decide handling. Authentication is therefore one input to a receiver's decision. [1.2]
The visible From domain, SPF MAIL FROM domain and DKIM d= signing domain are different identities. SPF itself can check HELO and MAIL FROM; current DMARC relies solely on the validated MAIL FROM identity for its SPF path. Compare that authenticated domain, or a validated DKIM d= domain, with the visible Author Domain.
Strict alignment requires identical domains; relaxed alignment requires a shared Organizational Domain. Current RFC 9989 specifies policy discovery and a DNS tree walk; a simplistic last-two-label comparison is inadequate. Alignment modes are distinct from DKIM signature canonicalization. At least one aligned authentication path must pass.
Alignment needs a validated domain from SPF or DKIM, or both, to match the From domain. Google says the From domain must align with either the SPF domain or the DKIM domain for DMARC alignment. A secondary source also warns that SPF or DKIM can technically pass while DMARC fails without alignment. This is why a green SPF or DKIM result alone is not enough. [1.3] [5.1] [8.3]
Illustrative example only, not a real incident: example.com sends through a vendor. Hypothetical aggregate rows: 900 messages from a vendor IP with SPF pass for bounce.example.net (not aligned) but DKIM d=example.com pass, so DMARC passes; 80 forwarded messages with SPF fail and DKIM pass, so DMARC passes; 20 messages with SPF pass for example.net and DKIM d=example.net, so DMARC fails. Passing rows still say nothing about whether a message reached inbox or spam, or whether anyone opened it. [1.2] [1.4] [5.1]
Aggregate reports are summaries of mail claiming to be from the domain, including sending IPs and SPF/DKIM outcomes, and RFC 9989 says reports include alignment indications. Counts are message volumes seen by a reporter, not opens. The RFC notes delivery to the inbox or other local policy action is based on the DMARC result. A report's disposition field is therefore not proof of inbox versus spam-folder placement. Vendor dashboards use categories like delivered or spam, but that is a vendor interpretation. [3.1] [4.1] [6.3]
Microsoft's Outlook.com consumer-service requirements for domains sending over 5,000 messages per day require passing SPF and DKIM, plus DMARC at least p=none aligned through either mechanism. Its updated announcement specifies 5.7.515 rejection for non-compliance. This provider requirement is separate from the generic either-mechanism DMARC pass rule.
Troubleshooting sequence, as reasoned guidance: 1) check one message's headers and the aggregate rows for the sending IP; 2) confirm SPF or DKIM aligned with the visible From domain; 3) look for forwarding, which can break SPF while DKIM may survive; 4) review SMTP rejection codes such as 421 or 550; 5) review IP reputation, complaints, engagement and content; 6) change one thing at a time. None of this guarantees inbox delivery. [5.4] [2.4] [2.5] [8.2]