SRS for forwarded aliases
 

The help pages for aliases recommend not enabling SRS (sender rewriting scheme) when configuring an alias to forward to an external mail system (gmail in my case).

Can anyone explain why this is the recommendation?

The help page says:
The example given is where it is needed - forwarding to Gmail if SPF is the only reason a message is rejected.

However, the DMARC standard makes use of both DKIM and SPF, and it additionally requires alignment between the envelope From and From header. SRS will cause this alignment to fail.

See more at:
https://fastmail.blog/2016/12/24/spf-dkim-dmarc/

At this time (with the current popular security standards) it's not possible to guarantee that forwarding works in all cases. This has nothing to do with Fastmail, but is due to the attempts to reduce spam by preventing spoofing of the From address.

Bill

Setting up SRS may prevent an email being rejected for failing SPF, it shouldn't make any difference to whether it passes DMARC.

"We don't recommend enabling SRS unless you need to" without any explanation seems very enigmatic to me. The reason for not having it would have to be a pretty good one IMO because a third-party downstream service could change its policy at any time.

FastMail probably dislikes the use of SRS on principle, in that it is spoofing the return address. There is always a chance that the receiving server will detect the "spoofing" and misinterpret the intention. Most SPF implementations have whitelists of mail services that do legitimate spoofing (such as forwarders like Pobox.com) but there could be trouble if you are not on that list.

Personally, though, like you I tend to think using SRS may be the lesser risk.

Old thread revival. If I am not mistaken, Fastmail's other service, Pobox.com, does utilize SRS as part of their email forwarding products. Not sure why a service like Pobox.com seems to be able to do forwarding successfully and make a profit on it while many people seem to think all forwarding is a bad idea. Why do Fastmail and Pobox.com, parts of the same company, have different opinions on SRS? In the past when I used Pobox.com I had absolutely no issues with the forwarding part of their service and when I sent email to others, via Gmail but using Pobox SMTP, my mail was getting through reliably.

Fastmail does support SRS as an alias redirection setting, but AFAIK not from sieve/rules.

pobox is the best know portable address provider around. Possibly it gets more widespread special handling.

Reading up a bit on SRS and forwarding, SPF, DKIM, DMARC, etc., it is a wonder any of our email ends up where it's supposed to!

I have seen many messages fail to get through after forwarding in the past few months. It's due to DMARC test failure at the receiving end on messages sent from certain domains. It all depends on the domain of the sender and how strict the DMARC test is at the receiving server. Many of the messages ended up in the spam folder, but some just disappeared.

SRS can in some cases solve SPF forwarding, but only if the receiving server doesn't use strict SPF and DMARC alignment (which means that the SPF and DKIM signing domains, From header domain, and From envelope domain all match).

Bill

I'm sure that's part of it, but it also seems that other factors are at play. For example, at work I have to constantly check my Junk folder using Microsoft 365. Every day it contains legitimate emails that I need to see. I can whitelist, move to Inbox, doesn't matter. The strange thing is it is not at all consistent. Some senders always go straight to Junk no matter what I do, but most only fail part of the time--sometimes to Junk, sometimes to the Inbox. There is no difference that is obvious between which ones go where: same sender, similar emails, different results. And, some of these are emails from very large, mainstream vendors and companies we do business with regularly, including Microsoft themselves. Though not specifically a forwarding problem since most of them are not forwarded.

Have you looked at the full headers? Look for Authentication-Results near the top. Here is a passing message from ancestry.com received at live.com/outlook.com:
Below is a message from Microsoft which passed SPF, failed DKIM, and passed DMARC. Outlook.com filed it into the Junk Email folder, even though it was sent by Microsoft (who owns Outlook.com)! Microsoft seems to often corrupt DKIM.
Bill

No, I haven't done that, but I would assume that email from the same source would have the same settings, but I could be wrong! It just seems odd that a message from Comcast, which we have multiple accounts with and we do business with every month, goes right into my Junk in Outlook. Unless I am misreading things, this email passed authentication.

Authentication-Results:
spf=pass (sender IP is 142.0.167.118)
smtp.mailfrom=notice.comcastbusiness.com; XXXXXX.org;
dkim=pass (signature was verified) header.d=notice.comcastbusiness.com;XXXXXX.org; dmarc=pass action=none header.from=notice.comcastbusiness.com;compauth=pass reason=100

Yeah, Microsoft has mysterious email filtering criteria (having nothing to do with SRS, SPF, DKIM, or DMARC) which are impossible to control. My guess is that others with Outlook email accounts are marking those Comcast messages as spam and that's affecting your account spam filtering.

Bill

Which is super annoying because these are things like invoices and service messages. I can try whitelisting, moving to the Inbox, etc. and they still end up in Junk, some of the time, but not all the time. We are using Office 365 Business Premium. It means that nearly every day I find things in Junk that I need for our business. The worst is that our own internal messages that come from our website or email service provider also end up in Junk, a lot of the time, but not all the time.

SRS doesn't have any effect on DMARC at all. The advantage is that it avoid an SPF fail.

The receiving server may reject based on SPF either without using DMARC or before using DMARC. The latter is not as bad as it sounds because most ham without an author aligned SPF pass will still have an SPF pass.

Even if there is no SPF rejection an SPF fail may be taken account of in other spam filtering.