Re-visiting mail forwarding in a DMARC world

Forwarding email messages automatically can be tricky, as evidenced by recent conversation on the Mailop list. Email forwarding always breaks SPF authentication, and can easily break DKIM authentication if you modify any of the headers (and knowing which headers to stay away from can take a bit of work). But it's still doable if you take some care.

For me, this was a solved problem way back in 2015. In a nutshell, I have a script that will just grab the mail, rewrite the headers, send it on with my domain and IP as the sender (properly authenticated with DKIM and SPF). (Funny how I thought ARC would eventually help with email forwarding, but its use case seems perhaps only suited to the biggest providers.)

Last night, I updated my email forwarding script slightly and here's where you'll find the new version. It's still potentially pretty fragile in that it makes a lot of assumptions about the case sensitivity of headers, but in my (admittedly limited) use case, I actually haven't had any trouble with this in years. If you capture mail on a Linux server running postfix/Maildir set up, you could easily modify this script to edit the username, sender address, and recipient address, and drop it into your server to be called by cron periodically and it'll happily pick up mail, rewrite the headers to prevent DMARC-related forwarding issues, and then email it onward it on as directed.

Here's my top five best practices for email forwarding, if you want to do as I do:

1. Don't forward spam. Have a spam filter in front of this. Otherwise you'll damage your own IP/domain reputation. (Perhaps even have a separate sending IP address or at lease a separate DKIM domain for forwarding, if you're really worried about this.)
2. Send as you, not as them. The forwarded mail should have your from domain and you should sign the forwarded mail with your DKIM signature. I strip away the old signature (change the header name to X-DKIM-Signature) to fully remove it from the equation.
3. Make sure that the mail is fully authenticated. DKIM as noted above, sending IP address is in the SPF record of the return-path domain, domain has a DMARC record. All help with deliverability, directly or indirectly.
4. Rewrite the return-path address. Why? If you don't, you'll potentially run afoul of DMARC policy due to SPF authentication failure, and some of the forwarded mail will be rejected. (I don't recommend bothering that you configure it to play nice with Sender Rewriting Scheme as SRS is not widely implemented.)
5. Preserve the original from address in the reply-to field, if at all possible. That way users can still respond to the original sender, in spite of the DMARC-necessary header rewriting. This doesn't always work perfectly, as Gmail has some safeguards to prevent what they think may be funny business in from/reply-to combinations. But it generally works. (And Gmail's limitations aren't set in stone.)

And finally, keep in mind that email forwarding can be complex and imperfect. The biggest providers do it, but I think some of their success with it is due to bending email authentication checks and/or whitelisting forwarding IP addresses, which are options not always available to the hobbyist or smaller enterprise. That doesn't mean you can't or shouldn't do it, but like with so many things deliverability-related, it's important to "keep your nose clean" and do whatever you can to ensure that your IP address and domain are only sending (or in this case forwarding) wanted mail.

(And don't complain to me about how this "breaks email" -- no, email has changed, email has evolved, and the old ".forward" method of email forwarding hasn't been very compatible with most large mailbox providers for years. I strongly feel that you have to adapt and evolve if you want continued success.)