Email Authentication
What actually happens when SPF or DKIM fails, the policy tag reference, and the one detail — alignment — that trips up more setups than anything else.
7 min read
Email Authentication
7 min read
DMARC: the policy that ties SPF and DKIM together
What actually happens when SPF or DKIM fails, the policy tag reference, and the one detail — alignment — that trips up more setups than anything else.
What DMARC actually is
SPF and DKIM each answer a narrow question — is this server allowed to send, and was this message signed correctly. Neither one tells a receiving mailbox what to actually do when one of those checks fails, or lets the domain owner find out abuse is happening. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that closes that gap: it ties SPF and DKIM together, tells receiving servers what to do with mail that fails both, and asks for a report back so the domain owner can see what's really being sent in their name.
A DMARC record lives at a fixed location — a TXT record at _dmarc.yourdomain.com — and always opens with the version tag v=DMARC1, the same way SPF opens with v=spf1.
Alignment: the detail people miss
Here's a subtlety that trips a lot of people up: a message can technically pass SPF and pass DKIM, and still fail DMARC. That's because DMARC adds one more requirement called alignment — the domain that SPF or DKIM actually verified has to reasonably match the domain shown in the visible "From" address a recipient actually sees.
This exists specifically to close a loophole: without it, a message could be technically authenticated for some obscure sending domain while still displaying a completely different, more trustworthy-looking "From" address. Alignment mode is set independently for each protocol via the aspf= and adkim= tags: r for relaxed (a matching subdomain counts, e.g. mail.example.com aligns with example.com) or s for strict (only an exact domain match counts). Both default to relaxed if omitted.
The tags that decide enforcement
A DMARC record is built from tag=value pairs separated by semicolons. Here's what each one controls:
| Tag | What it controls |
|---|---|
v= | Version — always DMARC1, and must be the first tag. |
p= | Policy for the domain itself: none, quarantine, or reject. |
sp= | Policy for subdomains specifically — inherits p= if omitted. |
np= | Policy for addresses that don't exist at all (RFC 9091) — inherits sp= if omitted. |
pct= | What percentage (0–100) of failing mail the policy actually applies to. |
adkim= | DKIM alignment mode: r (relaxed, default) or s (strict). |
aspf= | SPF alignment mode: r (relaxed, default) or s (strict). |
The rollout path most companies follow
Very few companies flip straight to p=reject on day one, and for good reason — a mistake in the underlying SPF or DKIM setup could suddenly start blocking a company's own legitimate mail. The standard, careful approach is a gradual rollout: start with p=none (monitor only, blocks nothing), confirm every real sending source is passing cleanly, then move to p=quarantine, and finally p=reject once confident nothing legitimate is still failing.
More on Email Authentication
See what your DMARC policy is really enforcing
Aimly Audit reads your DMARC setup in full — policy, alignment, and enforcement level — and tells you exactly where the gaps are.