SPF, DKIM and DMARC were designed for a simple path: the sender sends, the recipient receives. In reality many messages take a longer route. A user automatically forwards mail from an old address to a new mailbox; an association uses an alias that distributes messages to several people; a mailing list receives a message and sends it out again to all subscribers, perhaps adding a footer. Each intermediary can break one or more authentication mechanisms, and understanding how helps you avoid mistaking a routing problem for an attack.
What breaks with a simple forward
Imagine a message sent from example.com to an address on a university domain, which automatically forwards it to a personal mailbox at a large provider.
| Mechanism | After forwarding | Why |
|---|---|---|
| SPF | fails | the final provider sees the forwarding server's IP, not authorised by example.com |
| DKIM | usually passes | the signature travels with the message and stays valid if content doesn't change |
| DMARC | passes if DKIM is aligned | one aligned mechanism is enough |
This is the main reason aligned DKIM is essential: it is the only mechanism that survives a simple forward. A domain relying on SPF alone, with a strict DMARC policy, loses mail every time a recipient forwards its messages.
SRS: rewriting the envelope sender
The forwarding server has a problem of its own too. If it resends the message leaving the envelope sender unchanged, meaning the Return-Path at example.com, it is effectively sending mail on behalf of a domain that hasn't authorised it. The SPF check fails and, if the message cannot be delivered, the non-delivery notice goes back to the original sender from a server it doesn't know.
SRS, the Sender Rewriting Scheme, addresses this: the forwarding server rewrites the envelope sender with an address on its own domain, which contains the original address in encoded form plus a small signature with an expiry. A rewritten address looks like this:
SRS0=HHH=TT=example.com=mario@forward.example.net
That way SPF is checked against the forwarder's domain, which is authorised, and any bounces go back to the forwarding server, which knows how to route them to the original sender.
It is important to understand the limit: SRS makes SPF pass, but not aligned with From. For DMARC, then, SRS is not enough. It makes forwarding work without the intermediate server looking like a spammer, while alignment still depends on the original DKIM signature.
Mailing lists: when DKIM breaks too
Traditional mailing lists often modify the message: they add a subject prefix such as [members], or a footer with unsubscribe instructions. A single one of these changes is enough to invalidate the original DKIM signature. At that point SPF fails, DKIM fails, and a domain with p=reject sees its messages rejected by the list's recipients.
Many mailing list operators have adopted a practical solution: when the sender's domain has a strict DMARC policy, the list rewrites From with its own address, for example «Mario Rossi via Members», and puts the original address in Reply-To. The message thus becomes a message from the list, authenticated by the list's domain.
ARC: preserving the chain of trust
ARC, Authenticated Received Chain, tackles the problem from another angle. Each intermediary that supports it records, on receipt, the authentication results it observed in signed headers, before modifying or forwarding the message. The final recipient can then see that, when the message reached the list, SPF and DKIM were valid.
An ARC set is made up of three headers:
ARC-Authentication-Results: the results observed by that intermediary;ARC-Message-Signature: a message signature similar to DKIM;ARC-Seal: a signature that seals the chain of previous ARC headers.
ARC doesn't enforce anything. The recipient decides whether to trust the chain, and usually does so only if it knows and trusts the intermediaries that signed it. That is why ARC helps most when the intermediaries are large, recognised services.
What to do in practice
If you send:
- always sign with aligned DKIM, because that is what survives forwarding;
- in DMARC reports, don't mistake for spoofing the cases with failed SPF and valid DKIM from known forwarding servers;
- before moving to
p=reject, check whether employees or customers often write to mailing lists.
If you run a forwarding server or a list:
- enable SRS on forwards;
- avoid modifying the message when there is no need;
- rewrite From for domains with strict policies;
- sign with ARC, if your software supports it.
In short
- A simple forward breaks SPF but usually leaves DKIM valid.
- Aligned DKIM is the mechanism that lets DMARC survive forwarding.
- SRS rewrites the envelope sender and makes SPF pass, but not aligned.
- Mailing lists that modify messages break DKIM too and often rewrite From.
- ARC records authentication results along the route, for the benefit of the final recipient.
