Alignment, the idea that makes DMARC work

Here is the problem alignment solves. An attacker registers a domain they control, publishes flawless SPF and DKIM records for it, and sends you a message. Both checks pass, because the attacker is authenticating honestly as themselves. The From header displays your bank.

Every check passed. Nothing about either result said anything about the address on screen. Alignment is the requirement that closes that gap: the domain that authenticated must be the domain the recipient sees.

Two alignment checks

• SPF alignment compares the envelope sender (MAIL FROM) domain with the From header domain.
• DKIM alignment compares the signature's d= domain with the From header domain.

DMARC needs only one of them to both pass and align. A message can fail SPF entirely and still pass DMARC on an aligned DKIM signature, which is exactly what happens to legitimate forwarded mail.

Relaxed and strict

Relaxed mode, the default for both checks, compares organisational domains: the registrable domain plus its public suffix. Under relaxed alignment, mail.example.com and example.com share the organisational domain example.com, so they align. Strict mode requires an exact string match, subdomain included.

From:      invoices@example.com
MAIL FROM: bounce@mail.example.com   -> aligned (same org domain)
DKIM d=    example.com               -> aligned

From:      news@example.com
MAIL FROM: bounces@vendor.example.net   -> NOT aligned
DKIM d=    vendor.example.net           -> NOT aligned
SPF: pass   DKIM: pass   DMARC: FAIL

That second block is the single most common cause of DMARC failures on mail you actually sent. Both underlying checks pass, the message looks fine in every respect, and DMARC counts it as a failure because neither authenticated identity is yours.

Fixing an unaligned vendor

The fix is always the same in shape: make the vendor authenticate as you rather than as themselves. Every serious sending platform supports this, usually branded as custom DKIM, branded sending, or a custom return path.

1. Complete the vendor's custom DKIM setup. This publishes a key under your domain, typically as a CNAME, and makes them sign with d= set to your domain. This alone is usually enough, since DKIM alignment satisfies DMARC on its own.
2. If they also offer a custom return path or custom bounce domain, configure it. That aligns SPF too, giving you two independent paths to a DMARC pass instead of one.
3. Send a test message and read the headers. Confirm d= is your domain, not theirs.

Diagnosing it from the headers

You do not need reports to check a single message. Every major receiver stamps an Authentication-Results header on arrival, and it names the domains that were checked, which is exactly what alignment turns on.

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=bounces@vendor.example.net;
  dkim=pass header.d=vendor.example.net;
  dmarc=fail header.from=example.com

Read it from the bottom up. header.from is the domain your recipient sees. smtp.mailfrom is what SPF checked, and header.d is what DKIM signed as. Here both checks passed against vendor.example.net while the From header says example.com, so dmarc=fail is correct and the vendor needs custom DKIM configured.

Send yourself a message through every service that mails on your behalf and read this header on each. It takes an afternoon and gives you the same answer your first month of reports would, for the senders you already know about. Pasting raw headers into the header analyzer will lay the results out if you would rather not read them by eye.

Should you use strict alignment?

Rarely. Strict mode blocks a narrow class of subdomain abuse, and in exchange it breaks any sender that uses a subdomain for bounces or signing, which is most bulk senders. Setting aspf=s commonly breaks mail that was working fine, because providers routinely bounce from a subdomain of your domain.

Leave both at relaxed unless you have a specific threat in mind and reports proving nothing will break. If you do want to experiment, change one at a time and watch a full reporting cycle before changing the other.

Alignment and subdomains

Relaxed alignment operates on the organisational domain, which is why a message from mail.example.com aligns with example.com. It is worth being clear that this works through the public suffix list rather than simple string suffixes: example.co.uk and other.co.uk do not align, because co.uk is a public suffix and the organisational domains differ.

Note also that alignment and policy are separate questions. A subdomain with no DMARC record of its own inherits policy from the organisational domain, which the sp= tag controls.

Why this blocks enforcement

Alignment failures are the most common reason a domain cannot get to p=reject. The mail is legitimate, the team can see it is legitimate, and the reports keep counting it as a failure. Rejecting at that point would block your own invoices.

So the practical route to enforcement is: publish p=none, read reports until every significant source is identified, fix alignment on each one, and only then tighten. The staged rollout exists precisely to give you time to work through that list.