How to Configure SRS with Postfix

What Is SRS and Why Is It Required?

The Sender Rewriting Scheme (SRS) is a mechanism that allows E-Mail forwarding to continue functioning correctly in environments where modern anti-spam and anti-spoofing technologies such as SPF, DKIM and DMARC are enforced.

Historically, simple forwarding setups were straightforward: a forwarding mailserver simply accepted an incoming message and re-submitted the same message to another destination mailbox. Modern E-Mail infrastructure however no longer permits unrestricted forwarding behavior without additional precautions.

Serious mail operators enforce sender validation policies using a combination of:

• Sender Policy Framework (SPF)
• DomainKeys Identified Mail (DKIM)
• Domain-based Message Authentication, Reporting and Conformance (DMARC)

These mechanisms are designed to reduce spam, phishing and sender spoofing by verifying whether a given mailserver is authorized to transmit mail on behalf of a domain. SPF publishes a list of permitted transmitting systems in the DNS. DKIM adds cryptographic signatures generated by the originating mailserver. DMARC defines how receiving systems should interpret SPF and DKIM results and which policy should be applied when validation fails.

It is important to understand that SPF and DKIM validate domain-level transmission authorization, not the identity, legitimacy or trustworthiness of the human sender. They only validate whether a mailserver is authorized to transmit mail for a domain.

This creates a problem for forwarding. When a forwarding server receives a message and forwards it unchanged to another destination, the forwarding server effectively re-submits a message that still claims to originate from the original sender domain. From the perspective of the receiving system, the forwarding server now appears to be transmitting mail without authorization. Thus it breaks SPF validation and may also interact badly with DMARC enforcement policies.

In smaller infrastructures under full administrative control this can be mitigated by configuring the receiving side to trust the forwarding infrastructure explicitly. This approach however does not work with external providers such as

• Google Mail
• ProtonMail
• institutional mail infrastructures

In such environments SRS becomes necessary. SRS rewrites the envelope sender of forwarded messages. This modification only affects SMTP envelope metadata and does not modify the visible From: or To: headers shown to the user inside the mail client. The forwarding system therefore becomes the authenticated original SMTP sender while preserving the visible information for the user. The rewritten envelope sender address contains encoded information about the original sender as well as a cryptographic signature that prevents tampering.

As a result:

• SPF validation succeeds because the forwarding server is now transmitting mail for its own domain
• DMARC policies are no longer violated by the forwarding process

• users still see the original sender (or at least whatever the original sender wrote in From) in their mail clients

• Software Versions
• DNS Requirements
• Installing and Configuring PostSRSd
• Configuring Postfix
• Forwarding and Aliasing
• Debugging and Verification
• Operational Notes
• Conclusion

Software Versions

The following configuration was tested using:

• Operating system: FreeBSD 14.3
• Database: MySQL 8.4
• Postfix: 3.11.2
• PostSRSd: 2.0.11

The configuration will most likely also work on other Unix-like operating systems and more recent software versions, though configuration details may differ.

DNS Requirements

To implement SRS it is required to use a dedicated hostname. Assume the primary domain is example.com and the mailserver hostname is mail.example.com. A common choice would be:

srs.example.com

This domain will be used as the rewritten sender domain for forwarded mail.

The DNS zone requires:

• SPF records
• MX records
• IP address records (optionally also Legacy IPv4 records)

An example configuration may look as follows:

srs    IN TXT     "v=spf1 +mx +ip6:2001:db8:a:: +ip4:192.0.2.1 -all"
       IN SPF     "v=spf1 +mx +ip6:2001:db8:a:: +ip4:192.0.2.1 -all"
       IN MX 10   mail.example.com.
       IN A       192.0.2.1
       IN AAAA    2001:db8:a::

While the legacy SPF RR type is shown above for completeness, modern deployments generally only require the TXT record.

DNSSEC is strongly recommended for all production infrastructures, as usual.

Installing and Configuring PostSRSd

On FreeBSD the daemon can be installed directly from packages:

pkg install postsrsd

The daemon is configured via:

/usr/local/etc/postsrsd.conf

A minimal configuration could look as follows:

domains = { "example.com", "otherowndomain.example.com" }

srs-domain = "srs.example.com"
socketmap = unix:/var/spool/postfix/srs
keep-alive = 30

original-envelope = embedded
secrets-file = "/usr/local/etc/postsrsd.secret"

separator = "="
hash-length = 4
hash-minimum = 4
always-rewrite = off

unprivileged-user = "nobody"

syslog = on
debug = off

The most important parameters are:

• domains: Domains that are considered local and therefore do not require rewriting
• srs-domain: The domain used for rewritten envelope senders
• socketmap: The Unix domain socket used by Postfix to communicate with PostSRSd
• original-envelope: Controls how the original sender address is stored

The embedded mode is usually preferable because it is stateless and does not require maintaining a database mapping between rewritten and original senders. The tradeoff is that the original sender information must fit into the rewritten local-part, limiting the maximum sender address length to 51 bytes. Using the database on the other hand opens up a pathway to DoS attacks, which is usually even less desirable.

A secret key must also be generated for signing and validating rewritten addresses. The easiest way is to use openssl rand:

openssl rand -base64 32 > /usr/local/etc/postsrsd.secret
chmod 600 /usr/local/etc/postsrsd.secret

The daemon can then be started manually for testing:

/usr/local/etc/rc.d/postsrsd onestart

Useful verification steps include:

• checking /var/log/maillog
• verifying that the socket file exists

To enable automatic startup during boot add

postsrsd_enable="YES"

inside /etc/rc.conf.

Configuring Postfix

The Postfix configuration itself is comparatively small. The following directives are added to /usr/local/etc/postfix/main.cf:

sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender

recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient,header_recipient

Older documentation sometimes references additional spawn services inside master.cf. Modern deployments using the standalone daemon generally no longer require this.

After applying the configuration restart Postfix:

/usr/local/etc/rc.d/postfix restart

At this point SRS rewriting is operational.

Forwarding and Aliasing

Forwarding itself continues to use ordinary Postfix mechanisms such as:

• virtual_alias_maps
• recipient_bcc_maps

One important operational detail is that recipient_bcc_maps are not suitable for forwarding to multiple independent recipients, while virtual_alias_maps support this directly. The authors personal configuration uses MySQL-backed alias maps, though hash maps work equally well for smaller installations. In the following example we will show hash maps due to their simplicity.

Example:

virtual_alias_maps = hash:/usr/local/etc/postfix/virtual_alias_map

A forwarding rule may then look as follows:

localtarget@example.com    localuser@example.com,user@gmail.com,another@example.net

Messages sent to localtarget@example.com are now forwarded to all specified recipients. Messages leaving the local domain are automatically rewritten using SRS.

When using hash maps the database must be regenerated after modifications:

postmap /usr/local/etc/postfix/virtual_alias_map

Debugging and Verification

The easiest way to verify correct rewriting behaviour is using postmap queries directly against the socketmap interface:

postmap -q "localtarget@example.com" socketmap:unix:/var/spool/postfix/srs:forward
postmap -q "user@gmail.com" socketmap:unix:/var/spool/postfix/srs:forward

• Local addresses should normally return no rewritten result.
• External addresses should return an SRS-encoded sender address.
• The mail log should additionally show rewritten envelope senders during forwarding operations.

Operational Notes

SRS solves only the forwarding problem caused by SPF and DMARC enforcement. It does not replace:

• DKIM signing of outbound mail
• proper reverse DNS
• TLS configuration
• spam filtering
• queue monitoring
• abuse prevention

In practice SRS should therefore be viewed as one component inside a properly maintained mail infrastructure. SRS rewriting itself normally does not invalidate DKIM signatures because DKIM signs message headers and body rather than SMTP envelope metadata. However, operationally it is often cleaner to perform SRS rewriting before final outbound signing and policy processing in complex mail pipelines.

Conclusion

Modern E-Mail infrastructures no longer permit naive forwarding configurations without additional measures. SRS provides a relatively lightweight and operationally simple solution that restores compatibility between forwarding setups and modern SPF/DMARC enforcement. With Postfix and PostSRSd the required configuration is comparatively small and integrates cleanly into existing mailserver deployments. For administrators operating their own mail infrastructure, SRS is effectively mandatory whenever mail forwarding towards external providers is required.

References

• PostSRSd on GitHub
• Postfix
• DNSSEC configuration

This article is tagged:

• Basics
• FreeBSD
• System administration
• Internet