Forwarding is the most harmless arrangement a mailbox knows: mail arrives at address A and goes on to address B automatically. Since DMARC became widespread, that same arrangement regularly brings down messages that would have arrived without trouble on the direct route. The reason is not the forwarding itself. It is what the checking mechanisms actually check.
What technically happens when mail is forwarded
Forwarding is neither a copy nor a redirect. The forwarding server accepts the message in full and sends it again — from its own IP address, out of its own network. To the recipient at the end of the chain, the forwarder is the sending server. Nothing remains of the original connection except one extra Received: line in the header.
That removes a precondition SPF depends on entirely.
SPF does not survive forwarding
SPF asks: is this IP address allowed to send for this domain? The recipient sees the forwarder's IP as the sending address, but the envelope still names the original sender's domain. The forwarder's IP is of course not in the SPF record of a domain that is not theirs — why would it be. Result: fail.
This is not a configuration mistake. It is the unavoidable consequence of SPF checking a connection rather than a message. Every forward breaks SPF, without exception.
DKIM does survive — as long as nobody touches the text
DKIM works differently. The original sender computes a cryptographic signature over the message body and a selection of headers, and attaches it. That signature travels with the message. Whether it passed through an intermediate server is irrelevant — what is verified is the content, not the route.
That is why the ordinary case gets through despite broken SPF: DKIM passes, DKIM is aligned, and DMARC only requires that one of the two paths passes while aligned. How that comparison works is described separately.
Where the signature does break after all
The qualifier "as long as nobody touches the text" is not theoretical. Several common arrangements touch it:
- Mailing lists append a footer with unsubscribe information and put a tag such as
[internal]in front of the subject. Both fall inside the signed area. The signature is invalid afterwards. - Virus scanners and attachment filters replace attachments with notice text or append a scan result.
- Central disclaimers — the legal notice a gateway adds to every outgoing message — hit forwarded mail just the same.
- Re-encoding. A server rewriting a message from
8bittoquoted-printablechanges the text at byte level, even though the reader sees nothing of it.
Once DKIM is broken too, DMARC has no path left. The message is rejected or filed as spam — correctly, because from the recipient's point of view it arrived from an unauthorised source and was altered in transit.
SRS: the repair that moves the problem
Forwarders help themselves with the Sender Rewriting Scheme. The forwarder rewrites the envelope address to itself, turning anna@company.com into something like SRS0=abc=xy=company.com=anna@university.example. SPF then checks against university.example, the IP matches, and the result is pass again.
Except that DMARC gains nothing from it. The checked domain is now university.example, which agrees with the From: on company.com even less than before. SRS repairs the bounce path — those should land with the forwarder, not the original sender — but not the alignment. With SRS in place, DKIM alone still carries the result.
What ARC does
This is where the Authenticated Received Chain comes in. The idea is straightforward: if the forwarder already performed the check before it altered the message, it should pass that result on in an attested form.
Every ARC-capable intermediate server appends three headers:
| Header | Contents |
|---|---|
ARC-Authentication-Results | The result this server saw on receipt |
ARC-Message-Signature | A signature over the message in the state it arrived here |
ARC-Seal | A signature over the chain so far, so it cannot be rewritten afterwards |
The recipient at the end then sees: SPF and DKIM fail here, but the chain attests that both passed at the first recipient, and the chain itself is intact.
The decisive limitation
ARC proves nothing. It carries an assertion — and whether that assertion is worth anything depends entirely on whether the recipient believes the server that signed it. Any server can build an ARC chain claiming that everything passed.
ARC is therefore not something you switch on and it works. Large providers evaluate ARC chains from senders they know and have rated as reliable over time. For a freshly set up forwarder with no history, an ARC chain changes little at first. That is not a weakness of the mechanism but its design: ARC is a statement of trust, not a proof.
What this means in practice
If you have mail forwarded: expect messages from senders on p=reject to be lost in transit. The cleaner route is to let the destination mailbox collect the messages itself, by POP3 or IMAP import rather than by forwarding. Then there is no second send and nothing to break.
If you run a list: set From: to the list address and put the original address in Reply-To:. This is the solution the large list managers settled on. It looks inelegant, but it is the only one that works reliably once the list modifies the text.
If you send: make sure DKIM is aligned before you tighten the policy. A sender relying on SPF alone loses, at every forward of its messages, the one basis on which DMARC could still have passed.