Forwarding Broke Your SPF/DMARC? Here’s How SRS and ARC Save the Day (Without Tears)

The Day Forwarding Made Me Spill My Coffee

Ever had that moment when a perfectly good email vanishes into the void the second it’s forwarded? I remember a Tuesday morning—quiet, coffee still warm—when a client pinged me: “Our invoices aren’t reaching customers when they forward them to Gmail.” Classic. The original message sailed through. But the forwarded one? SPF fail. DMARC fail. Cue the head-scratch.

Here’s the thing with email: it’s very good at pretending to be simple. But under the hood, it’s a tangle of headers, cryptographic signatures, and decades of layered decisions. Forwarding, which feels like a “meh, just pass it along” move, can absolutely wreck SPF and DMARC alignment if you don’t handle it right. The fix is beautifully boring once you know it: SRS for SPF, ARC for DMARC’s sanity. That’s what we’ll unpack today.

We’ll walk through why forwarding breaks authentication in the first place, how Sender Rewriting Scheme (SRS) patches SPF, how Authenticated Received Chain (ARC) helps downstream providers trust your forwarded mail, and how to roll them out in a clean, production-ready way. I’ll share the gotchas, the “ask me how I know” mistakes, and how I test end-to-end so you don’t have to guess.

Why Forwarding Breaks SPF and DMARC (And Why That’s Not Your Fault)

Let’s start with the picture in your head. An email is sent from [email protected] through example.com’s mail server. SPF says: “Only example.com’s servers may send mail for example.com.” DKIM signs the message body and some headers, and DMARC says: “When in doubt, trust alignment with the From domain and what SPF/DKIM say.” All good so far.

Now Bob receives that message at [email protected], which forwards to Bob’s personal Gmail. Your server becomes the new sender in the eyes of Gmail because you initiate a fresh SMTP transaction to Gmail. SPF checks the IP of the forwarding server against the original domain’s SPF policy. Oops. Your server isn’t in example.com’s SPF record, so SPF fails. DKIM might still pass if the body and headers weren’t mangled, but forwarding systems sometimes add footers, subject tags, or rewrap long lines. Suddenly DKIM is shaky too.

DMARC lives on top of SPF/DKIM. It wants either SPF or DKIM to align with the visible From domain. If SPF fails after forwarding and DKIM gets tweaked, DMARC can tumble like a Jenga tower. That’s when you get non-delivery, quarantines, or the dreaded silent drop.

It’s not that forwarding is wrong; it’s that vanilla forwarding ignores the rules modern authentication expects. We need to make the message carry proof: who handled it, what we verified, and why the next hop should still trust it. Enter SRS and ARC.

SRS: The Little Return-Path Rewrite That Saves SPF

Think of SRS like putting a return address sticker on a forwarded package. SPF validates the server that originates the SMTP transaction. When you forward a message, you are now the origin. Without SRS, you’re claiming to send mail on behalf of the original domain, which their SPF will almost certainly reject. With SRS, your server rewrites the envelope sender (Return-Path) into an address you own and can vouch for.

Practically, an address like [email protected] becomes something like [email protected]. The HASH is there so bounces can be safely routed back through your forwarder and eventually to the right sender without being abused. To SPF, the mail is now coming from your domain’s Return-Path, which you authorize via your SPF record. Suddenly, SPF passes again.

In my experience, SRS is the easiest “why didn’t we do this earlier?” fix for forwarding setups. Whether you’re running Postfix, Exim, or something more exotic, there’s a straightforward way to enable SRS and stop fighting SPF failures on forwarded mail.

When to Use SRS

Use SRS on any system that forwards mail on behalf of other domains. Catch-all forwarders. Aliases that pipe to a personal mailbox elsewhere. Distribution points that just pass through messages unchanged. If your server is a forwarder in any capacity, SRS should be on your shortlist.

One caveat: don’t double-SRS. If mail passes through multiple forwarders, each with SRS, they should detect existing SRS and avoid nesting it endlessly. Good implementations take care of this, but it’s worth checking in testing.

ARC: The Receipt Book for Forwarders and Filters

ARC is like a signed chain of custody for email. It doesn’t rewrite anything. Instead, it records what you verified on the inbound hop—SPF, DKIM, DMARC—and seals that record so downstream providers can decide whether to trust it. When DKIM gets broken by a list footer or subject tweak, and SPF now points at a forwarder, ARC lets the next hop see that, yes, before any changes, the message was legit.

From a policy perspective, DMARC doesn’t “trust” ARC the same way it trusts SPF/DKIM alignment, but major receivers use ARC as a significant signal. If you run a gateway that filters or modifies mail, signing with ARC is a kindness to everyone downstream. And if you’re a forwarder, it can be the difference between “weirdly inconsistent deliverability” and “things just work.”

If you want to dig into the mechanics, you can read the ARC RFC, but you don’t need to memorize it. What matters: validate inbound, write down your results, sign that record with an ARC seal, and forward. Think of ARC as the paper trail that says, “We checked this. Here’s what we found. You can verify that we’re not lying.”

DMARC’s Role and Why Forwarders Need Both SRS and ARC

DMARC ties the room together. It looks for alignment between the visible From domain and either SPF or DKIM. When you forward, SPF alignment is usually lost—unless you perform SRS. DKIM might survive, but any modifications can break it. ARC shows downstream providers that you verified the message before forwarding, which helps when DKIM is altered in transit. The combo looks like this: SRS fixes SPF by making you the responsible sender for the envelope. ARC preserves the “this was valid when we got it” breadcrumb trail for DMARC-friendly receivers.

If you want a quick refresher on the policy mindset, the DMARC overview is a solid primer. But here, the order of operations matters. Do SRS for forwarding first. Then, if you modify mail or you’re a reputational hop that wants to help downstream providers, add ARC. That sequence tends to eliminate the hairiest failures.

Setting Up SRS the Right Way

Postfix with postsrsd

On Postfix, the cleanest path I’ve used is the postsrsd project. It’s a small daemon that handles SRS rewrite and reverse. The 60-second tour:

1) Install postsrsd via your distro or build it. 2) Configure a secret key (for the hash) and set the domain you’ll use for rewritten senders, like srs.yourdomain.com. 3) Add a DNS record so that domain resolves to your MTA and is included in your SPF record. 4) In Postfix, set sender_canonical_maps and recipient_canonical_maps to the postsrsd socket. 5) Reload Postfix and send a test.

What you’re looking for after setup is a rewritten Return-Path that starts with SRS0 or SRS1 and includes your chosen domain. On bounces, the reverse mapping should send non-delivery notifications back to the original sender correctly. If you see “SRS failure” on bounces, check that your secret and hashing parameters didn’t change mid-flight and that reverse rewriting is enabled.

Exim’s Built-in SRS

Exim users have it pretty comfy because SRS support is native. You enable it, set your secret and SRS domain, and wire it into your routers/transports for outbound forwarding. Pay attention to the order of routers; you want SRS to catch forwarded messages, not local deliveries.

A small Exim gotcha I’ve seen: if you use multiple SRS domains or rotate secrets aggressively without tracking rollovers, bounces can get stuck. Keep a short memory of previous secrets so return traffic during the rotation window still verifies.

Other MTAs and Managed Panels

OpenSMTPD and other MTAs support SRS via external tools or patches. On managed panels like cPanel or DirectAdmin, check whether SRS is available and how it’s toggled for domain forwarders vs. virtual aliases. Sometimes it’s on but not for the delivery path you’re actually using. Test each forwarder path individually—aliases, catch-alls, mailing list outputs—and verify Return-Path rewriting on each.

DNS and SPF for SRS

Don’t forget the SPF part for your SRS domain. If your SRS rewrite domain is srs.yourdomain.com, include the IPs or mechanisms needed so SPF passes for that subdomain. Some operators prefer to use the main domain and keep a clean single SPF policy; others isolate SRS on a subdomain. Either works as long as the envelope sender’s domain authorizes your forwarding MTA.

ARC Setup Without the Headache

ARC isn’t hard if you already understand DKIM. You’ll generate a keypair, publish the public key in DNS under a selector, and run a signer that adds ARC headers. The difference is that ARC carries the results of your inbound authentication checks, so you must reliably verify SPF, DKIM, and DMARC on ingress before you seal and forward.

Option A: OpenARC

OpenARC is a sibling project to OpenDKIM. You run it alongside your MTA, typically in milter mode for Postfix or via a similar filter interface for other MTAs. Configure it to:

1) Validate inbound SPF and DKIM (usually via your existing SPF checker and OpenDKIM). 2) Record those results in ARC-Authentication-Results. 3) Sign with ARC-Message-Signature and ARC-Seal using your ARC key. 4) Increment ARC sets properly if the message already has ARC from an upstream hop.

Keep your ARC private keys safe and rotate them like DKIM. And make sure your system clock is accurate; timestamps matter for signature validity.

Option B: Rspamd as Your ARC Swiss Army Knife

If you already run Rspamd for filtering, enabling ARC signing and verification is refreshingly simple. Rspamd can verify SPF/DKIM/DMARC, produce Authentication-Results, and add ARC headers in one place. In my setups, this has been the most reliable way to ensure consistent verification before sealing.

ARC Policies in Practice

One mental model helps: you’re not telling the world “we guarantee this message.” You’re telling the world “we checked this message when it hit our gateway, and here’s what we observed.” That’s useful when downstream changes break DKIM or when forwarders shuffle headers. Major providers read ARC as a trust signal in the bigger story of your mail flow.

Putting It Together: A Clean Forwarding Flow

Here’s a flow that’s served me well when building reliable forwarders:

1) Inbound: Verify SPF, DKIM, and DMARC. Keep a local log of Authentication-Results. 2) Decide if you’ll modify the message. If yes (e.g., adding headers, footers, or subject tags), assume DKIM might break. 3) Before relaying, sign ARC to capture your inbound results and the message state you saw. 4) Apply SRS so your envelope sender is aligned with your infrastructure. 5) Relay to the next hop with TLS where possible. If transport security is your thing—and it should be—check out this friendly playbook on MTA‑STS, TLS‑RPT, and DANE for delivery and security.

That’s the core play. Once you settle on it, the weird intermittents start disappearing. Forwarding stops feeling like a coin toss, and your helpdesk stops living in the logs.

Real-World Testing: The Little Ritual That Saves Hours

I always test forwarding in pairs. First, I send a message from a domain with strict DMARC (p=reject), strong DKIM, and a clear SPF. Then I forward it through the system I’m fixing and inspect the headers at the destination.

Here’s what I look for:

1) Return-Path: Is it SRS-rewritten to my domain or chosen SRS subdomain? 2) Authentication-Results at the final destination: Does SPF pass for the SRS domain? If not, fix SPF records or the SRS domain you used. 3) DKIM: If it fails, is that because of expected modifications? If yes, ARC should still tell the story that it passed on my inbound hop. 4) ARC: Are there valid ARC-Seal headers? If I’m the only ARC hop, is i=1? If I’m in a chain, did I increment properly and include cv=pass if the chain validated?

Then I run the reverse: send from a simple domain with p=none to see baseline behavior without policy pressure. This helps isolate configuration vs. policy side effects. I also sample a few receivers—Gmail, Outlook, and a smaller provider—because they each have personality. Some weigh ARC more, some less, but consistent SRS plus solid ARC signing is remarkably steady across the board.

Common Gotchas I’ve Learned the Hard Way

1) You forgot to authorize your SRS domain in SPF

The message now claims to be from [email protected], but your SPF record doesn’t include the MTA IP for that domain. SPF still fails. Fix your SPF policy to include your forwarder’s sending IPs for the SRS domain or use the main domain consistently.

2) DKIM breaks because you “helpfully” changed things

Mailing list footers, subject tags, and signature rewrites are usual suspects. If you must modify content, ARC is your safety net. It won’t make DKIM pass, but it preserves the fact that it did pass before you touched it.

3) Double-SRS or inconsistent secrets

When mail hops through multiple forwarders, make sure your SRS implementation recognizes SRS’d senders and only rewrites when needed. Also, secret rotation is great—until bounces can’t reverse. Keep a short history of secrets so in-flight bounces decode properly.

4) DMARC alignment confusion

Remember, DMARC checks alignment with the visible From domain, not the Return-Path. SRS fixes SPF’s technical pass, but for DMARC alignment to be happy via SPF, your SRS domain must align with the From domain. In forwarding scenarios, that rarely happens, which is why you lean on DKIM (and ARC as your supporting evidence). Don’t chase impossible alignment; aim for stable signals.

5) ARC without real verification is just noise

ARC is only helpful if your inbound verification is solid. Make sure you’re doing honest SPF/DKIM/DMARC checks and writing accurate Authentication-Results. If you sign ARC but your inputs are garbage, you’re signing confusion.

6) Too many DNS lookups in SPF

Forwarders sometimes bulk up SPF with includes and lookups. Keep it lean. SPF has lookup limits, and exceeding them can mean hard fails at the worst moments. Consolidate where you can.

7) You forgot bounce behavior

Forwarding with SRS should still let bounces find the original sender. Test this. Trigger a non-existent mailbox and watch where the bounce goes. If it lands in a black hole, revisit your SRS reverse mapping.

Operational Tips That Make Life Easier

Rotate DKIM and ARC keys on a sane schedule, and don’t set DNS TTLs so high that rotations take days. Keep NTP in good shape so signatures aren’t timestamp-weird. Log your Authentication-Results on ingress; they’re gold when you investigate a single flaky provider.

When rolling out SRS/ARC in production, consider a gentle ramp. For DMARC, p=none lets you watch aggregate reports and see who fails and why. Once your forwarding is behaving, you can move toward quarantine or reject confidently. If you’re orchestrating broader email reliability and transport security, you might also enjoy how I approach deliverability with MTA‑STS and TLS‑RPT; it complements the authentication story nicely in practice.

Finally, keep your helpdesk scripts updated. When someone says, “It works to my work mailbox but not to my Gmail,” your team should immediately think: check SRS rewrite, check ARC presence, inspect final Authentication-Results. Ten minutes of habit beats two hours of log archaeology.

A Quick Word on Reports and Visibility

DMARC aggregate reports (RUA) are a gift. They tell you how often receivers saw your mail, whether SPF/DKIM aligned, and what policies were applied. For a forwarder, this can be a little noisy since alignment is not always the goal. But it’s still useful to spot trends, misconfigurations, or a broken SRS domain after a DNS change. Even if you don’t obsess over every report, glance weekly during rollout.

On the ARC side, there’s no centralized “reporting” like DMARC. You’ll mostly rely on delivery success, reputation metrics from receivers, and your own logs. That’s fine. ARC’s job is to add context, not to be another dashboard you have to babysit.

Mini Case Study: The Alias That Wouldn’t Behave

A few months ago, a small team had a simple setup: aliases on their domain forwarded to various personal mailboxes. Everything looked fine until a partner tightened DMARC to reject. Suddenly, invoices and support threads vanished when forwarded to Outlook addresses. We enabled SRS on the Postfix host with postsrsd, added the SRS subdomain to SPF, and watched SPF go green at the destination. DKIM still broke occasionally when the CRM added headers on the way out, so we turned on ARC signing in Rspamd. Within a day, delivery stabilized across Gmail and Outlook. No drama. The surprising part wasn’t that it worked—it’s how quickly the mystery disappeared once the right signals were in place.

What Success Looks Like in Your Headers

When you’re done, your forwarded messages will tell a neat little story:

1) Return-Path shows an SRS address at your domain. 2) Authentication-Results at the destination show SPF pass for that SRS domain. 3) If DKIM broke due to an expected modification, ARC headers reflect that it passed when you received it. 4) If DKIM didn’t break, even better; DMARC will be happy via DKIM alignment, and ARC is just an extra breadcrumb for later hops.

That’s the signature of a clean forwarding pipeline: nothing fancy, just consistent signals.

Troubleshooting Playbook: From “Why?” to “Aha.”

When something still misbehaves, I run this dance:

1) Inspect headers at the final mailbox. Find Authentication-Results, ARC-Authentication-Results, and Received-SPF. 2) Confirm whether SPF failed due to using the original sender’s domain. If yes, SRS didn’t trigger or SPF for your SRS domain is wrong. 3) If DKIM failed, compare the body hash to see if a footer or tag caused it. If that’s expected, ARC should still communicate the ground truth from your ingress hop. 4) Look for multiple ARC sets. If there are more than one, make sure yours is the most recent and valid. 5) Check DNS for your ARC/DKIM selectors and SRS domain. Typos and stale keys love to ruin afternoons. 6) Finally, send a minimal, plain-text message through the same path. If that passes cleanly, content modifications are the culprit; not the pipeline.

External Resources Worth a Peek

If you like reading specs or want a deeper dive later, I’ve found these handy to keep bookmarked:

– The ARC RFC (RFC 8617) for the formal model and header formats. – The DMARC overview for a crisp policy refresher. – The postsrsd project for a battle-tested Postfix SRS implementation.

Wrapping It Up: Forwarding Without the Friday Night Fire Drill

Forwarding doesn’t have to be a gamble. The moment you accept that SPF evaluates the current sending server—and that forwarding changes who that is—SRS becomes an obvious fix. You rewrite the envelope sender into a domain you control, SPF passes, and bounces still find their way home. Then you add ARC when you want to preserve a trustworthy record of what was true on ingress, especially if you or someone downstream might touch the message in a way that breaks DKIM. That’s the whole play.

If you’re rolling this out, tackle it step by step: enable SRS on the forwarder and confirm SPF passes at the destination. Then enable ARC signing only after you’re reliably verifying inbound SPF/DKIM/DMARC. Test with a strict DMARC sender and a relaxed one. Read the headers like a story. They always tell you what happened if you know where to look.

And hey, if you’re also polishing the rest of your mail pipeline, tightening transport with MTA‑STS and friends makes a nice companion project. Either way, I hope this clears the fog around forwarding, SPF, DMARC, SRS, and ARC. Set it up once, test it well, and get your Friday nights back. Hope this was helpful! See you in the next post, and may your headers always make sense.