Set Up SRS in Postfix

Why SRS Is Necessary for SPF-Compliant Email Forwarding

You forward an email from your personal account to a group mailing list. It arrives, but some recipients see it marked as spam—or worse, it doesn’t arrive at all. Why?

SPF checks fail silently when the email passes through a third-party server, because the original sending IP no longer matches the domain’s authorized list. The sender’s address is now technically invalid, even though the message is real.

SRS—Sender Rewriting Scheme—fixes this by rewriting the envelope sender address before forwarding, so SPF alignment is preserved. Without it, forwarded emails break SPF compliance and risk being rejected outright.

Key takeaways

SRS rewrites the envelope sender address during forwarding to preserve SPF alignment.
Without SRS, forwarded messages fail SPF checks and are likely blocked or marked as spam.
Proper SRS setup in Postfix ensures SPF-compliant email forwarding across third-party servers.

How SRS Works With SPF During Email Forwarding

When you forward an email, the original sender’s domain is no longer the one sending it, breaking SPF checks. SRS (Sender Rewriting Scheme) fixes this by rewriting the Return-Path to trust your domain. It cryptographically encodes the original sender, letting receiving servers verify the forwarded message using SRS-specific keys while preserving alignment with the forwarder’s domain.

How SRS Rewrites the Return-Path

Let’s say you forward an email from [email protected]. SRS rewrites the Return-Path to something like [email protected]. The part after the + is a signature that includes the original domain and a timestamp. This way, SPF on your forwarder’s domain passes, since the sender domain now matches the one authorizing the message.

Receiving servers check this signature using the SRS domain key. If it matches, the forward is valid, and the message can be trusted. If not, it’s likely spoofed or tampered with. This preserves the integrity of SPF while allowing forwarding to work.

Why This Matters for Deliverability

Without SRS, forwarded emails often fail SPF because the sender domain has no DMARC policy or alignment with the forwarder. This leads to spam filtering, bounces, or outright rejection. SRS ensures that forwarders don’t break authentication, which keeps your messages in inboxes.

For example, if you’re managing a mailing list that forwards newsletters, SRS prevents the original sender’s domain from getting blacklisted due to your list’s behavior. The original domain stays safe; the forwarder’s domain takes responsibility — but only with proper verification.

The system works because SRS is widely adopted and documented in RFC 6510. It’s not a workaround — it’s the standard way to handle SPF-aligned forwarding across domains. Many major email providers and security tools now expect SRS in forwarders that handle bulk or automated messages.

While SRS solves SPF alignment, it doesn’t guarantee inbox placement alone. You still need strong sender reputation, proper DKIM, and clean lists. That’s where tools like MailTester help. Use bulk email verification to clean your list before forwarding, and inbox placement testing to see how your messages land in real inboxes, not just servers. Real-time verification with our API can also catch bad addresses early.

Set Up SRS in Postfix for SPF-Compliant Email Forwarding

You can set up SRS in Postfix by installing the srs package via your system’s package manager, configuring sender_canonical_maps to use srs, enabling SRS rewrite rules with a map file, generating the map with postmap, ensuring your SRS domain has a valid A record and reverse DNS, reloading Postfix, and verifying the rewritten Return-Path in headers of forwarded messages. This preserves SPF alignment across forwarders.

Install and Configure SRS

Install the SRS package using your OS’s package manager: apt install postgrey srs on Debian or Ubuntu. This includes the SRS tools needed to rewrite headers during forwarding.
Add sender_canonical_maps = srs to your /etc/postfix/main.cf. This tells Postfix to apply SRS rewriting rules to sender addresses before delivery.
Enable the SRS rewrite mechanism by adding srs_maps = hash:/etc/postfix/srs_maps to main.cf. This defines where Postfix will look up your SRS domain configurations.
After editing /etc/postfix/srs_maps, run postmap /etc/postfix/srs_maps to build the hash database. Without this, SRS won’t function.

Validate SRS Domain and Test Setup

Add your domain (e.g., example.com) to the /etc/postfix/srs_maps file in the format example.com SRS0=...=example.com. The SRS domain must be valid and reachable.
Confirm the SRS domain (e.g., srs.example.com) resolves to your mail server’s IP via an A record. Use tools like MXToolbox to validate DNS records. Reverse DNS for the IP must match the SRS domain, or replies may be rejected.
Reload Postfix with systemctl reload postfix to apply changes. Avoid full restarts unless necessary.
Send a test email from a forwarded address (like [email protected]) to yourself. Check the full message headers for a rewritten Return-Path showing SRS encoding (e.g., ).

SRS ensures that SPF checks pass when emails are forwarded, preventing rejection due to SPF alignment failure. Without SRS, forwarded messages from domains with strict SPF policies often fail delivery.

The 4 steps described in “Install and Configure SRS”, in order.

SPF alignment is critical for inbox placement — a failure can trigger filters at receiving mail servers.

For teams managing large email lists, validating your sender infrastructure is essential. Use a service like MailTester’s bulk verification to check list quality before deployment, helping identify invalid or problematic addresses early.

Common SRS Configuration Pitfalls and How to Avoid Them

You’ll break SRS forwarding if you skip DNS checks, skip reloading Postfix, misuse map formats, or forget SPF whitelisting. These errors silently cause bounces or rejections. Let’s walk through each one so you don’t waste time troubleshooting why a forwarded email isn’t getting through.

DNS and SPF: The Silent Killers

Don’t assume your SRS domain is ready. Use MXToolbox or RFC 7208 to verify A records and reverse DNS (PTR) on the SRS domain. Missing or mismatched records break the SRS chain.
Never skip adding the SRS domain to your SPF record. If your SPF policy doesn’t include include:srs.example.com, the receiving server will reject the rewritten address. SPF is strict—no exceptions.

Configuration and Reloads: Tiny Mistakes, Big Failures

Always use hash: in your SRS map file, not ldap: or mysql:. Unless you’re running a high-scale, dynamic setup, hash maps are reliable and Postfix expects them. Using the wrong format stops SRS from loading entirely.
After editing main.cf or SRS map files, run postfix reload. A forgotten reload means your new config is ignored. This is the fastest way to waste hours chasing errors that were already fixed.
Test your setup with real email—don’t rely only on logs. Use a tool like inbox placement testing to verify that forwarded messages land in the inbox, not the spam folder, even with SRS rewriting.

One misstep in any of these areas and your entire forwarding system fails silently. The worst part? The bounces won’t mention SRS—they’ll just say “invalid sender” or “rejected.” That’s why testing end-to-end is critical.

Verify That SRS Is Working Correctly

You can verify SRS is working by sending a test email through your forwarding setup, then checking the raw headers for a Return-Path that begins with srs0=, includes the original sender’s domain, and points to your forwarder’s domain. The SRS token must decode to the original sender’s domain, and the SRS domain must resolve via DNS to your authorized mail server. This confirms SPF alignment and prevents bounce loops.

Check the Raw Headers After Forwarding

Send a test email from a known valid address (e.g. [email protected]) through your Postfix SRS-enabled forwarder.
Retrieve the full email headers from the delivered message—this is usually available via your email client’s "Show original" or "View source" feature.
Locate the Return-Path header and confirm it starts with srs0=.
Check that the token contains the original domain in the format srs0=...[email protected].

Confirm SRS Token and DNS Integrity

Ensure the domain in the SRS token (the one after srs0=) is your authorized forwarder domain and resolves to a valid mail server.
Use Google’s public DNS or MxToolbox to query the TXT record for the SRS domain and confirm it matches your SRS configuration.
Verify that the Return-Path domain (the forwarder’s domain) is listed in the sender’s SPF record with a include: or ip4: mechanism.
Test deliverability by forwarding to a non-SPF-compliant recipient or a service like MailTester’s Inbox Placement Tester—it will show if SRS is working by simulating real-world delivery.
Use the MailTester API to validate forwarded addresses at scale and catch misconfigured SRS patterns early.

Proper SRS setup isn’t just about compliance—it’s about maintaining deliverability across forwarders and mailing lists. Without it, SPF breaks and messages get rejected.

Let’s be clear: SRS isn’t optional for mail forwarding in today’s environment. If you’re using Postfix for forwarding and don’t validate SRS, you’re risking bounces and reputation damage. Check the headers, validate the DNS, and test with real delivery scenarios.

Best Practices for Maintaining Sender Reputation With Forwarding

Forwarding emails safely means only routing messages from domains with strong authentication (SPF, DKIM, DMARC), avoiding known spam sources, scrubbing your list with real-time email verification to remove invalid, catch-all, and disposable addresses, and monitoring bounces and complaints closely. If you forward bad mail, your own domain gets tainted.

Only Forward Reputable, Authenticated Messages

You’re essentially vouching for every email you forward. If the original sender lacks SPF, DKIM, or DMARC, or if their domain is blacklisted, your reputation takes the hit. Use tools like RFC 7208 (SPF) and RFC 7209 (DKIM) to verify that incoming emails pass basic authentication checks before passing them through.

Let’s be clear: you don’t have to forward everything just because it arrives. If a message comes from a domain with no published SPF policy or a weak DMARC record, that’s a red flag. It’s not just about reputation — those setups can lead to your IP or domain being flagged by receiving servers.

Keep Your List Clean, Not Just Forwarded

Forwarding an email to a dead address harms deliverability. High bounce rates and complaints trigger filters that treat your server like a spam source. Use real-time verification to clean your list before any forwarding happens. This means catching invalid addresses, catch-all domains (which often hide delivery failures), and disposable email providers (commonly used in spam campaigns).

MailTester’s bulk email verification tool checks for these issues at scale — it validates syntax, checks DNS records, and confirms inbox delivery potential. You get a report showing each address’s status: valid, invalid, catch-all, or risky. Only forward to the valid ones.

Also keep an eye on post-forwarding metrics. A sudden spike in hard bounces or user complaints should trigger a review. These signals don’t just affect current messages — they influence long-term deliverability. Treat forwarded mail like any other send: it must be monitored and cleaned.

Reputation isn’t built overnight. It’s eroded fast — especially when you’re forwarding mail you didn’t originate.

Your reputation is tied to the quality of every message your server sends. Even if you’re not sending the original content, your infrastructure is responsible for delivery. Clean lists, strong authentication checks, and active monitoring are the minimums — not optional extras.

How Email Verification Prevents Forwarding Failures

Forwarding emails with invalid, catch-all, or disposable addresses leads to bounces, spam complaints, and reputational damage. By verifying every address before forwarding—using tools like MailTester—you catch bad entries early. This stops delivery failures before they happen, keeps your sender reputation intact, and ensures only valid, inbox-ready addresses receive your messages.

Why Forwarding Fails Without Verification

When you forward emails without checking the destination, you risk sending to addresses that don’t exist, are role-based, or are tied to disposable domains. These aren’t just bad inboxes—they’re red flags. The Mailvelope mailing list study found that unverified lists can have bounce rates exceeding 5%—a common sign of poor hygiene. If your forwarded messages hit these, you risk triggering greylisting, throttling, or even being blocked entirely.

For example, a forwarded email to [email protected] might appear valid, but it's likely a role account. These often reject messages, generate bounces, or get marked as spam. Similarly, catch-all domains accept any address, which means they’re hotbeds for automated bots and abuse. Forwarding to them wastes bandwidth and harms deliverability. You’re not just sending to a fake address—you’re sending to a trap.

How MailTester Stops the Failures Before They Happen

MailTester’s 98.9% accurate validation catches invalid, role, disposable, and high-risk addresses before they ever enter your forwarding pipeline. Its real-time API checks individual addresses on demand, while bulk verification helps you clean entire lists. Both integrate directly with your workflows—whether you use Postfix, SendGrid, or a marketing platform like HubSpot.

Using MailTester’s inbox placement tool gives you a final checkpoint: it checks how messages arrive in real inboxes. This isn't just about delivery—it’s about how likely the recipient is to open or reply. If your forwarder sends to a blocked or low-engagement address, it’s a silent performance killer. You're not just improving SPF compliance; you’re reducing overall sending risk.

You don’t need to guess or rely on partial checks. With MailTester, you can clean your list in bulk, verify individual addresses via the real-time API, and test inbox placement before you forward. Credits never expire, and you start with 100 free verifications—no risk, no commitment.

Integrating Verification into a Forwarding Workflow

You can prevent delivery failures and preserve sender reputation by verifying email addresses before forwarding. Use MailTester’s API to validate addresses in real time, clean large lists with bulk verification, and block invalid or risky emails early—before they hit your forwarding pipeline. This reduces bounces, avoids blacklists, and keeps your reputation intact.

Pre-Forwarding Validation with MailTester

Integrate the MailTester API into your ingestion stage. Call the API when a new email is received or submitted—either via an inbound script or a user form. Pass the address and receive a verdict: valid, invalid, catch-all, or risky. Only proceed with forwarding if the status is valid.
Use bulk verification for high-volume inboxes. If you’re processing hundreds or thousands of addresses daily (e.g., from a newsletter list or CRM export), upload your list to MailTester’s bulk verification tool. It returns full feedback in minutes, filtering out invalid, disposable, or role-based addresses that would otherwise cause delivery failures.
Verify user-submitted emails in real time. Integrate with platforms like Mailchimp, SendGrid, or HubSpot using the MailTester integrations. When a user signs up or updates their email, validate it before storing or forwarding. This stops fake or typo-ridden emails from cluttering your system.
Automatically reject invalid or risky addresses. Configure your workflow to block any email flagged as invalid or risky. This avoids sending to catch-all domains, disposable email providers, or known spam traps. This step is critical for maintaining a clean sending reputation and avoiding greylisting or ISP filtering.
Monitor inbox placement after forwarding. Use the MailTester inbox placement tool to test whether your forwarded messages land in inboxes instead of spam folders. This helps catch issues early—like poor alignment between SPF, DKIM, and SRS—before they cause widespread delivery issues.

Why This Matters for SRS and SPF Compliance

Making forwarding work with SPF requires more than just SRS. Even with correct SRS alignment, forwarding to an invalid or risky address can break sending reputation. If the recipient doesn’t exist, the bounce might be hard to parse. If the address is a disposable domain, your IP may get flagged by email providers.

By verifying addresses before forwarding, you ensure that only valid, deliverable destinations receive your messages. This reduces the chance of feedback loops and unqualified bounces—key elements in maintaining a healthy sending reputation. SPF-compliant forwarding only works when the entire pipeline is clean. As outlined in RFC 7208, Section 6.2, sending to addresses that won’t accept messages leads to reputation damage, even if SRS is configured.

With MailTester, you can scale verification without adding complexity. The API is designed for integration into existing workflows. Credits never expire, and you get 100 free verifications to start—no commitment. This makes it easy to test and deploy in production environments.

SRS and Deliverability: A Technical Summary

Setting up SRS in Postfix solves SPF breakage during email forwarding by rewriting the return path to preserve sender reputation. It’s not optional if you want trusted forwards—without it, SPF fails and messages hit spam folders or are rejected outright. Proper configuration and DNS records are mandatory. Pair it with email verification to ensure only valid, reputable addresses are forwarded.

Key steps to maintain deliverability with SRS

Enable SRS in Postfix using the srs transport and srs_map file for address rewriting.
Configure your main.cf to route outgoing mail through the SRS-enabled transport, using always_bcc = [email protected] to capture bounces.
Set up a valid SRS DNS TXT record at mail._srs.yourdomain.com with the correct signing key, verified via RFC 6309.
Ensure your SRS host supports both inbound and outbound SRS processing—this is critical for handling replies and bounces correctly.
Test with real-world bounce feedback: invalid or malformed SRS signatures will cause delivery failures or rejection by receiving servers.

Why SRS alone isn’t enough

SRS fixes SPF but doesn’t solve poor sender reputation or invalid addresses. Forwarding a known spam trap or disposable email is still bad.
Use email verification prior to forwarding to filter out invalid, risky, or catch-all addresses. Tools like MailTester’s bulk verification check validity, deliverability, and spam risk.
Integrate a real-time verification API—like MailTester’s API—to screen addresses at point of entry, reducing bounce rates before forwarding.
Monitor inbox placement using tools like MailTester’s inbox tester to validate if forwarded emails actually land in inboxes.
Remember: even a perfectly configured SRS setup fails if the original sender’s domain is blacklisted or the email content triggers filters.

Let’s be clear: no amount of SRS magic overrides bad sender reputation. You’re not just forwarding mail—you’re inheriting its reputation. Always verify the list first. MailTester’s credits never expire, so verify at scale without pressure.

Final Steps: Validate, Monitor, Maintain

After configuring SRS in Postfix, your real work begins: verify the rewrite works in live traffic, watch for abuse signals, and revisit settings when systems change. Regular checks catch misconfigurations before they hurt sender reputation. Use inbox testing tools to confirm real-world deliverability after each update.

Test and verify forwarder behavior

Send test messages from forwarded addresses and inspect the headers for correct SRS rewriting. Look for SRS0 or SRS1 prefixes in the Return-Path and ensure the original sender is preserved in the From header.
Verify the SRS-rewritten bounce address resolves correctly to your forwarder’s mail server. A failed rewrite breaks SPF validation and triggers delivery failures.
Use tools like MXToolbox or RFC 6306 to audit how your SRS implementation handles various edge cases in forwarded mail.

Monitor for abuse and reputation risks

Check bounce logs weekly. Unusual spikes in bounces from forwarded domains may indicate compromised or misused addresses.
Monitor complaint reports from ISPs. High complaint rates on forwarded emails can signal misuse or poor list hygiene.
Review mail logs for unexpected SRS patterns—multiple forwardings or high volumes from single sources suggest abuse.
Run inbox placement tests after configuration changes using MailTester's inbox placement tool to ensure messages land in inboxes, not spam folders.
Review SRS configuration annually or when you upgrade mail servers, switch domains, or change DNS records. A change in your infrastructure may break SRS rewriting.
Use MailTester’s bulk verification tool to clean forwarding lists, remove invalid or disposable addresses, and reduce bounce risk.
Implement automated validation steps in your deployment pipeline to catch SRS misconfigurations early.
Never assume SRS works perfectly just because it’s configured. Real-world delivery depends on consistent header rewriting and alignment with receiver policies.

“SRS is only effective if every intermediate system respects and preserves the rewritten header.” — RFC 6306

Let’s be clear: SRS doesn’t fix all forwarding issues. It only helps with SPF alignment on bounced messages. The rest—message content, sender reputation, domain trust—depends on responsible email practices. Use the right tools, test relentlessly, and maintain your setup. This isn't a one-time effort. It’s part of responsible email forwarding.

SRS + Email Verification = Reliable Forwarding

SPF compliance isn’t optional—it’s required for inbox placement. Without SRS, forwarded emails break SPF alignment and get rejected or marked as spam.

Combining SRS with real-time email verification ensures only valid, deliverable addresses are forwarded. This cuts bounce rates and stops reputation damage before it starts.

MailTester helps catch invalid addresses early. With 100 free verifications to start and credits that never expire, you can verify at scale without waste.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if I forward emails without SRS?

The forwarded message fails SPF checks, leading to rejections, high bounce rates, and reduced sender reputation.

Can I use SRS with DKIM and DMARC?

Yes, SRS works alongside DKIM and DMARC. DKIM signs the body, and DMARC policies can still enforce alignment at the envelope level.

Do I need a separate domain for SRS?

Yes. The SRS domain (e.g. srs.example.com) must be registered, have an A record, and reverse DNS configured.

How accurate is MailTester’s email verification?

MailTester’s verification has a 98.9% accuracy rate, identifying valid, invalid, catch-all, and risky email addresses.

Can I integrate MailTester with Postfix?

Yes. Use the real-time API to verify addresses before processing, or run bulk checks on your list before forwarding.

Does SRS affect email tracking or analytics?

No. SRS only modifies the Return-Path header. It does not interfere with message content, tracking pixels, or headers used for analytics.

Do disposable emails need SRS?

No. Disposable domains are often not SPF-compliant and should be blocked before forwarding, not processed with SRS.

Is SRS supported by all email providers?

Most major providers (Gmail, Outlook, Yahoo) understand SRS rewrites and accept SPF-passing forwarded messages.

How often should I verify email lists for forwarding?

Run verifications before forwarding, and periodically to account for list decay — monthly for high-volume campaigns.

Can SRS help with role accounts?

SRS ensures SPF compliance but does not verify if an address is a role account. Use verification to detect and filter out role addresses.

Will SRS reduce my bounce rate?

Yes, by preserving SPF alignment and reducing sender reputation damage, SRS helps prevent delivery failures.

What if my SRS domain fails DNS lookup?

SRS will not function. The receiving server will reject the email due to an invalid Return-Path. Ensure DNS records are correct and accessible.