
The Sender Rewriting Scheme (SRS) is a clever way to prevent email spoofing, which is when a sender forges an email to make it look like it comes from a different address. This can be a real problem, as it allows spammers to send emails that appear to come from legitimate sources.
SRS works by rewriting the sender's email address in the email headers, making it difficult for spammers to fake the sender's address. This is a key feature of SRS.
The SRS scheme is designed to be compatible with most email servers and clients, making it a practical solution for businesses and individuals alike.
On a similar theme: Email Authentication
What Is Sender Rewriting Scheme
Sender Rewriting Scheme (SRS) is a clever solution to a common problem in email forwarding.
It rewrites the sender address in the "From" header and adds a new header called "Resent-From" that contains the SRS address.
This allows a forwarded email to pass an SPF check on the receiving server.
A unique perspective: Email Sender Accreditation

The "From" header is rewritten to match the SRS address, which is the address of the forwarding mail server.
The original sender address is preserved in the "Sender" header, which indicates the actual identity of the sender.
For example, if Charlie receives an email from Alice via Bob's forwarding service, the email headers will look something like this:
- From: [email protected]
- Resent-From: [email protected]
- Sender: [email protected]
- To: [email protected]
- Subject: Hello
The SRS rewrites the sender address so that the email appears to come from the forwarding mail server, which is the main advantage of an email server with an SRS functionality.
Check this out: How to Delete All Email from One Sender Gmail
Configuring Sender Rewriting Scheme
To configure the Sender Rewriting Scheme (SRS), you need to configure srsfilter, a virtual domain, and add MX records to your DNS. This involves adding mx.mydomain.tld to rcpthosts, creating a virtual domain for SRS purposes, and configuring srsfilter to run when an email for the srs user is received.
You'll also need to create an SPF record and configure DKIM and DMARC records for mx.mydomain.tld to satisfy Google policies. This ensures that your emails are properly authenticated and trusted by receiving servers.
Here are the key configuration steps:
Configuration

To configure Sender Rewriting Scheme (SRS), you'll need to create a virtual domain for SRS purposes, which should not be created by the usual vadddomain program. This virtual domain will be used exclusively for SRS and its definition is different from the vpopmail's virtual domains.
You'll also need to add the domain to the rcpthosts file so that qmail-smtpd will accept emails for that domain. Don't add it to control/locals, or the virtualdomains file will be ignored and srsfilter will not be run.
Here are the mandatory settings you'll need to configure:
- Add the domain to the srs_domain control file, so that srsfilter will use it in the rewritten address for all virtual hosts.
- Create the srs_secret file, which is a random string to generate and check SRS addresses.
- Provide an MX record and an SPF record for the newly created srs_domain in your DNS.
- Configure DKIM and DMARC records for mx.mydomain.tld to satisfy Google policies.
You'll also need to configure PostSRSd by editing the postsrsd.conf file in /usr/local/etc. The most important configuration options are domains (or domains-file) and secrets-file with a secret passphrase for authentication.

Here's a summary of the configuration options you'll need to consider:
For integration with Postfix, you'll need to add a canonical map to your /etc/postfix/main.cf file, specifying the path to the unix socket relative to /var/spool/postfix. If you prefer a TCP connection, you'll need to change the mapping accordingly.
Axigen Mail Server
Axigen Mail Server supports the Sender Rewriting Scheme (SRS) feature, which can be enabled by setting the enableSRS server context parameter.
To enable SRS on Axigen, you'll need to configure a value for the srsSecretKey parameter in the same context. This key is crucial for generating and using the SRS secret key.
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, it's essential to share the srsSecretKey between all cluster members to ensure proper functionality.
- 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 srsSecretKey must be shared between all the cluster members.
Implementing Sender Rewriting Scheme
To implement an SRS, you need to configure a mail transfer agent to rewrite the sender address of emails. This involves specifying the rewrite rules and mapping the original sender address to a new address.
Broaden your view: Bounce Address Tag Validation

The new address is typically a unique identifier for the sender, such as an email address or a hash of the original address. This ensures that emails from the same sender are rewritten to the same new address.
A simple example of an SRS rewrite rule is to replace the original sender address with a hash of the original address. For instance, if the original address is "[email protected]", the rewritten address might be "hash:[email protected]".
The rewritten address is then used as the sender address in the email header. This allows the receiving mail server to identify the original sender and deliver the email accordingly.
On a similar theme: Bounce Address
Troubleshooting and Testing
If you're experiencing issues with your Sender Rewriting Scheme, start by checking the IP address mapping, as incorrect mappings can cause problems.
To troubleshoot, verify that the IP address mapping is correct and matches the one specified in the configuration.
A mismatched IP address can lead to email delivery issues, so double-check the mapping to ensure it's accurate.

Make sure the sender rewriting scheme is enabled and correctly configured in the email client or server.
Testing is crucial to ensure the scheme is working correctly, so send a test email to verify that the sender rewriting scheme is functioning as expected.
If you're still experiencing issues, check the logs for any errors or warnings related to the sender rewriting scheme.
Limitations and Considerations
Sender Rewriting Scheme (SRS) has its limitations, which can impact its usability and security. SRS addresses are longer and more complex than normal email addresses, which may cause confusion or mistrust among users.
This can lead to difficulties in typing or copying the SRS address, or exceeding the length limit of some email clients or servers. I've seen this happen when users try to paste SRS addresses into their email clients, only to have them truncated or rejected.
SRS addresses are vulnerable to spoofing or forging, if the secret key of the forwarding service is compromised or guessed. An attacker could create a fake SRS address that encodes a different sender address than the original one, and use it to send malicious messages to the recipients.

Here are some of the limitations of SRS:
- SRS addresses may not be compatible with some email features or standards, such as DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting and Conformance), or ARC (Authenticated Received Chain).
- SRS addresses may cause messages to fail verification or alignment checks, leading to rejection or marking as spam by the recipient's mail servers.
These limitations can make SRS less effective in certain situations, and may require additional measures to ensure the security and authenticity of email messages.
Security and Compliance
Sender Rewriting Scheme (SRS) is a security feature that helps prevent email spoofing and spam. It does this by rewriting the sender's email address in the message envelope.
SRS helps prevent email spoofing by adding a new header to the email, which contains the original sender's email address. This makes it harder for spammers to fake the sender's address.
The SRS header is added by the sender's server, and it's not visible to the recipient. This ensures that the recipient's email client can't be tricked into thinking the email came from a different sender.
SRS is particularly useful for organizations that handle sensitive information, as it helps protect against phishing and other types of email-based attacks.
Understanding Email Headers
Email headers can be a bit confusing, but understanding them is key to grasping how the Sender Rewriting Scheme (SRS) works. SRS affects the email headers by rewriting the sender address in the "From" header, and adding a new header called "Resent-From" that contains the SRS address.
The "From" header is rewritten to match the SRS address, so that the message can pass the SPF check. The original sender address is preserved in the "Sender" header, which is used to indicate the actual identity of the sender.
For example, if Charlie receives an email from Alice via Bob's forwarding service, the email headers might look like this:
- From: [email protected]
- Resent-From: [email protected]
- Sender: [email protected]
- To: [email protected]
- Subject: Hello
The SRS address has three parts: the prefix, the signature, and the encoded original address. The prefix indicates the number of times the message has been forwarded using SRS, usually up to SRS9. The signature is a hash of the encoded original address and a secret key that is known only to the forwarding service. The encoded original address consists of the original sender domain and the original sender local part, separated by an equal sign.

Here's a breakdown of what the SRS address looks like:
The SRS address looks something like this: [email protected]. This address is used to indicate that the message has been forwarded by an intermediate agent, and to provide the address for reply.
Featured Images: pexels.com


