DMARC alignment, explained: why SPF passes but DMARC fails

Three domains in every message

A single email carries up to three domains that matter for authentication:

DMARC passes only when SPF or DKIM passes and its domain aligns with the From: domain. In the example above, both SPF and DKIM pass, but for vendor.example, so DMARC fails for example.com.

Relaxed vs strict alignment

• Relaxed (default, aspf=r / adkim=r): the two domains must share the same organisational domain. bounces.example.com aligns with example.com; example.net does not.
• Strict (aspf=s / adkim=s): the domains must be identical. bounces.example.com does not align with example.com.

Relaxed is right for almost everyone, because it lets you put third-party senders on subdomains.

How the organisational domain is found

Under the original RFC 7489, receivers used the Public Suffix List to find the organisational domain (so example.co.uk, not co.uk). RFC 9989 replaces this with a "DNS tree walk": receivers query _dmarc records up the name, at most 8 queries. For ordinary domains the result is the same. The change matters mainly for public-suffix operators, who can now publish psd=y.

Reading the evidence

Every receiving server records what it checked in an Authentication-Results header. In Gmail it looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor.example header.s=s1 header.b=AbCdEf;
       spf=pass (google.com: domain of bounce-123@mail.vendor.example designates 198.51.100.7 as permitted sender) smtp.mailfrom=bounce-123@mail.vendor.example;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.com

Compare header.from with smtp.mailfrom (the SPF domain) and with header.i/header.d (the DKIM domain). Here neither aligns, so DMARC fails even though both underlying checks pass.

The common cases and their fixes

Case 1: SaaS sender uses its own bounce domain

Symptom: spf=pass smtp.mailfrom=…@vendor-domain, dmarc=fail.

Fix: most platforms offer a "custom return-path" or "custom bounce domain". You add a CNAME such as bounces.example.com → vendor's host. SPF is then checked against your subdomain, which aligns under relaxed mode. Better still, also set up custom DKIM (case 2).

Case 2: DKIM signed with the vendor's domain

Symptom: dkim=pass header.d=vendor.example, dmarc=fail.

Fix: enable custom-domain signing in the vendor's settings. It gives you one or more CNAME or TXT records at <selector>._domainkey.example.com. After that, d=example.com and DKIM aligns. This is the most robust fix, because DKIM survives forwarding. The DKIM selectors guide covers verification.

Case 3: Forwarding and mailing lists

Symptom: a message that passed at the first hop fails DMARC after a forward. SPF now sees the forwarder's IP, and a mailing list that adds a footer or subject tag breaks the DKIM body hash.

Fix: you can't change other people's forwarders. Make sure your mail is DKIM-signed, since plain forwarding keeps DKIM intact. Receivers like Gmail also consider ARC (RFC 8617) headers added by well-behaved intermediaries. Gmail exempts forwarded and mailing-list mail from its alignment requirement.

Case 4: Strict alignment set by accident

Symptom: a subdomain sender fails even though everything is "your domain".

Fix: remove aspf=s/adkim=s unless you specifically need strict mode.

A quick decision table

From the field: It is very easy to run into alignment problems when configuring DMARC. Ensure you have a firm grasp on all settings before you configure them. If you are unsure, leave it out until you do then come back and configure it if you still want it.

Check it

Use the Email Record Lookup to confirm your DMARC alignment settings and that DKIM keys exist for your selectors. For a specific sending IP, the SPF validator shows whether your domain's SPF authorises it. Remember that this only helps alignment if the vendor uses your domain in the envelope.

Sources

• RFC 9989: DMARC (May 2026)
• RFC 8617: Authenticated Received Chain (ARC)
• Gmail email sender guidelines FAQ