SRS configuration for Postfix & Plesk

Sender Rewriting Scheme (SRS) is a scheme for rewriting the envelope sender address of an email message, in view of remailing it. This function (re)allow you to forward email on a server with SPF enabled. SPF ensure that the server who sends an email is allowed to send it from this domain. If you forward a mail, SPF will fail as your server is not allowed to send email from the domain of the forwarded email. SRS solve this issue.

An example may be better. You have your mail server and a mailboxes this mailbox is forwarded to A mail from via is sent to Your server checks with SPF that is allowed to send email for domain, do the antispam check and then forward it to The Gmail server verify that is allowed to send email from domain As it’s not true the SPF test will fail and this mail could be classified as SPAM. If the forwarded mails are SPAM your server can also be blacklisted. With SRS the envelope is rewritten from <> to something like <> so SPF test will pass. More information about SRS can be found here at

Before implementing SRS you should be aware that all forwared mail will be interpreted as coming from your server. If you do not have a good antispam configuration you may become a relay of spam an cloud be blacklisted !

Runing configuration

Debian wheezy 3.2.0-4-amd64
Postfix 2.9.6
Plesk 12.0


First point is to install dependencies if you don’t already have this package.

SRS is implemented for Postfix with PostSRSd. They are other option but this is the only one that works as a Postfix milter.

Next step is to build the postsrsd application

Configuration of PostSRSd

The configuration of PostSRSd is stored in /etc/default/postsrsd. Only one parameter must be changed to disable SRS for local domains. If your server hosts mutliples domains you have to disable SRS for local incoming mails :

During the installation, a secret key is generated and stored in /etc/postsrsd.secret. Be careful to protect this secret because your server can be used as open relay if this key is known. When the configuration is done you just have to enable the daemon on OS start (thanks to Albrecht in comments) and start it the PostSRSd directly.

Configuration of Postfix

By default OpenSRSd will use the ports 10001 and 10002. You only need to add these lines to /etc/postfix/ to enable the rewriting.

And then reload postfix

Integration with Plesk

As every local domain should be added to the OpenSRSd configuration (and removed when the domain is removed). We can use the scripts and described in post DKIM configuration for Postfix & Plesk to call custom scripts only for SRS configuration.

Create custom script in directory /scripts/ named with the content below. It will add the newly created domain to the SRS_EXCLUDE_DOMAINS variable and apply change by restarting SRS and reloading Postfix.

Create the script that will remove the domain from the exclude list :

You need to edit and to call these two new scripts.

Important note about Spam Filtering and White/Black Lists

PostSRSd rewrites all incoming mails even those are not forwarded this is a known issue from the editor of PostSRSd caused by the way it is integrated with Postfix. This has an impact with the black and white list on Spam fighter, for example spamassassin. If you whitelist the main domain of the server (also the domain used by default by PostSRSd) the spam filter will be completely bypassed. Here is an example of the problem : A mail from arrives, the from address is rewrited like If is whitlisted by the spam filter, no spam verification will be done.

To allow the main domain to be whitelisted without impact on spam filtering, you may change the SRS domain in PostSRSd with a subdomain of the main domain in /etc/default/postsrsd :

If you have custom blacklist or whitelist elements like *, the spam filter will not match this pattern as the from field has been rewritten. These patterns have to be changed to ** Do not forget that mails from internal domains will not be rewritten. If the server hosts the domain and you would whitelist this domain, you may add the rule *


The easiest way to check if the SRS is working well is to check headers on a forwarded mail. In the headers the Return-Path should be rewritten like this :

The mail log of the server will also show your the whole process of a mail. To do a real time trace :


  1. Albrecht Köhnlein

    Just found your tutorial and tried to install it on Debian 8.

    > service postsrsd start

    failed. I had to run

    > systemctl enable postsrsd

    before and everything was ok. Maybe you can extend your tutorial.

    1. Stéphane (Post author)

      Hello Albrecht,

      Thanks for your comment, this is completely right, I’ve added it to the post.


  2. Costin


    On some example I have seen this approach:
    “recipient_canonical_classes= envelope_recipient”

    What happens exactly if ‘header_recipient’ is not added? So far I found no explanation.

    1. Stéphane (Post author)

      Hello Costin,

      Thanks for your comment, for each incoming mail Postfix will have the envelope_recipient with the value provided in the MAIL TO command during TCP connection to the mail server and a header_recipient contained in the BODY part of the mail in the mail header To:.
      So basically if you didn’t add the header_recipient in the recipient_canonical_classes, the from address will not be de-rewritten during SRS process when a response to a rewritten mail come back to the mail server.
      It may have no impact on the delivery of the e-mails if the To header is not rewritten. In any case I do recommend to remove all possible rewrite done before if any other mail server manipulate the To header (for example if some mail server replace the To address with the Envelope recipient you would have a reason to remove this).

      For my point of view there is 99% of chances that only recipient_canonical_classes= envelope_recipient would be sufficient.
      I hope I answered your question and wish you a great day.


Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.