What is DMARC alignment, and why does mail fail it?

Alignment is the question DMARC adds on top of SPF and DKIM: does the domain that was authenticated match the domain in the From: header — the address the recipient is actually shown?

It is a different question from “did SPF pass”, and it is the one that catches people out. A message can pass SPF, pass DKIM, and fail DMARC.

Why passing is not enough

Each check authenticates an identity, and neither of them is the visible one.

• SPF authenticates the envelope sender (Return-Path / MAIL FROM) — where bounces go. Not displayed.
• DKIM authenticates the signing domain (d= in the signature) — whoever took responsibility for the message. Not displayed.
• The recipient sees the From: header, and neither check looks at it.

So:

Return-Path: bounces@mail.provider.net     ← SPF authenticates this
DKIM d=:     provider.net                  ← DKIM authenticates this
From:        noreply@yourapp.com           ← the recipient sees this

SPF   pass   (provider.net authorised the IP)
DKIM  pass   (signature valid for provider.net)
DMARC fail   (neither authenticated domain matches yourapp.com)

Two green ticks, and the check that matters fails. This is the default state at a great many providers, because aligning the return path means per-customer DNS instead of one shared bounce domain, and shared is cheaper to operate.

DMARC passes if either SPF or DKIM aligns. Only one is needed. Both failing is what produces a DMARC failure.

Relaxed and strict

Set with aspf= and adkim= in the DMARC record.

Relaxed (r, the default) — the organizational domains must match. Subdomains count:

Strict (s) — the domains must match exactly. mail.yourapp.com no longer aligns with yourapp.com.

Relaxed is right for almost everyone. Strict is for domains where subdomain delegation is itself a risk you are managing deliberately, and it will break any sending you have not accounted for.

How to fix a failure

Read the Authentication-Results header of a message that actually arrived:

Authentication-Results: mx.google.com;
  spf=pass   smtp.mailfrom=bounces@mail.provider.net;
  dkim=pass  header.i=@provider.net;
  dmarc=fail (p=NONE) header.from=yourapp.com

The last line names the domain DMARC evaluated: header.from=yourapp.com. Compare it against smtp.mailfrom and header.i. If neither is your domain, nothing is aligned, and the fix is one of two things:

Align DKIM. Have the provider sign with d=yourapp.com rather than their own domain. This usually means publishing a CNAME or TXT record for a selector they give you. It is the easier of the two, it survives forwarding, and for most senders it is the right one to fix first.

Align SPF. Point a subdomain of yours at the provider’s bounce infrastructure — a custom Return-Path such as bounces.yourapp.com — so the envelope sender is under your organizational domain. Whether this is available depends entirely on the provider.

Do both if you can. Either alone passes DMARC; having both means one can break without the message failing.

The one check to run

If you test a single thing about your outgoing mail, test alignment rather than SPF and DKIM separately. Send a message to an address you can read raw headers on, find the dmarc= verdict, and confirm the domain it names is yours.

Pharos enforces alignment at send time: a sending domain that would fail cannot send through it, which makes this failure mode impossible rather than detectable. The deliverability page explains what that does and does not buy you.