DKIM alignment and forwarding

15 June 2026 · 10 min read

Why DKIM is the signal that survives the journey

Every email you send is supposed to travel from your server straight to your recipient's inbox. In practice it rarely does. It gets redirected by aliases, fanned out by mailing lists, scrubbed by security gateways, and relayed by intermediaries you never set up and cannot see. Each of those extra hops is a chance for authentication to break, and when it breaks on a domain protected by DMARC, the consequence can be a legitimate message landing in spam or being rejected outright.

There are only two mechanisms DMARC can use to authenticate a message: SPF and DKIM. Of the two, only one is built to survive that messy real-world journey. SPF is tied to the connecting server, so the moment a different server relays your mail, SPF for your domain stops working. DKIM is tied to the message itself, so it can pass through many hops and still verify at the far end. That difference is not a minor implementation detail. It is the single most important reason that any domain serious about reaching enforcement needs to lean on DKIM rather than SPF.

This article is about DKIM alignment specifically: what it is, how it differs from a plain DKIM pass, why a verified signature can still fail DMARC, and exactly how forwarders and mailing lists interact with it. If you want the broad picture of what happens to both mechanisms when mail is forwarded, the companion piece forwarding and DMARC covers that ground. Here we zoom in on DKIM and the alignment rules that decide whether a forwarded message protects your brand or quietly fails.

A plain DKIM pass is not the same as DKIM alignment

The most common misunderstanding about DKIM is that a valid signature is enough. It is not. DMARC asks a stricter question than "did the signature verify?". It asks "did a valid signature verify for the same domain the recipient sees in the From header?". Those are two different questions, and the gap between them is alignment.

To see why, you need to keep three domains separate in your head. The DMARC alignment explained guide walks through all three in detail; the short version is:

• The From header domain is what the human reads in their mail client, for example news@yourbrand.com. DMARC is anchored entirely to this domain.
• The Return-Path (envelope-from) domain is the bounce address used during the SMTP conversation. SPF authenticates this, never the From header.
• The DKIM signing domain is the d= tag inside the DKIM-Signature header. This is whatever domain cryptographically signed the message.

A DKIM signature authenticates the d= domain and nothing else. It says "the domain named in d= vouches for these bytes". It does not, on its own, say anything about the From header. DKIM alignment is the extra step DMARC adds: it compares the d= domain against the From header domain and only counts the signature if the two match under the alignment mode in force.

So a message can carry a perfectly valid, cryptographically sound DKIM signature and still fail DMARC, because the signing domain is not your domain. This happens constantly. An email platform signs your campaigns with its own domain, d=mailgun.org or d=sendgrid.net, the signature verifies flawlessly, but it verifies for the platform, not for yourbrand.com. DKIM passed. DKIM alignment did not. As far as DMARC is concerned, that signature does nothing for you.

You can inspect what a domain currently publishes and signs with the DKIM checker. If the d= you see there is not your own domain or a subdomain of it, you have a DKIM alignment problem waiting to surface the day you move past p=none.

How DKIM alignment is actually evaluated

When a receiver runs DMARC on an inbound message, the DKIM half of the evaluation works like this:

1. The receiver finds every DKIM-Signature header on the message. There can be more than one.
2. For each signature, it fetches the public key from DNS at <selector>._domainkey.<d-domain> and verifies the cryptographic signature against the signed headers and body.
3. For each signature that verifies, it checks whether the d= domain aligns with the From header domain.
4. If any verified signature aligns, DKIM passes for DMARC. One aligned, verified signature is enough.

That step 4 is important and often overlooked. A message can carry several signatures: one from your platform's domain that verifies but does not align, and one from your own domain that verifies and does align. DMARC only needs the aligned one. This is exactly why the fix for a non-aligning platform signature is usually not to remove the platform's signature but to add an aligned one. Most reputable email services let you do this through "DKIM authentication" or "custom domain" setup, where you publish a CNAME or TXT record so the platform can sign as d=yourbrand.com (or a subdomain) on your behalf. The DKIM product page covers how that signing is provisioned correctly.

Relaxed versus strict alignment

DMARC supports two alignment modes for DKIM, set by the adkim tag in your DMARC record.

• Relaxed alignment (adkim=r, the default) requires only that the d= domain and the From domain share the same organisational domain, also called the registrable domain. So d=mail.yourbrand.com aligns with a From of news@yourbrand.com, because both roll up to yourbrand.com. Subdomains are interchangeable in either direction.
• Strict alignment (adkim=s) requires the d= domain and the From domain to be an exact match. d=mail.yourbrand.com would not align with news@yourbrand.com under strict mode. They must be identical character for character.

For almost everyone, relaxed is the correct choice. Strict alignment buys you a marginal amount of extra precision and costs you a great deal of fragility, because email platforms routinely sign with a subdomain of your domain, and strict mode rejects that. Unless you have a specific, well-understood reason and you control every signing path exactly, leave adkim at relaxed. You can review or build a record that sets this sensibly with the DMARC generator.

A worked example makes the modes concrete. Suppose your From header is billing@yourbrand.com and the message carries a verified signature with d=eu.mailer.yourbrand.com.

• Under relaxed alignment, the receiver compares the organisational domains. Both reduce to yourbrand.com. They match. DKIM aligns, DMARC can pass.
• Under strict alignment, the receiver compares the full domains. eu.mailer.yourbrand.com is not equal to yourbrand.com. They do not match. DKIM does not align, and unless SPF saves the message, DMARC fails.

Same message, same valid signature, opposite outcome, decided entirely by one letter in your DMARC record.

Why DKIM is the forwarding-resilient signal

Now we reach the heart of the matter. DKIM is not just a way to authenticate mail. It is the only mechanism that can survive a forwarding hop with alignment intact, and understanding why tells you exactly where it will and will not hold up.

SPF authenticates the connecting IP address against the SPF record of the envelope-from domain. It is a question about the network: "is the server currently connecting allowed to send for this domain?". The instant a forwarder relays your message, the connecting IP belongs to the forwarder, not to you. SPF for your domain fails, or, if the forwarder uses Sender Rewriting Scheme to rewrite the envelope, SPF passes for the forwarder's domain instead, which then fails to align with your From header. Either way, after a forward, SPF cannot carry your DMARC authentication. The detailed mechanics are in forwarding and DMARC, but the conclusion is what matters here: SPF is structurally incapable of surviving a relay.

DKIM works on a completely different principle. It does not care about IP addresses, connection paths, or how many servers a message passes through. DKIM is a cryptographic signature over the message content itself. When your server sends the message, it hashes a set of chosen headers and the body, signs that hash with a private key, and stamps the result into a DKIM-Signature header that travels inside the message. Any receiver, however many hops later, fetches your public key from DNS, recomputes the hash, and checks the signature. Nothing about who relayed the message, or from which IP, affects that calculation.

So for plain forwarding that does not modify the message, the chain is clean:

1. Your server signs with d=yourbrand.com.
2. A forwarder accepts the message and re-sends it byte-for-byte to the final recipient.
3. The final receiver fetches your public key, recomputes the hash over the unchanged bytes, and the signature verifies.
4. Because the signature is for d=yourbrand.com, it aligns with the From header news@yourbrand.com.
5. DKIM passes and aligns. DMARC passes, despite the forward and despite SPF having broken on the relay hop.

This is precisely why DKIM is non-negotiable. A domain that relies on SPF alone will see legitimate forwarded mail fail DMARC the moment it reaches enforcement. A domain with correct, aligned DKIM signing rides through most forwards untouched. If you are planning the journey from p=none to p=reject, getting DKIM aligned on every legitimate sending stream is the work that makes the forwarded-mail failures disappear.

Where DKIM does break: message modification

DKIM survives forwarding only on one condition: nothing that was signed may change in transit. The signature covers a hash of the body and of specific named headers. If a single byte of the signed content is altered, the recomputed hash will not match and the signature fails. Plain relays preserve the bytes. Anything that edits the message does not.

This is exactly what makes mailing lists the hardest case in all of email authentication. A typical discussion list does several things that touch signed content:

• It adds a tag to the Subject, turning Quarterly numbers into [finance-list] Quarterly numbers. The Subject header is almost always signed, so this breaks the signature.
• It appends a footer to the body, usually unsubscribe links or list information. The body hash no longer matches, so the signature breaks.
• It may re-encode the body, convert HTML to multipart, or alter the MIME structure, all of which change the signed bytes.

Because lists break both SPF (different connecting IP) and DKIM (modified content), a list-distributed message arrives with neither mechanism able to authenticate for your domain. Under p=reject, a strict receiver can reject it. This is the well-known reason that well-run discussion lists rewrite the From header to their own domain, for example From: "Jane via finance-list" <finance-list@lists.example.org>, so that DMARC is evaluated against the list's domain rather than yours. It is a workaround for the fact that the list deliberately invalidated your signature. It is also why you sometimes see a c= canonicalisation choice mentioned in DKIM discussions: relaxed canonicalisation tolerates harmless whitespace and header-folding changes, but it does not tolerate added footers or subject tags. No canonicalisation setting can save a signature once real content has been edited.

There is a newer standard built specifically to repair this damage: ARC, the Authenticated Received Chain. When a list or forwarder participates in ARC, it records the authentication results it saw before it modified the message and seals that record cryptographically as the message moves on. A receiver that trusts the intermediary can then honour the original authentication even though SPF and DKIM now fail on the modified message. ARC does not change your DMARC record and it is not something you publish on your own domain; it is something intermediaries implement. Its adoption is growing but uneven, so you cannot assume every forwarder along a path supports it. It is a real and meaningful mitigation, not a complete solution.

What this means for your records and your reports

The practical takeaways follow directly from the mechanics above.

Sign everything with an aligned domain. Every legitimate stream that sends as your domain, marketing platform, invoicing system, helpdesk, transactional service, must apply a DKIM signature whose d= aligns with your From domain under relaxed mode. A platform signature using the platform's own domain verifies but does not protect you. Walk each sender and confirm aligned signing is enabled; the DKIM checker shows you what is actually published.

Keep adkim relaxed unless you have a precise reason not to. Strict alignment turns ordinary subdomain signing into a failure and is the wrong default for nearly every organisation.

Read forwarded-mail failures correctly. When your DMARC reports show failures from unfamiliar sources, separate the cases. A source where DKIM still aligns but SPF fails is almost always plain forwarding doing exactly what it should, and your DMARC is surviving on DKIM alone, which is the system working as designed. A source where both fail is usually a mailing list that modified the message, or a sender you have not yet set up aligned signing for. The first is harmless. The second needs action. The DMARC report analyzer helps you tell them apart by surfacing which mechanism aligned on each source, and ongoing monitoring tells you when a new unaligned source appears so you can fix it before raising your policy.

Do not raise your policy until DKIM alignment is solid. The single most common cause of a botched move to p=reject is a sending stream that was only ever passing on SPF, which then breaks the first time that mail is forwarded. If DKIM aligns on every legitimate source, forwarding stops being a threat to your delivery.

The bottom line

SPF is tied to the network path, so it cannot survive a relay. DKIM is tied to the message, so it can, and it carries your DMARC authentication across forwarding hops as long as the message content is not edited. That makes DKIM alignment the foundation that any domain heading for enforcement has to get right first. Plain forwarding preserves it; mailing lists that rewrite subjects and append footers break it, which is why they rewrite the From header and why ARC exists to paper over the gap.

If you want to see exactly which signatures a domain publishes and whether they will align, start with the free DKIM checker and the wider tools set. And if walking every sending stream, fixing alignment, and moving safely to p=reject without dropping a single legitimate forward sounds like more than you want to own in-house, that end-to-end work is precisely what our done-for-you DMARC service handles.