SPF and DKIM pass, but DMARC fails: which domain passed?

If the immediate blocker is a pending Mailchimp status, start with the Mailchimp authentication checklist, then use the alignment examples below to interpret a receiving result.

A pass can be perfectly valid for the email platform’s domain while the address the recipient sees belongs to your client. That is the gap alignment checks are designed to expose. This guide helps an agency operator compare the identities, preserve unknowns, and write a useful handoff. It does not test your domain or approve a campaign for launch.

Put three domains beside each other

Start with a message received through the exact sending path being investigated. A preview, a separate transactional tool, or a message sent from a staff mailbox may use a different configuration.

Use the receiving service’s own authentication results. Do not trust an arbitrary Authentication-Results line simply because it appears in copied text. RFC 8601 explains why the receiver’s trust boundary matters. Keep full headers private: they can contain addresses, routing details, and message identifiers. Read the SPF specification and Authentication-Results specification for the protocol context.

A worked example: both checks pass for the wrong identity

The following domains and results are constructed examples, not customer evidence. Assume direct delivery and separate organizational domains for client.example and vendor.example.

The successful checks establish something about the vendor identity. They do not connect that identity to the client identity in the visible From. A reviewer who records only the two green verdicts loses the information needed to explain the DMARC failure.

Under the current DMARC specification, a pass needs a successful SPF or DKIM result whose domain aligns with the author domain. Relaxed alignment uses the same organizational domain; strict alignment needs identical domains. Check the applicable aspf and adkim settings rather than assuming the mode. Organizational boundaries cannot safely be determined by taking the last two labels of every domain. Read RFC 9989, the current main DMARC reference.

The practical next action is to inspect the ESP’s supported custom-domain authentication configuration. It is not to paste a universal DNS record from an article. The authorized ESP operator establishes what the platform expects; the authorized DNS operator applies only the supported, reviewed change.

A DMARC pass can still leave another requirement unmet

Now assume SPF passes for bounce.client.example, DKIM fails, and SPF alignment is relaxed. In this illustrative case, aligned SPF can satisfy DMARC. Change the SPF mode to strict and that same subdomain relationship no longer suffices. Alternatively, a passing DKIM signature for client.example could supply alignment even if SPF fails.

These cases explain DMARC’s decision. They do not mean the sender satisfies every mailbox-provider rule. For example, Gmail’s bulk-sender requirements separately call for both SPF and DKIM, as well as DMARC. One aligned method may explain a DMARC pass while the failed method remains a provider-level problem. Use the provider requirements comparison to keep the two questions separate. Read the Gmail sender guidelines for the provider’s current wording.

Also keep direct delivery separate from forwarding or mailing-list paths. A changed route can change the evidence. Record the path you tested before comparing results from different recipients or different messages.

When the only honest answer is “unknown”

A DNS checker can establish that a record was found. It cannot, by that observation alone, establish how a particular message was signed or evaluated. Likewise, an ESP setup badge describes a platform state; it is not the receiver’s verdict for every possible sending path.

If the real message evidence is missing, write “message-level authentication not observed.” If the result came from an unfamiliar intermediary, record that provenance. If the client cannot name the sending platform or authorize an operator, resolve that gap before prescribing a change. Unknown is a useful handoff status because it tells the next person what to collect.

Turn the comparison into one owner action

A good handoff separates the observation from the proposed fix. Here is an illustrative structure:

• Observation: the received test authenticated the vendor domain, while the visible From used the client domain.
• Unknown: whether this account’s selected sending path supports the expected branded DKIM configuration.
• Owner: the client’s authorized ESP operator, with the DNS operator available for supported records.
• Next action: compare the account’s authentication settings with that ESP’s current documentation and record the exact discrepancy.
• Recheck: send a new authorized test through the same path to a controlled recipient; inspect the receiver’s result and compare the identities again.

This is narrower and more useful than “fix DMARC.” It gives the client a fact, a responsible role, and a way to tell whether the work changed anything. Use the launch handoff checklist to record it.

Research note. Reviewed 28 September 2026. This is an editorial explanation with constructed examples, not a test of customer domains or a deliverability benchmark. RFC 9989 is the current main DMARC reference; mailbox providers’ documented requirements and actual receiver results still matter for a specific path. No assertion is made that every receiver implements every new protocol detail identically.