tl;dr: SRS changes the sender address when you forward email so it doesn’t get filed as spam.
We’ve just deployed an update to our hosting accounts that allows you to enable Sender Rewriting Scheme when forwarding mail for your domain.
We’ve previously mentioned how we’re seeing increased adoption of Sender Policy Framework (SPF), a system for ensuring that mail from a domain only comes from authorised servers. Whilst this may or may not reduce spam, it does very reliably break email forwarding.
If someone at sender.com sends you an email to you at yourdomain.com and you forward it on to your address at youremailprovider.com, the email that arrives at your final address will come from the mail server hosting yourdomain.com which almost certainly isn’t listed as a valid sender in the SPF record for sender.com. Your email provider may reject the mail, or flag it as “untrusted”.
To fix this, we need a different TLA: SRS, or Sender Rewriting Scheme. As the name suggests, this rewrites the sender address of a forwarded email, from one in a domain that you don’t control (sender.com) to one that you do (yourdomain.com).
In the example above, the actual rewritten address would be something like:
This includes an encoded version of the original address, and any email sent to it will be routed back to the sender. This means that any bounces messages will end up in the right place.
The sender and recipient in these examples refer to the “envelope” sender and receiver. The addresses that are normally visible to users are the “from” and “to” headers, which may be different and are unaffected by sender rewriting. Applying SRS should be invisible to the end users.
SRS is now available as an option whenever you create or edit a forwarder using the customer control panel for email accounts hosted on our main hosting servers. If your account is hosted on sphinx, we need to do a little extra magic to enable it, so please email support.