Deliverability
The forwarding problem
Having mail forwarded from your own old address is the most harmless thing in the world. It reliably destroys sender verification — and not through a fault, but because the procedure anchors itself to something that changes in the process.
What happens when mail is forwarded
Anna writes to Bert. Bert has his mail forwarded to another account. The forwarding server accepts the message and submits it afresh — at the final destination.
Why this is not a fault
SPF answers the question: is this machine allowed to submit in this name? At the second submission the machine is a different one, so the answer is correctly "no". The procedure does exactly what it is meant to.
The mistake is in the expectation. SPF checks a relationship between IP address and domain, and that relationship is bound to precisely one delivery step. It does not survive a second.
Why DKIM survives it
The signature travels inside the message. Whoever passes the message on passes the signature on with it, and at the destination it can be checked as before — regardless of how many stops it came through.
Which is precisely why DMARC does not demand both procedures but one of the two: on a forward, SPF falls and DKIM carries. A domain with a working signature survives forwarding; one with SPF alone does not.
This is the practical reason DKIM is not optional. Without a signature every forwarded message is one that fails — and forwards are far more common than senders suspect: old addresses, university accounts, shared mailboxes.
Where DKIM breaks too
The signature covers the content and selected header lines. Change anything in them and you invalidate it. Classic mailing lists do exactly that:
- a tag in the subject so you can recognise the list,
- a footer with unsubscribe instructions,
- conversion of HTML into plain text,
- removing or rewriting attachments.
Every one of those changes is well meant and breaks the signature. After that both SPF and DKIM fail — and a domain publishing a strict DMARC policy thereby ensures that its own users get thrown off mailing lists.
This collision happened visibly in 2014, when large providers set their policy to "reject" and mailing lists worldwide began ejecting their users. The lists' response was to rewrite the sender: messages have since often come from the list itself, with the original author surviving only in the display name.
Two attempts at repair
Rewrite the envelope. The forwarding server replaces the envelope sender with an address of its own that encodes who originally sent the message. SPF then matches it again, and bounces still find their way back. An established but never standardised procedure, which makes the addresses unsightly and declares the forwarder responsible for somebody else's mail.
Document the chain. The newer approach has every intermediate stop attach a signed note: "when I received this message, the checks were in order." The destination can follow the chain and trust a stop it trusts anyway.
Both are bolt-ons to bolt-ons. They work, and at the same time they show where this leads: surviving a forward now takes a fourth procedure on top of the three that were needed already.
What this says about the system
Forwarding is not a marginal case but one of the oldest functions there is — email has been passed along from the very beginning. That of all things it collides with the retrofitted security procedures is no coincidence.
Those procedures had to check properties the protocol never provided for, and therefore fell back on what was available: the IP address of the other party. That is a property of the transport, not of the message. Anything that changes the transport breaks it — and forwarding means changing the transport.