Why forwarded mail lands in spam
28 July 2026 · 5 min read
When you forward a message, your server connects to the destination. SPF for the original sender lists their servers, not yours, so it fails. This is not a misconfiguration, it is arithmetic.
DKIM is the leg that can survive
If the forwarder passes the original bytes through untouched, the sender’s DKIM signature still verifies at the far end, DMARC passes on the DKIM leg, and the message is fine.
What breaks it
- Adding, removing or reordering a signed header.
- Rewriting the subject, for instance prefixing "Fwd:".
- Re-encoding the body, including converting 8-bit to quoted-printable.
- Adding a footer or a "scanned by" banner.
The one that caught us
Our own edge was inserting Date and Message-Id headers on messages that lacked them. A DKIM signature that covers a header which is absent binds it to stay absent, so adding one is a guaranteed break. Every affected message failed DKIM at the destination and we could not see why, because the message looked untouched.
If you run a forwarder, verify by sending a signed message through it and reading the Authentication-Results at the far end. Do not verify from a mailbox copy: the delivering server rewrites headers on storage, so a mailbox copy can fail a check the wire copy passed.
More on deliverability
SPF, DKIM and DMARC in plain English
Three records, three different jobs, and one relationship between them that explains almost every "why is my mail in spam" question.
MTA-STS and TLS-RPT, and when they are worth it
SMTP encryption is opportunistic by default, which means it is trivially downgraded. These two records are the fix, and one of them is nearly free.
Why a good mail server refuses instead of bouncing
Accepting a message you cannot deliver turns you into a spam cannon aimed at whoever was forged as the sender.