DMARC Alignment: Relaxed vs Strict, and Why Forwarding Breaks It
A message can pass SPF and pass DKIM and still fail DMARC. Here's the alignment mechanics behind that paradox, what relaxed and strict actually change in the domain comparison, and why forwarding collapses your DMARC fate down to DKIM-or-nothing.
EvilMail TeamJuly 17, 202611 min read
Here is a header block that stops most people cold:
SPF passed. DKIM passed. DMARC failed anyway, and because the policy is p=reject, that message just got bounced at the door. Nothing about the cryptography or the SPF lookup went wrong. What failed is alignment, and if you run mail long enough you learn that nearly every DMARC rejection of legitimate mail is an alignment failure, not an authentication failure.
DMARC is an alignment protocol wearing an authentication costume. SPF and DKIM answer "did *some* identity authenticate?" DMARC ignores that question and asks a sharper one: "did an authenticated identity match the domain the human actually sees?" That visible domain — the RFC5322.From header — is the only thing DMARC anchors to. Everything else is machinery in service of comparing against it.
DMARC Alignment Explained: Relaxed vs Strict SPF/DKIM & Forwarding — EvilMail Blog
The three domains DMARC actually compares
Every message carries three separate domain identities, and most operators conflate them:
`RFC5321.MailFrom` — the envelope sender, visible as the Return-Path / MAIL FROM in the SMTP transaction. This is what SPF checks. The recipient never sees it in their client.
The DKIM `d=` domain — whatever domain signed the message, taken from the d= tag inside the DKIM-Signature. This is what the DKIM signature validates against. It has nothing inherently to do with the From header.
`RFC5322.From` — the From: header address your recipient reads in their mail client. This is the DMARC anchor.
SPF and DKIM are, by design, blind to the From header. SPF validates a return path; DKIM validates whatever d= a signer chose to insert. An attacker can send from [email protected] with a valid SPF record and a valid DKIM signature over d=totally-legit-spammer.net, and stamp From: [email protected] in the header. Both checks pass. The user sees the bank. That gap — between what authenticates and what displays — is precisely the hole DMARC was built to close.
That last box is the whole rule. DMARC passes if at least one of {SPF-aligned-pass, DKIM-aligned-pass} is true. It is a logical OR, not an AND. You do not need both to align — you need one. But "aligned" is doing enormous work in that sentence, and it is where relaxed and strict live.
Relaxed vs strict, precisely
DMARC (RFC 7489) gives you two independent knobs: adkim for DKIM alignment and aspf for SPF alignment. Each takes r (relaxed) or s (strict). Omit either tag and it defaults to r. They are independent — you can run adkim=s; aspf=r and many people should.
Relaxed means the Organizational Domain must match. The org domain is computed against the Public Suffix List (publicsuffix.org), not by naively stripping one label. Under relaxed, mail.marketing.evilmail.pro aligns with evilmail.pro because both reduce to the same org domain. This matters for domains under multi-label suffixes: evilmail.co.uk reduces to evilmail.co.uk, not co.uk, because the PSL knows co.uk is a public suffix.
Strict means the FQDN must match exactly. Under strict, mail.evilmail.pro does not align with evilmail.pro. Same registered domain, different fully-qualified name, no alignment.
From header
Authenticated domain
Relaxed
Strict
evilmail.pro
evilmail.pro
aligned
aligned
evilmail.pro
mail.evilmail.pro
aligned
fail
news.evilmail.pro
evilmail.pro
aligned
fail
evilmail.pro
evilmail.cloud
fail
fail
evilmail.co.uk
mx.evilmail.co.uk
aligned
fail
One extra wrinkle for SPF specifically: SPF alignment requires two conditions, not one. First, SPF itself must return pass on the MailFrom domain. Second, that MailFrom domain must align with the From domain. An SPF pass on a domain that doesn't match your From is worthless to DMARC — it's exactly the top row of the header we opened with.
Reading a DMARC evaluation by hand
Take a real marketing send through an ESP. The customer configured it correctly, which means the ESP signs with two DKIM keys:
DKIM-Signature d=esp-sender.net (the ESP's own signature)
DKIM-Signature d=evilmail.pro (a signature using a key you delegated to the ESP)
Now evaluate:
1.SPF passes — the sending IP is in esp-sender.net's SPF record. But it passes *on* esp-sender.net, which does not align with evilmail.pro. SPF alignment: fail.
2.ESP DKIM (d=esp-sender.net) passes cryptographically. But esp-sender.net ≠ evilmail.pro. That signature's alignment: fail.
3.Customer DKIM (d=evilmail.pro) passes cryptographically *and* aligns with the From domain. Aligned pass.
The OR rule fires on step 3. DMARC passes on the strength of that one aligned signature, and neither SPF nor the ESP's own DKIM contributed anything. This is the entire reason you sign with your own domain at your ESP — it's the only identity that survives to DMARC. Skip that delegated key and the message authenticates beautifully while failing DMARC completely.
Why forwarding breaks it
Forwarding is the canonical DMARC breaker, and the mechanics are worth internalizing because p=reject plus forwarding is the single most common way operators bounce their own legitimate mail.
When a .forward file, a Sieve redirect, or a Mailman list re-sends your message, the forwarder transmits it from its own IP with its own SMTP transaction. The receiving MX now evaluates SPF against the forwarder's connecting IP versus *your* domain's SPF record — which of course doesn't list the university's or the list server's IP. SPF fails. Even when the forwarder deploys SRS (Sender Rewriting Scheme) and rewrites the envelope to its own domain so SPF *passes*, it passes on the forwarder's domain and still doesn't align with your From. Either way, SPF alignment is dead on a forwarded message.
So the message's entire DMARC fate now rests on DKIM. And DKIM is fragile across a hop in one specific way: the signature covers a hash of the headers and body. Anything that mutates signed content invalidates it. Forwarders love to mutate content:
Mailman and other list managers inject a footer ("To unsubscribe...") into the body.
Lists prepend a subject tag like [dev-list] to a signed Subject: header.
Gateways re-encode MIME, convert 8bit to quoted-printable, or rewrap long lines.
Any one of those changes the signed hash, dkim=fail follows, and now nothing is aligned. SPF alignment was already gone. DMARC fails. Your p=reject policy instructs the final MX to reject, and a subscriber's legitimate forwarded copy vanishes.
Two mitigations get confused constantly. SRS is a forwarder-side band-aid for SPF: it rewrites the envelope so the *forwarder's* SPF passes and the message doesn't get rejected as a forgery by SPF-only receivers. SRS does nothing for DMARC, because it rewrites the envelope, not the From header — alignment is untouched. ARC (Authenticated Received Chain, RFC 8617) is the real fix: the forwarder adds ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers that cryptographically vouch for the authentication results *as they were before the hop*. A downstream receiver that trusts the forwarder can honor that sealed chain and pass DMARC even though SPF and DKIM broke in transit. Trust is the receiver's call — ARC is a claim, not a guarantee.
Choosing your alignment mode without self-sabotage
Default to relaxed for both unless you have a concrete, named reason to go strict.
Strict aspf/adkim buys you exactly one thing: protection against a hostile or compromised subdomain under your org domain signing mail that appears to come from your bare domain. That is a real threat for some organizations. But the cost is that any legitimate subdomain sender, or any ESP that signs with an org-level d=, stops aligning — and you'll spend weeks chasing phantom failures in your reports.
The pragmatic posture for most senders in 2026, now that Gmail and Yahoo's bulk-sender rules (5,000+/day) have made DMARC alignment effectively mandatory:
Relaxed alignment on both tags.
A well-scoped SPF record that doesn't over-include third parties.
DKIM signing with a `d=` that shares your organizational domain — delegated selectors at every ESP, never relying on the ESP's own d=.
Strict `adkim` only if you've audited every legitimate stream and confirmed each one signs with an exact-FQDN key you control.
Never deploy strict while using ESPs unless you've explicitly verified their signing domain, and roll out policy the boring way: p=none while you collect aggregate (rua) reports → confirm every legitimate stream shows an aligned pass → p=quarantine with a pct ramp → p=reject.
The record and how to verify
A production DMARC record with alignment spelled out:
fo=1 requests a failure report whenever *any* mechanism fails to produce an aligned pass, not only when everything fails — the most useful setting while debugging. Inspect your records from the command line:
bash
# The DMARC policy itself
dig +short TXT _dmarc.evilmail.pro
# SPF record on the org domain
dig +short TXT evilmail.pro | grep -i spf
# A specific DKIM selector's public key
dig +short TXT selector1._domainkey.evilmail.pro
In an aggregate report, the truth is in two blocks per record row. auth_results tells you whether SPF and DKIM *authenticated* and on which domain; policy_evaluated tells you the *aligned* result (spf and dkim there are the alignment verdicts DMARC acted on). When auth_results shows pass but policy_evaluated shows fail, you're looking at an alignment failure — same signature as the header we opened with.
Operator checklist:
Confirm your ESP signs mail with a delegated DKIM key under your org domain, not just its own d=.
Verify Return-Path alignment on your own outbound; fix it before blaming forwarders.
Keep aspf=r unless a subdomain threat model demands strict.
Only set adkim=s after auditing every legitimate signer.
Publish rua and read reports for at least two weeks at p=none before tightening.
Distinguish auth_results (authentication) from policy_evaluated (alignment) in every report.
Deploy ARC on your own forwarders and mailing lists so downstream receivers can trust broken hops.
Ramp policy none → quarantine (pct) → reject; never jump straight to reject.
Treat spf=pass dkim=pass dmarc=fail as the fingerprint of an alignment problem, never an authentication one.
If you take one thing from this: forwarding plus p=reject is the number-one self-inflicted deliverability wound in production mail. Your alumni forwarders, your mailing lists, your "send to my other address" rules — every one of them strips SPF alignment and gambles the whole message on a DKIM signature that a footer injection will happily shred. Ship ARC, keep alignment relaxed, sign with your own domain everywhere, and only then turn the policy up.
