DMARC alignment, in plain English

The four words people conflate

DMARC reports talk about four things that sound similar but are not the same:

• SPF authentication — did the sending IP show up in the Return-Path: domain's SPF record?
• SPF alignment — does the Return-Path: domain match the From: domain?
• DKIM authentication — does the message carry a valid DKIM signature?
• DKIM alignment — is the domain in that signature the same as the From: domain?

DMARC requires at least one of authentication + alignment to pass. Either SPF passes and aligns, or DKIM passes and aligns. You don't need both. But you need one to do both jobs — and a lot of mail does only one of them.

The classic "SPF passed but DMARC failed" puzzle

You see this in DMARC reports all the time, especially from senders like Mailchimp, SendGrid, or your support-desk vendor. The report shows:

SPF result: pass
DKIM result: pass
DMARC result: fail

How can a message pass both SPF and DKIM and still fail DMARC?

Because pass in the report rows means "authentication passed" — the cryptographic check worked. It doesn't say anything about alignment. When the sender is an ESP relaying for you, the picture is usually:

• The From: header says noreply@acme.com.
• The Return-Path: says bounces@mcsv.net (Mailchimp's bounce-handling domain).
• The DKIM signature is signed by d=mcsv.net (Mailchimp's signing domain).

Both checks pass. But neither one's domain matches your From: — so from DMARC's perspective, neither one is aligned with you. From a cryptographic standpoint Mailchimp authenticated themselves; they didn't authenticate you.

Why DMARC requires alignment specifically

DMARC's job is to stop spoofing of From: headers — that's the only domain end-recipients ever see. SPF and DKIM both predate DMARC, and both can pass without saying anything about From:. DMARC's contribution is gluing identity (the From: domain) to authentication (SPF or DKIM results) by requiring the authenticated identifier to match the identifier the recipient sees.

Without alignment, a spammer could buy any sketchy domain, set up SPF and DKIM correctly for that sketchy domain, and then send mail with a forged From: ceo@yourcompany.com — both authentication checks would pass (because they're checking the sketchy domain) and DMARC would have nothing to say about it. Alignment closes that loophole.

How to actually fix unaligned ESPs

You have two paths. Most established ESPs support both; pick whichever is simpler in their admin UI.

Path A: Custom return-path (fixes SPF alignment)

Most ESPs let you set up a custom bounce domain — bounce.acme.com or em.acme.com — that they configure to handle bounces for you. The ESP gives you a CNAME to publish, you publish it, and now the Return-Path: on outbound mail is your domain instead of theirs. SPF evaluates against acme.com (or its subdomain), and SPF alignment suddenly works.

This is the right answer if SPF authentication was already passing — you're just moving the alignment domain.

Path B: Custom DKIM signing (fixes DKIM alignment)

Better path for most ESPs. Instead of signing with their own domain, the ESP signs your outbound mail with a key tied to your domain. You publish the public key in DNS at k1._domainkey.acme.com (the selector name varies by ESP). Now the DKIM signature has d=acme.com — same as your From: — and DKIM alignment works.

DKIM alignment is usually the more reliable fix because it follows the message end-to-end. SPF alignment only works if the message arrives at the receiver via the original return-path; if there's mailing-list forwarding or any other relay, SPF often breaks but DKIM survives.

Strict vs relaxed alignment

DMARC has two alignment modes, controlled by adkim= (DKIM alignment) and aspf= (SPF alignment) in your DMARC record:

• Relaxed (the default): subdomains of your From: domain count as aligned. From: ceo@acme.com aligns with d=mail.acme.com in DKIM.
• Strict: only an exact match counts as aligned. From: ceo@acme.com must align with d=acme.com exactly. d=mail.acme.com would fail.

Default to relaxed — it's the path of least surprise and matches how most ESPs configure custom signing. Switch to strict only if you have a specific reason (e.g. forensic-grade alignment for legal/compliance domains). Watch your reports carefully after the switch — strict can catch legitimate mail you'd missed.

Why this matters during ramp-up

At p=none (monitor only), unaligned senders don't break anything — you just see them in reports. The danger is when you progress to p=quarantine or p=reject without first fixing them. Suddenly Mailchimp's marketing blasts go to spam (or worse, get bounced) because their signature was never aligned with your domain — and the user complaints start.

Before you ramp past p=none, audit your DMARC reports for consistently-failing senders, identify the legitimate ones, and walk through Path A or Path B for each before turning enforcement on. Our progression playbook goes into the ramp itself in detail.

Related

• What is DMARC? — the 5-minute primer.
• Progressing past p=none safely — the 4-week enforcement ramp.
• DKIM verifier — check your DKIM selectors against ~25 common ESPs.
• SPF tester — count your SPF lookups against the RFC 7208 cap.
• DMARC audit — full plain-English audit of any domain.