Updated: June 15, 2021
Email servers are often the targets of cyberattacks, with phishing and spam being the most common ones.
In recent years, email authentication standards like the SPF, DKIM, and DMARC have been introduced to supplement the SMTP protocol and prevent attacks on your email communication.
Although the introduction of these mechanisms has improved email security and spoofing prevention, it’s also disrupted some essential scenarios — namely auto-forwarding and relaying.
At Axigen, we’re committed to ensuring our customers’ security and, at the same time, keeping pre-existing functionalities (like forwarding). This is why, starting with Axigen X3 Update 2, we will begin rolling out the Sender Rewriting Scheme (SRS) functionality to solve the problem of auto-forwarding being incompatible with SPF.
Here’s what you need to know about SRS.
What Is Sender Rewriting Scheme (SRS)?
In short terms, SRS does exactly what its name says — it's a scheme for rewriting an email's envelope sender in order to remail it.
The main objective of email authentication standards is to prove an email is not forged, meaning it comes from who it claims to be from. All this is great except when legitimate email servers need to forward emails.
Let’s say a Mail Transfer Agent accepts an email message, whose destination is not a local mailbox and needs to forward it. In this case, either the email author (most frequently) or whoever administers the forwarding should receive a bounce message.
If that bounce message is sent to an email address with a strict SPF policy that the target MTA enforces, the forwarding transaction will be rejected and the email can be lost.
Using a Sender Rewriting Scheme means that this scenario can be avoided by allowing the recovery of the original envelope address. That way, when the bounced message reaches the MTA, it can be forwarded along the reverse path with an empty envelope sender.
How Does Sender Rewriting Scheme (SRS) Work?
It all starts with the Sender Policy Framework (SPF) standard, which allows senders to define which IP addresses are allowed to send mail for a particular domain. If an email fails its SPF check, it will be either marked as spam or simply rejected by the receiving MTA, especially if the DMARC policy is p=reject and neither DKIM does not validate and align.
The SPF is a great feature that protects users from unwanted emails, but it does have one downside: it doesn’t allow you to forward emails in the traditional way.
This means that if you attempt to forward an email from a hosted domain to your Gmail address, for example, it will not arrive reliably - it will be marked as spam, or it might not arrive at all.
Considering that the SPF standard is used by all the popular webmail systems (especially in conjunction with DMARC), including Gmail, Hotmail, Outlook, and Yahoo, this can be problematic.
The Sender Rewriting Scheme (SRS) offers a solution to this problem. It modifies the sender address to use your own domain, which means you control the relevant SPF records. This way, you can make sure that your forwarded email passes the SPF checks and arrives in your Gmail inbox.
Note! The SRS rewrites the Sender address so that the email appears to come from the forwarding mail server. This allows a forwarded email to pass an SPF check on the receiving server. The SRS will not function correctly if the external mail server’s autoresponder replies to the Sender address instead of the From address.
Why the SRS Functionality Matters
The Sender Rewriting Scheme is especially useful when you want to use an official email address (like info@company.com), but you want to forward all the messages you receive to your personal email address (something like david@yahoo.com).
Without SRS, the email’s origin can’t be verified, so the receiving MTA system (Yahoo in this case) marks it as spam or rejects it because it didn’t pass the SPF check. This is a scenario often encountered by one-man businesses and small hosting providers.
The main advantage of an email server with an SRS functionality is the improved deliverability of applicable messages that pass Sender Policy Framework (SPF) checks when they arrive from the original sender, but then fail SPF at the final external destination after they are forwarded.
What Sender Rewriting Scheme (SRS) Looks Like
Let’s say you want to send your job application from your personal email address (john@gmail.com) to the company’s official email address (info@company.com).
However, on your company’s account (if permitted by one’s company’s policy) one has set up auto-forwarding to an external email address (david@yahoo.com).
The SRS will look something like this:
| Original message | Auto-forwarded message | |
| Recipient | info@company.com | david@yahoo.com |
| Envelope From | john@gmail.com | SRS0=Ec3y=5M=gmail.com=john@company.com |
| From header | john@gmail.com | john@gmail.com |
SRS on Axigen Mail Server
Enabling SRS on an Axigen installation can be made by setting the new enableSRS server context parameter and configuring a value for the srsSecretKey parameter in the same context.
When SRS is enabled, Axigen will generate / use a random SRS secret key.
Notes:
- Changing the srsSecretKey may result in Axigen not being able to compute the reverse SRS for emails that are already in transit using an older secret.
- In a cluster environment, the sysadmin must ensure that the srsSecretKey is shared between all the cluster members.
For more technical details, you can review our SRS documentation here.
More Information
- How to redirect email messages?
- How to forward incoming emails to a specific account
- How to forward messages to another mail server if the account is not local
- How to forward the messages for an account and keep a local copy