Why SPF and DKIM Can Pass While DMARC Fails

You open the headers of an outbound email and find three results:

spf=pass
dkim=pass
dmarc=fail

That can be a valid result. SPF and DKIM may have authenticated domains belonging to the sending service, while neither domain aligns with the address in the message's From field.

Before changing DNS, write down which domain passed each check. A screenshot with two green checkmarks leaves out the information needed to diagnose this failure.

Start With the Three Domains

The visible From address is the address the recipient sees as the author. For this example, it is Maya <maya@example.com>, so the domain DMARC evaluates is example.com.

For ordinary mail with a nonempty envelope sender, SPF checks the sending server's authorization to use the SMTP MAIL FROM domain. That envelope address handles bounces and can differ from the visible From address. See RFC 7208's explanation of the MAIL FROM identity.

DKIM checks a cryptographic signature. Its signing domain is the d= value in the DKIM signature, which can also belong to a service provider. The selector, s=, helps locate the key; it is not the domain used for alignment. RFC 6376 defines those signature fields.

DMARC connects a passing SPF or DKIM result to the From domain through alignment. On a particular message, at least one of those passing results must align. Two unaligned passes still fail DMARC. RFC 9989, Section 5.3.5

Read a Failure With Both Checks Passing

This is a synthetic excerpt, not a customer message or a complete message you can submit for testing. Assume an applicable DMARC policy exists for example.com, and the receiving service produced these results:

From: Maya <maya@example.com>
Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=sender.example.net;
    dkim=pass header.d=sender.example.net;
    dmarc=fail header.from=example.com

Read the domains alongside the results:

Neither authenticated domain aligns with example.com. The provider could be correctly configured to authenticate its own domain while the setup for your From domain remains unfinished.

The next step is to ask the sending provider which authenticated domains the message actually used and which settings control them. Do not assume adding another SPF include to example.com will change the MAIL FROM address that the service puts on a message.

Check Which Authentication Results You Can Trust

Use the original message source at the receiving mailbox. Identify the Authentication-Results field created by that receiving service or another authenticator it explicitly trusts.

A header can contain an assertion without making that assertion trustworthy. An unfamiliar server name at the start of Authentication-Results is a reason to ask the receiving administrator which result is authoritative, not a reason to accept the nearest pass. RFC 8601 describes this trust boundary and the handling of forged authentication results.

Keep the message ID and timestamp with your notes. When two people inspect different test messages or different receiving hops, they can reach different conclusions without either person noticing the mismatch.

Relaxed and Strict Alignment Change the Comparison

Strict alignment requires identical domains, compared without regard to letter case. Relaxed alignment uses the same Organizational Domain. The DMARC tags aspf and adkim select these modes separately for SPF and DKIM; both default to relaxed.

For a simple example, assume bounce.example.com and example.com share the Organizational Domain example.com. A passing SPF result for bounce.example.com aligns with From example.com under relaxed mode, but not strict mode.

Use that as an illustration, not a rule that strips every domain to its last two labels. RFC 9989, published in May 2026, replaces RFCs 7489 and 9091 and defines a DNS Tree Walk for Organizational Domain discovery. Receiver implementations can differ; have the receiving administrator confirm how an unexpected result was evaluated.

Give the Provider a Specific Handoff

For the synthetic failure above, aligned DKIM is one possible repair. If the provider signs with d=example.com and that signature validates, the expected result is:

From: Maya <maya@example.com>
Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=sender.example.net;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

This second excerpt is also synthetic. It shows the expected outcome after a configuration change, not instructions to edit a received header. The SPF result is still unaligned; aligned DKIM supplies the pass for this message.

Ask the provider to document the signing configuration and required DNS records, then send a fresh test through the same application and route that produced the failure. If the service supports a custom MAIL FROM domain, evaluate aligned SPF as well.

Use this checklist to keep the handoff useful:

• Campaign or application owner: Supply the sending application, From address, test time, message ID, and original received headers through an authorized support channel. Remove unrelated message content and unnecessary personal information.
• Receiving administrator: Identify the trusted authentication result, MAIL FROM domain, each passing DKIM d= domain, and the result of the alignment comparison.
• Sending provider: Confirm which account and route handled the test, whether signing for your domain is enabled, and which settings control the envelope sender.
• DNS administrator: Check the applicable DMARC policy and its alignment modes, plus the SPF and DKIM records the provider requires. Record the values before changing them.
• Person closing the issue: Attach a new received sample after the change. Verify authentication and alignment separately, and note any remaining failure on another sending route.

A test from a provider's console is useful, but I would also test the actual outbound email workflow before closing the issue. The handoff should identify exactly what was tested.

A Passing Message Does Not Finish the Setup

The per-message DMARC rule does not mean you should configure only one authentication protocol. Google's requirements for bulk senders to personal Gmail accounts include SPF, DKIM, and DMARC. For direct mail from those bulk senders, Google also requires the From domain to align with SPF or DKIM. Google's sender guidelines

DMARC passing also does not guarantee inbox placement. Google evaluates other sending requirements and reputation signals, while the DMARC standard leaves message handling to the receiver.

In an outbound email review, I would keep three questions separate: Did authentication pass? Did a passing domain align with From? What happened to the message afterward? That makes a support conversation much more useful than saying that DNS looks fine.

For the broader responsibility split, see Infrastructure vs. Sequencer: Which Variables Each One Controls.