CertaDNS

DMARC alignment: why mail passes SPF and DKIM and still fails

Alignment is the step between "SPF passed" and "DMARC passed". How relaxed and strict modes differ, which domain each protocol actually authenticates, and why a forwarded message behaves differently.

Last reviewed

A message can pass SPF, pass DKIM, and still fail DMARC. This surprises people, and nothing in a DMARC record makes it obvious. The missing concept is alignment: DMARC only counts a pass if the domain that passed is related to the domain a human actually sees.

Three domains, not one

Every message carries several domain names, and it is easy to assume they are the same thing. They are not, and each protocol authenticates a different one.

DomainWhere it livesWhat authenticates it
MAIL FROMThe SMTP envelope. Also called the return-path or bounce address. Never shown to the recipient.SPF
d=The DKIM-Signature header. The domain whose key signed the message.DKIM
From:The message header. This is the only one the recipient sees.Nothing, on its own — which is the problem DMARC exists to solve.

SPF and DKIM both predate DMARC, and neither has anything to say about the From: header. That is the gap: a message can pass SPF for bounces.somesaas.com while displaying From: billing@yourbank.com, and SPF is perfectly happy, because SPF was never asked about the visible address.

DMARC closes it by requiring that at least one passing mechanism be aligned with the From: domain. Alignment is the whole of DMARC's contribution; everything else is reporting and policy.

Relaxed and strict

Two tags control how closely the domains must match: aspf for SPF and adkim for DKIM. Each takes r (relaxed) or s (strict), and relaxed is the default when the tag is absent.

ModeMatch requiredFrom: example.com passes if…
Relaxed (r)Organisational domainmail.example.com, bounces.example.com, or example.com itself
Strict (s)ExactOnly example.com

The difference matters more than it looks. Under relaxed alignment a subdomain passing counts for the parent, which is what makes it possible to send bulk mail from mail.example.com with its own SPF record and still satisfy DMARC for example.com. Under strict, it does not, and you will see a stream of inexplicable-looking failures in your aggregate reports from senders you know are legitimate.

Only one has to align

DMARC passes if either SPF or DKIM passes and aligns. Both failing is a DMARC failure; one passing and aligning is a DMARC pass, even if the other fails outright. This is why DKIM is worth having even on a domain with a perfect SPF record.

What real records look like

Cloudflare sets both modes explicitly to their defaults, which is a reasonable habit — it makes the intent visible to whoever reads the record next:

$ dig +short TXT _dmarc.cloudflare.com
"v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100;
  rua=mailto:…@dmarc-reports.cloudflare.net,mailto:rua@cloudflare.com"

The BBC runs strict alignment on both, which is a deliberate and fairly demanding choice — every sender has to authenticate as the exact domain:

$ dig +short TXT _dmarc.bbc.co.uk
"v=DMARC1;p=reject;aspf=s;adkim=s;pct=100;fo=0;ri=86400;
  rua=mailto:dmarc_agg@vali.email;"

You can read your own with the DMARC Inspector, which spells out what each alignment mode means for your record rather than just echoing the tag.

Why forwarding changes the answer

Forwarding is where alignment stops being theoretical. When a mailing list or a .forward rule relays your message:

  • SPF breaks. The forwarding server connects from its own IP, which your SPF record does not authorise. SPF fails — correctly, from its own point of view.
  • DKIM usually survives. The signature travels with the message and covers the headers and body, so it still verifies at the far end as long as nothing rewrote them.

So on a forwarded message DMARC depends entirely on DKIM being present and aligned. A domain relying on SPF alone will see forwarded mail fail DMARC, and at p=reject that mail is gone. This is the single most common reason a move to enforcement causes complaints.

Mailing lists make it worse by modifying the message — prepending [list-name] to the subject, or appending a footer — which invalidates the DKIM signature too. That is what ARC exists to address, and it is also why most well-run lists now rewrite the From: header instead.

Which mode to use

Start relaxed. It is the default, it is what almost every domain runs, and it accommodates the normal practice of sending different classes of mail from subdomains. Strict alignment buys you protection against a fairly narrow attack — someone who controls a subdomain of your organisational domain — and costs you every legitimate sender that authenticates as anything other than the exact name.

Consider strict only when you already have full visibility from aggregate reports, every sender is enumerated, and you have a specific reason: usually a high-value domain where subdomain compromise is a live concern. Moving to strict without that visibility is a reliable way to start rejecting your own mail.

Diagnosing an alignment failure

In an aggregate report, look for a row where SPF or DKIM shows pass in the authentication results but the corresponding DMARC column shows fail. That gap is alignment, every time. The report also tells you which domain passed, which is usually enough to identify the sender.

Check this on your own domain

Free, no account, reads public DNS only.

Related

CertaDNS automates most of what is described above — Email Authentication. The manual route above works perfectly well; the product exists because keeping it correct as your senders change is the part that does not stay done.