What DMARC alignment actually breaks

There is a particular kind of email problem that survives every obvious fix. SPF passes. DKIM passes. You check both with an online tool and both come back green. And your invoices still land in spam, or bounce outright at Google.

The answer is almost always alignment, which is the part of DMARC that nobody configures on purpose because nobody knows it is there.

Three checks, not one

DMARC is not a third authentication method sitting alongside SPF and DKIM. It is a policy layered on top of them, and it asks a question neither of them asks on its own:

Does the domain that passed authentication match the domain in the From header the human actually sees?

That is alignment. SPF authenticates the envelope sender — the MAIL FROM, which your recipient never sees. DKIM authenticates whatever domain signed the message, which may not be yours. DMARC insists that at least one of those lines up with the visible From address.

Where it goes wrong

The common failure looks like this. You send invoices through a billing provider. They send as bounces@mail.billingprovider.com at the envelope level, with your From: accounts@yourcompany.com on the visible header. SPF passes — for billingprovider.com. DKIM passes — signed by billingprovider.com.

Neither aligns with yourcompany.com. DMARC fails. If your policy is p=reject, the mail is discarded, and the only evidence is a bounce your billing provider swallows.

Every checker that tests SPF and DKIM independently will tell you everything is fine, because independently, everything is.

Strict and relaxed

Alignment has two modes, and the defaults are doing you a favour you probably do not know about.

Relaxed (the default, aspf=r / adkim=r) accepts a subdomain. mail.yourcompany.com aligns with yourcompany.com. This is what makes delegated sending subdomains work at all.

Strict (aspf=s / adkim=s) requires an exact match. Nothing but yourcompany.com will do.

People turn on strict alignment because strict sounds safer, and then break every legitimate sender they had delegated a subdomain to. If you did not deliberately choose strict for a reason you can articulate, relaxed is correct.

The order things break in

The sequence we see most often, in order:

1. A domain publishes p=none and nothing changes, because none does nothing. Somebody reads the reports, sees passes, and concludes it is working.
2. The policy is raised to p=quarantine or p=reject.
3. Everything sent through the marketing platform, the CRM, the invoicing tool and the helpdesk stops arriving, because none of them were ever aligned.
4. Nobody connects the two, because step 2 happened weeks earlier.

The gap between changing a policy and noticing what it broke is exactly the gap monitoring is for.

What to check

• Does your visible From domain match what SPF authorised, or a subdomain of it?
• Is your DKIM signature d= your domain, or your provider's?
• Are you on strict alignment without meaning to be?
• Did your policy change recently, and did anything stop arriving afterwards?

The first three you can answer right now with a DNS lookup: your SPF record, your DMARC record and the aspf / adkim tags in it are all public TXT records.

IT Watch checks SPF, DKIM and DMARC on every monitored domain and alerts when a policy weakens, a record disappears, or an SPF record crosses the ten-lookup limit that silently voids it. It cannot tell you what your billing provider signs with — nothing outside your mail flow can — but it will tell you the day your policy changed, which is usually the day the trouble started.