DMARC explained: why SPF and DKIM pass but your email fails

Editorial review note, remove before publication: This is a complete working draft, not a technically cleared article. The public research allowance blocked primary-source verification. Confirm the protocol details flagged below against the current DMARC specification, SPF/DKIM specifications and Authentication-Results documentation. No claim about 2026 standards changes or adoption statistics is included. All header examples are illustrative, not captured customer messages. No hero image is proposed: the domain tables and annotated headers carry the explanation. Topic tags and category are left unset because the existing taxonomy contains no suitable technical category.

Your test email says spf=pass and dkim=pass. A few lines later, it says dmarc=fail. DMARC alignment explains the apparent contradiction: authenticating a sending service is not the same as authenticating the domain your recipient sees.

DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, connects those identities. It lets a domain owner publish a policy for mail that fails the check and request reports about how their domain is being used.

The fix starts with three domains in one message. Not another round of adding DNS records until a checker turns green.

The short version

• SPF checks whether the sending server is authorized for the envelope-sender domain.
• DKIM checks a cryptographic signature associated with a signing domain.
• DMARC checks whether a passing SPF or DKIM result aligns with the domain in the visible From header.
• One passing, aligned authentication path is enough. Two passing but unaligned paths are not.

For a platform sending on behalf of customers, the practical consequence is simple: a test from your platform's domain does not prove that sending from a customer's domain will pass DMARC.

[confirm: Verify the definitions and pass condition above, the alignment rules below, and the illustrative Authentication-Results syntax against current primary specifications before publication.]

Start with the three identities, not the DNS dashboard

Suppose your app sends a booking confirmation for a customer using customer.example. Your delivery provider uses provider.example for some of its infrastructure.

These are three separate identities:

The visible sender is the identity your customer wants to use. The envelope sender and signing domain are identities used along the sending path. DMARC asks whether a successful authentication result connects back to the visible sender.

A display name is not that connection. Neither is a Reply-To address. Changing where replies land does not fix a mismatch between the authenticated domain and the From domain.

Why SPF and DKIM can both pass while DMARC fails

Here is an illustrative message with successful authentication and unsuccessful alignment:

SPF has authenticated the provider's envelope-sender domain. DKIM has authenticated a signature from the provider's signing domain. Neither result authenticates an identity aligned with customer.example.

The provider has proved something about its own domains. It has not yet provided the aligned pass this customer needs.

That distinction changes the repair. Adding another provider to the customer's SPF record will not, by itself, change a message that still uses the provider's domain as its envelope sender. Changing the DKIM selector will not fix a signature whose d= domain is still unrelated to the visible sender.

Inspect what the actual message uses before changing what DNS authorizes.

Fix one path, then test it

A working configuration could use DKIM signing for the customer's domain:

SPF is still unaligned. DMARC can pass because the DKIM path now both authenticates and aligns.

Another configuration might use a customer-aligned envelope sender. The important outcome is not three green labels on a DNS setup screen. It is at least one passing, aligned authentication result on a delivered message.

Relaxed and strict alignment change what counts as a match

DMARC supports relaxed and strict alignment. The adkim setting applies to DKIM alignment; aspf applies to SPF alignment. They are separate controls.

For an ordinary domain such as customer.example, the practical distinction looks like this:

Strict alignment requires an exact domain match. Relaxed alignment permits the relevant organizational-domain relationship, including the straightforward subdomain example above. It does not mean that any domain belonging to the same company or provider qualifies.

The default alignment mode is relaxed. Do not enable strict alignment just because it sounds more secure. First establish whether every legitimate sending path can meet it.

This table is deliberately about a simple domain structure. For public suffixes, delegated subdomains and policy-discovery edge cases, use the current specification rather than treating the last two labels of every hostname as an organizational domain.

Read the result from a real receiving mailbox

Send through the same path your app uses in production. Open the received message's original source and find the Authentication-Results header added by the receiving service you trust.

This simplified example shows the mismatch:

Read the identity next to each result:

1. smtp.mailfrom shows the domain used for the SPF result.
2. header.d shows the signing domain associated with the DKIM result.
3. header.from shows the visible sender domain evaluated for DMARC.

Here is the same example after customer-domain DKIM signing is working:

Both examples have passing SPF and DKIM. The difference is which domain the passing DKIM signature authenticates.

Use the receiver's result, not an arbitrary header claiming that authentication passed. Keep enough context to distinguish the receiving system's evaluation from headers added earlier in the message's journey.

Publish a monitoring policy before asking receivers to enforce it

A DMARC policy is published as a DNS TXT record. For customer.example, the direct policy location is _dmarc.customer.example.

A minimal monitoring policy is:

That record requests no DMARC-specific enforcement. It does not disable spam filtering, and it does not guarantee acceptance. It also does not configure a reporting destination by itself.

For a useful monitoring rollout, configure aggregate reporting as well. The rua tag identifies where reports should go. Use a destination you control or a reporting service's documented destination, and complete any authorization required for reports sent to another domain.

[confirm: Verify DNS publication, policy-discovery behavior, reporting-destination authorization and receiver discretion against the current DMARC and aggregate-reporting specifications. Add a verified, copy-ready reporting example before publication.]

You can inspect the direct DNS record with:

Replace the illustrative domain with yours. Check for an existing policy before adding one; duplicate DMARC policy records are not a way to combine settings. A successful DNS lookup still does not prove that messages sent through your app align.

Treat the policy as a request, not a delivery verdict

Receiving systems apply their own policies. A DMARC pass is not an inbox-placement guarantee, and a published policy is not proof that every receiver handled every message the same way.

Move toward enforcement by fixing senders, not watching a calendar

Before requesting quarantine or rejection, inventory the services sending from your domain. Include password resets, booking confirmations, support replies, billing notices and any other legitimate stream using that visible sender.

For each service, record:

• The visible sender domain.
• The envelope-sender domain.
• The DKIM signing domain.
• The authentication and alignment result from a received test.
• The person responsible for fixing that sending path.

Then compare that inventory with aggregate reports. An unexpected source needs investigation. It might be an unauthorized sender, but it might also be a legitimate service that nobody included in the migration plan.

Do not move to rejection because a monitoring record has existed for a particular number of days. Move when you understand the legitimate sources and have evidence that they align. Include infrequent jobs in that evidence, not just the busiest transactional stream.

The safest rollout is a sequence of verified changes: identify a sender, fix its authentication path, test a real message, then check the reporting evidence. Tighten policy when that evidence supports it.

Account for forwarding and message changes

A direct delivery test does not cover every route. Forwarding can change the server that delivers a message to the final recipient, which can affect SPF. A DKIM signature may survive forwarding if the signed content remains intact, but changes to signed headers or the message body can break it.

That is another reason not to treat SPF and DKIM as interchangeable checkboxes. A path that works on direct delivery may behave differently through a forwarder or mailing list.

When investigating a forwarded failure, compare the direct and forwarded copies. Establish which authentication result changed before changing the sender's DNS policy.

[confirm: Verify forwarding and DKIM-survival guidance against the relevant primary specifications. Keep any discussion of receiver exceptions or ARC out of this draft until independently sourced.]

For SaaS platforms, make alignment a per-customer test

A platform can authenticate its own domain perfectly and still misconfigure a customer's sending identity. The unit of verification should be the domain a customer will actually use, through the sending route that will actually carry their messages.

PostShiba uses tenants to separate customer domains, SMTP credentials, inboxes and suppressions, as described in our beta introduction. That structure gives you a place to organize customer sending. It does not make a test for one customer evidence for another.

A practical onboarding check should capture:

Repeat the test when the sending path changes. A provider migration, a new signing configuration or a different envelope-sender setup can change the identities that reach the receiver.

Authentication is also not permission. Our stance on cold email applies whether a message passes DMARC or not. An authenticated unsolicited campaign is still unsolicited.

Debug the identity before editing the policy

When a message fails DMARC, work through this list in order:

1. Find the visible sender domain. Ignore the display name and Reply-To for alignment.
2. Read the receiver's SPF result and authenticated identity. A pass for the provider's domain may not align with the customer's domain.
3. Read the DKIM result and signing domain. The existence of a signature is not the same as a passing, aligned signature.
4. Check alignment mode. A subdomain relationship that works in relaxed mode may fail an exact-match requirement.
5. Fix the failing path. Change the signing or envelope-sender configuration that the message actually uses.
6. Send again and inspect the received copy. Do not stop at a DNS checker.
7. Evaluate policy changes separately. Weakening enforcement may change handling without fixing authentication.

Start with one failing message. Write down its visible sender, envelope sender and DKIM signing domain side by side. That comparison tells you whether you have an authentication failure, an alignment failure, or both.

Source and verification ledger

• PostShiba public beta introduction: read for tenant separation and customer-domain sending context.
• PostShiba stance on cold email: read for the distinction between authentication and permission.
• Competing DMARC guide: supplied as the editorial comparison, not used as primary protocol authority.
• Outstanding before publication: open and cite the current primary DMARC specification, aggregate-reporting specification, SPF and DKIM specifications, and Authentication-Results documentation. Resolve every [confirm: ...] note above and remove this editorial ledger or replace it with a reader-facing source list.