tmailrDeliverability
Why forwarded mail lands in spam
28 July 2026 · 3 min read · TMailr
Forwarding is the oldest trick in email and one of the most reliable ways to make good mail look bad. The mechanics are simple and the consequences are not obvious until your forwarded mail starts arriving in spam and the original does not.
The forwarder becomes the sender
When a message is forwarded, a new SMTP conversation opens from the forwarding server to the destination. As far as the destination is concerned, the forwarder sent it. The connecting IP belongs to the forwarder, so SPF is evaluated against the forwarder, not the author.
If the forwarder keeps the original envelope sender, SPF fails outright: the forwarder is not on the author’s list of permitted servers, and never will be. That failure is not a bug in the forwarder, it is SPF working exactly as designed on a message it was never designed to handle.
The fix is to rewrite the envelope sender to an address the forwarder controls, so SPF is evaluated against a domain that does authorise it. That is what a well-behaved forwarder does, and it has a consequence: bounces now come back to the forwarder, which has to work out what to do with them.
DKIM is what carries the message through
With SPF necessarily broken, DKIM is the only thing left that can tie the message to its author, and DMARC accepts either. So a forwarded message that still has a valid DKIM signature passes DMARC on the DKIM leg and arrives looking legitimate.
Which means the forwarder’s one real obligation is to not touch the signed parts. That sounds easy and is where most forwarders fail. Anything that alters the body or a signed header invalidates the signature:
- Appending a footer saying the message was forwarded.
- Rewriting links for click tracking or safety scanning.
- Converting HTML to plain text, or re-encoding either.
- Adding, reordering or reformatting a header that was in the signature’s h= list.
- Rewriting the Subject to add a prefix.
Each is individually defensible and each turns dkim=pass into dkim=fail, at which point the message has no passing authentication at all and is being judged purely on the forwarder’s reputation.
Reputation you did not ask for
Once the destination is judging the forwarder rather than the author, everyone forwarding through the same service shares one reputation. A forwarder relaying somebody’s spam and your invoices from the same IP is going to hurt your invoices, and there is nothing you can do about it from your side.
This is the argument for forwarders that refuse things. Refusing to relay a message with an executable attachment, or one that is itself a bounce, or one that has already been through the same forwarder, is not fussiness. It is the only lever a forwarder has over the reputation everyone using it depends on.
What good looks like
- The original bytes are relayed unchanged, so the author’s DKIM signature still validates.
- The envelope sender is rewritten to the forwarder’s own bounce address.
- That bounce address identifies which forward failed, so a rejecting destination can be noticed rather than guessed at.
- Loops are detected and stopped rather than bounced back and forth.
- Automatic messages are not forwarded onward, because a bounce chasing a bounce never ends.
How to tell which one you have
Forward a message to an address you can inspect and read the Authentication-Results header at the far end. If dkim=pass survived, your forwarder is byte-faithful. If it says fail, something in the path rewrote the message, and the footer at the bottom usually tells you who.
Then look at whether the body came through untouched. A forwarder that has added anything to the message has, by definition, broken the signature, and no amount of SPF or DMARC configuration on your side will put it back.
More on deliverability
