Difficulties with e-mail forwarding

There are some additional details when an e-mail forwarder is involved. Forwarders perform a useful service in allowing you to have one simple permanent address, even if you change jobs or ISPs. List servers perform a similar function, forwarding e-mail to many receivers on behalf of one sender. Forwarders pose no problem for an end-to-end authentication method like DKIM and DomainKeys, as long as the signed message is not modified (some lists do this).

CSV limits its focus to one-hop authentications. SPF and SenderID have in essence the same limitation, they don't work directly behind the "border" ( MX ) of the receiver. For SPF forwarders to third parties could rewrite the Return-Path (MAIL FROM) in a similar way like mailing lists. This approach emulates the SMTP behaviour before RFC 1123 deprecated source routes; for a technical explanation see SRS.

For SenderID, forwarders to third parties and mailing lists are asked to add a Sender: or Resent-Sender: header. For many mailing lists, the former is already the case, but other forwarders avoid any modifications of the mail in addition to the mandatory Received-timestamp line.


Use of a forwarder prevents the receiver from directly seeing the sender's IP address. The incoming IP packets have only the forwarder's IP address. Two solutions are possible if one can trust all forwarders. Either one trusts the forwarder to authenticate the sender, or one trusts the forwarder to at least accurately record the incoming IP address and pass it on, so one can do their own authentication.

The situation gets complicated when there is more than one forwarder. A sender can explicitly authorize a forwarder to send on its behalf, in effect extending its boundary to the public Internet. A receiver can trust a forwarder that it pays to handle e-mail, in effect designating a new receiver. There may be additional "MTA relays" in the middle, however. These are sometimes used for administrative control, traffic aggregation, and routing control. All it takes is one broken link in the chain-of-trust from sender to receiver, and it is no longer possible to authenticate the sender.

Forwarders have one other responsibility, and that is to route Bounce messages (a.k.a. DSNs) in case the forwarding fails (or if it is requested anyway). E-mail forwarding is different from remailing when it comes to which address should receive DSNs. Spam bounces should not be sent to any address that may be forged. These bounces may go back by the same path they came, if that path has been authenticated.