tmailrPrivacy
Why your alias provider should not rewrite your mail
15 July 2026 · 2 min read · TMailr
An alias forwards a message from one address to another. The question that separates a good service from a bad one is what it does to the message in between, and the correct answer is nothing at all.
The signature is the thing being protected
The sender signed their message with DKIM, over the body and a list of headers. A receiver recomputes that signature and either it matches or it does not. Nothing partial: change one byte of the signed material and dkim=fail.
For forwarded mail this matters more than for anything else, because SPF is already gone. The forwarder is not on the author’s list of permitted senders and never will be, so DKIM is the only leg left that can pass DMARC. A forwarder that breaks it has removed the last thing tying the message to whoever wrote it.
Everything on this list breaks it
- Adding a footer saying the message was forwarded.
- Rewriting links for tracking or for safety scanning.
- Converting HTML to text, or re-encoding either.
- Adding a prefix to the subject.
- Adding, reordering or reformatting any header the signature covered.
- Stripping an attachment.
Each is individually defensible. Each turns a message that authenticates into one that does not, at which point it is judged purely on the forwarder’s reputation, shared with everybody else using that service.
The attachment case, which looks like an exception
Removing a dangerous attachment seems obviously worth it. It is not, because you cannot remove a part without invalidating the signature: you have made the message unverifiable in order to deliver it.
Refusing the whole message is the better trade. The sender is told during the SMTP conversation, the recipient sees a record of what was held back, and every message that does arrive still carries an intact signature. We refuse rather than strip for exactly this reason.
What has to change, and how
One thing legitimately changes: the envelope sender, rewritten to the forwarder’s own bounce address so SPF passes on the outbound leg and bounces come back somewhere useful. That is envelope, not message, so the signature is untouched.
Trace headers can be added, because they were not in the original signature and adding a header the signature does not cover does not invalidate it. That is how a forwarder can mark its own work without damaging anything.
How to tell what yours does
Send a signed message through your alias to somewhere you can inspect, and read Authentication-Results at the far end. dkim=pass means the relay is byte-faithful. dkim=fail means something rewrote it, and the footer at the bottom of the message usually names the culprit.
Then look at the message itself. If anything has been added to the body, the signature was broken by definition, and no amount of configuration on your side will put it back.
More on privacy
