Alignment: why passing SPF and DKIM can still fail DMARC

Alignment is DMARC's requirement that the domain which passed SPF or DKIM match the domain in the From header your reader sees. It is the single most misunderstood idea in email authentication, and the gap it creates is brutal in practice: a message can pass SPF, pass DKIM, show green checkmarks in every testing tool, and still fail DMARC, because both passes belong to your email tool's domain instead of yours. If you learn one lesson in this module cold, make it this one.

Three domains, one message

Every authenticated message has three domains in play, and alignment is the question of whether they agree:

1. The visible From domain, RFC5322.From, the one displayed in the inbox. This is DMARC's anchor.
2. The envelope sender domain, RFC5321.MailFrom, visible as Return-Path in delivered mail. This is what SPF evaluates.
3. The DKIM d= domain, named inside the signature. This is what DKIM identifies.

SPF and DKIM each produce a pass for their own domain, numbers 2 and 3. DMARC then asks: does either passing domain align with number 1? One yes is a DMARC pass. Two nos is a fail, regardless of how good those individual passes looked.

Relaxed and strict

Alignment comes in two modes, set per mechanism in your DMARC record by the aspf= tag (for SPF) and the adkim= tag (for DKIM).

Relaxed mode, the default for both, requires the two domains to share the same organizational domain. The organizational domain is, roughly, the part you registered: for bounce.mail.example.com it is example.com. (Receivers work this out using the public suffix list, which is why example.co.uk behaves like the registrable unit rather than co.uk.) Under relaxed alignment, a Return-Path at bounce.example.com aligns with a From at example.com. Subdomains count as family.

Strict mode, aspf=s or adkim=s, requires an exact match. bounce.example.com no longer aligns with example.com; only example.com itself does.

Almost everyone should run relaxed, and the defaults quietly agree. Legitimate setups use subdomains constantly (dedicated bounce subdomains, send. subdomains for ESPs), and strict mode turns each of those into a fail. Strict exists for organizations that want subdomain-level compartmentalization and know exactly why. If you didn't set adkim=s on purpose, you shouldn't have it.

A message that aligns

Concrete headers, using a domain you can imagine as your own. Your newsletter goes out through an ESP where you completed the custom-domain setup:

From: hello@example.com
Return-Path: <bounces@send.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

Walk the verdict. SPF evaluates send.example.com, the ESP's servers are authorized in that subdomain's record, pass. Is send.example.com aligned with example.com? Under relaxed mode, yes, same organizational domain. DKIM verifies against the key at k1._domainkey.example.com, pass, and d=example.com matches the From exactly, so it aligns even under strict. DMARC needed one aligned pass and got two. This message is fully yours, provably, and your domain collects the reputation for it.

A message that passes everything and aligns nothing

Same newsletter, same ESP, but the custom-domain setup was never done. The ESP falls back to its own infrastructure:

From: hello@example.com
Return-Path: <b-8231@bounce.espmail.net>
DKIM-Signature: v=1; a=rsa-sha256; d=espmail.net; s=s1; ...

SPF evaluates bounce.espmail.net. The ESP wrote that record, their server is in it, pass. DKIM verifies with the key at s1._domainkey.espmail.net, which the ESP hosts, pass. Two clean passes, and every basic header checker will show them proudly.

Now DMARC. Does bounce.espmail.net align with example.com? No, different organizational domains entirely. Does d=espmail.net align with example.com? No. DMARC: fail. If example.com publishes p=quarantine, this newsletter, the real one, written by you, sent by the tool you pay for, lands in spam on your own policy's orders.

Read that example twice, because it is the trap. The ESP's default configuration authenticates the ESP. Nothing in it authenticates you.

Why ESPs default to this

There's no malice in it. An ESP can make mail authenticate out of the box only by using domains it controls: its own bounce domain for SPF, its own d= for DKIM. That works instantly for every customer with zero DNS access. Fine, until the customer's domain publishes a DMARC policy with teeth, at which point the default silently stops being good enough.

A sourced example from our own checker table. Kit's most common real-world failure, the one we wrote into our Kit checker's verdict copy, is exactly this: the Verified Sending Domain setup was never completed, so Kit sends from its shared domain, and a DMARC policy on the customer's own domain doesn't cover those emails. The sender did nothing wrong by their own lights. They finished the signup, mail flowed, opens came in. The unfinished optional-looking DNS step only becomes visible as a problem when DMARC enforcement meets it, sometimes years later.

And this half-configured state is stable, which is what makes it dangerous. Nothing about it errors. Mail delivers for months on the shared domain, right up until the domain owner (or the 2024 bulk sender rules) tightens DMARC, and then placement falls off a cliff that was poured long before.

What a verified sending domain actually changes

Every serious ESP offers the fix under some name: verified sending domain, custom domain, domain authentication, branded sending. Strip the branding and it is two changes to which domains appear in your mail.

First, DKIM under your domain. You publish a selector record (usually a CNAME delegating to the ESP's key), and the ESP starts signing with d= set to your domain. In Kit's flow, that's the cka._domainkey CNAME. One aligned DKIM pass is already a DMARC pass, so this step alone usually gets you safe.

Second, a custom Return-Path, sometimes called a bounce domain or envelope domain. A record (Kit's flow uses a CNAME at ckespa) moves the envelope sender onto a subdomain of your domain, so SPF's pass starts aligning too. Now you have both legs, and forwarding that breaks SPF still leaves the aligned DKIM pass standing.

After those two records, rerun the mental check from the aligned example above: that's your mail now. Same ESP, same servers, same everything, except the passes finally point at you.

Two practical notes. The records prove which domains appear in the mail, and only a delivered message proves it end to end; a dashboard saying "verified" is the ESP's claim, and DNS can drift after the day you verified. And if your ESP put the whole arrangement on a subdomain like send.example.com, keep the layers straight: the records to verify now live on that subdomain (its SPF record, its selectors), while the policy judging the mail is still the DMARC record on your From domain, which needs no twin on the subdomain for this to work. The free health check reads the relevant records on any domain you give it, and the per-ESP checkers probe the exact record names your tool documents.

Alignment closes out the load-bearing half of the authentication module. What remains is the radar those aligned records feed, reading DMARC reports, and then the second shelf: MTA-STS, TLS-RPT, BIMI and ARC, each weighted honestly.

Terms from this lesson

• alignment - DMARC's requirement that the domain passing SPF or DKIM match the visible From domain; without it, a pass counts for nothing.
• relaxed alignment - the default mode: domains align if they share the same organizational domain, so subdomains count.
• strict alignment - the opt-in mode (aspf=s, adkim=s) requiring an exact domain match, with subdomains excluded.
• organizational domain - the registrable part of a hostname (example.com in bounce.mail.example.com), determined via the public suffix list.
• shared sending domain - the ESP-owned domain used for Return-Path and DKIM when a customer hasn't completed custom-domain setup; it authenticates the ESP, never the customer.
• verified sending domain - the ESP feature (names vary) that moves DKIM's d= and usually the Return-Path onto your domain so passes align.
• custom Return-Path - a bounce domain under your own domain, replacing the ESP's shared one so SPF's pass aligns with your From.

Check yourself

1. A message shows From: news@example.com, Return-Path on bounce.espmail.net (SPF pass), and a valid DKIM signature with d=espmail.net. What is the DMARC result for example.com?

Pass, because both SPF and DKIM passedPass, because ESPs are exempt from alignmentNeutral, pending the pct= tagFail, because neither passing domain aligns with example.com

2. Under relaxed alignment, does a Return-Path at send.example.com align with a From at example.com?

Yes, they share the organizational domain example.comNo, only exact matches alignOnly if aspf=s is setOnly if the subdomain has its own DMARC record

3. Why does an ESP's out-of-the-box configuration typically fail DMARC alignment for your domain?

ESPs skip DKIM signing by defaultShared infrastructure can't pass SPFThe default Return-Path and d= use the ESP's own domain, which authenticates them rather than youDMARC ignores mail sent through third parties

4. Which change alone is usually enough to make your ESP mail pass DMARC?

Adding the ESP's include to your SPF recordDKIM signing with d= set to your own domainSetting pct=100 in your DMARC recordSwitching your DMARC policy to p=none