Email Forwarding Breaks DMARC — Fix It with SRS (and Other Options)

December 7, 2025 • February 3, 2026 • Read: 24 min • Views: 11

Was this helpful?

Email forwarding feels like plumbing: you connect A to B, then go home. Until the CEO forwards a vendor invoice to their personal mailbox, it vanishes, and you spend the afternoon explaining “alignment” to people who think DNS is a department.

Forwarding breaks DMARC in ways that are not mysterious, just under-documented in the places busy operators actually look. The good news: you can fix most of it with SRS, plus a couple of boring operational habits that keep you out of incident review.

Why forwarding breaks DMARC (the mechanical failure)

DMARC is simple in concept and brutal in practice. It asks a receiving system:

Does this message authenticate with SPF and/or DKIM?
Do the authenticated identifiers align with the “From:” domain users see?
If not, what does the sender’s published DMARC policy tell me to do?

Forwarding breaks the first part of that chain in a very specific way: it changes the IP address that delivers the message while keeping the visible “From:” header intact.

SPF passes at the original receiver, then fails at the forwarder’s receiver

SPF is evaluated against the connecting IP and the domain in the SMTP envelope sender (Return-Path). When a forwarder relays a message, it becomes the connecting IP. Unless the original sender authorized the forwarder’s IPs in SPF (they didn’t), SPF fails.

At this point, many people say “but DKIM exists.” Yes. And DKIM can save you—until it doesn’t:

If DKIM signature survives intact and aligns with the From domain, DMARC can pass even if SPF fails.
If the forwarder modifies the message (footer, subject tags, line wrapping, MIME re-encoding), DKIM can break.

DMARC only needs one of SPF or DKIM to pass and align. Forwarding commonly causes SPF to fail. Mailing lists and some “helpful” gateways commonly cause DKIM to fail too. That’s your DMARC failure.

Alignment: the part people skip, then regret

Even when SPF technically passes, DMARC can still fail due to misalignment. Alignment compares the domain that authenticated (SPF domain or DKIM d= domain) to the domain in the visible From header.

If your forwarder rewrites the envelope sender but does it with a domain that doesn’t align with the From domain, DMARC still fails unless DKIM passes and aligns. This is why “we enabled SRS but it didn’t help” is sometimes real: SRS fixes SPF results, but not alignment with From, unless you also ensure DKIM alignment or accept that SPF alignment will be with the forwarder domain.

One dry truth: DMARC wasn’t designed to make forwarding easy. It was designed to make spoofing expensive. Forwarding is collateral damage.

Joke #1: Email forwarding is like moving someone else’s mail by hand—eventually you’ll be accused of forging the handwriting.

Facts and short history that explain today’s mess

Some context helps because DMARC debates get emotional fast, like sports, religion, and which MTA config format is “readable.” Here are concrete facts that shape the forwarding problem:

SPF checks the path, not the content. It validates where mail came from (connecting IP) relative to the envelope sender domain.
DKIM checks the content, not the path. It signs message headers/body; forwarding can preserve it if nothing changes.
DMARC was published in 2015 as an RFC (7489). It unified policy and reporting around SPF/DKIM plus alignment.
Forwarding predates SPF/DKIM by decades. The original SMTP model assumed trust between operators. That era is over.
Yahoo and AOL tightened DMARC policies in 2014. Mailing lists broke loudly; the industry started taking DMARC seriously because inboxes suddenly went empty.
Many enterprise gateways modify mail “for safety.” Disclaimers, DLP tags, and content re-wrapping routinely invalidate DKIM signatures.
SRS existed before DMARC became mainstream. It was built to make SPF survive forwarding by rewriting the envelope sender.
ARC (Authenticated Received Chain) is newer. It’s a way for intermediaries to vouch for upstream authentication results when messages are transformed.
DMARC enforcement is receiver-driven. Even with “p=none,” receivers can apply local policies; with “quarantine” or “reject,” your forwarded mail is living dangerously.

Failure modes: what breaks, what survives

Case 1: Simple forward, no modifications

Typical: user@forwarder.example forwards to user@gmail.com.

SPF at Gmail: fails (forwarder IP not authorized by original Return-Path domain).
DKIM at Gmail: likely passes (message unchanged).
DMARC: passes if DKIM aligns with From.

This is why some forwarding “works fine” for years, until a vendor changes DKIM selectors or you add a footer. Then it doesn’t.

Case 2: Forwarder adds a footer/disclaimer

Common in corporate mail: “This email may be confidential…” appended at the bottom.

SPF: fails (same reason).
DKIM: fails (body changed).
DMARC: fails hard, especially if sender publishes “p=reject”.

Case 3: Mailing list explodes DKIM and SPF

Mailing lists often:

rewrite Subject (e.g., “[list]”),
modify body (footer, unsubscribe info),
re-send using list servers.

That breaks DKIM; SPF won’t align because list servers aren’t in the original domain’s SPF. DMARC fails unless the list does mitigations (From rewriting, ARC, or re-signing with aligned DKIM if possible).

Case 4: “Preserve header From, but change envelope sender”

This is what SRS does: it rewrites the MAIL FROM / Return-Path while leaving the header From intact.

Result:

SPF can pass because the forwarder is authorized to send for its own SRS domain.
DMARC still requires alignment: SPF alignment will be with the SRS domain (the forwarder), not the original From domain.
Therefore: DMARC will only pass via SPF if the forwarder’s rewritten MAIL FROM domain aligns with the header From domain (usually it won’t), so DKIM alignment remains important.

This is a point that gets mangled in meetings. SRS primarily prevents SPF-based rejection and reduces backscatter issues. It does not magically make DMARC alignment with the original From happen. It makes forwarding less broken, not perfectly clean.

SRS: the fix that actually matches the problem

SRS (Sender Rewriting Scheme) rewrites the SMTP envelope sender so that SPF checks evaluate against the forwarder’s domain. That prevents the forwarded message from failing SPF due to the forwarder’s IP. It also ensures bounces return to the forwarder so it can route DSNs correctly back to the original sender, instead of creating backscatter.

What SRS changes, concretely

Before forwarding:

MAIL FROM: <alice@sender.example>
From: Alice <alice@sender.example>

After forwarding with SRS (example):

MAIL FROM: <SRS0=hash=timestamp=sender.example=alice@forwarder.example>
From: Alice <alice@sender.example> (unchanged)

Now the receiving system evaluates SPF for forwarder.example against the forwarder’s connecting IP, and it passes. That’s the goal.

Why SRS is still worth doing

Because without it, SPF is guaranteed to fail on forwarded mail unless the original domain did something unusual. SPF failure is not always fatal to DMARC, but it’s a big chunk of the authentication story. With SRS, you at least stop breaking SPF in ways that are entirely predictable.

SRS does not solve DKIM breakage

If your forwarder modifies messages (disclaimers, link rewriting, attachment scanning that re-encodes), DKIM will still fail. SRS can’t help. The fix there is: stop modifying mail you don’t own, or implement ARC to preserve upstream auth assertions, or rewrite From (which changes user-visible identity and is politically painful).

Where SRS belongs in the architecture

SRS should live at the forwarding boundary: the place where you accept a message and then send it onward to a different domain while preserving the original From.

Do not bolt SRS onto every outbound mail path blindly. It makes troubleshooting harder and can confuse bounce processing. Use it for forwarding flows only.

Other options: DKIM preservation, ARC, and “don’t forward”

Option A: Preserve DKIM by not touching the message

If you can forward mail without modifying it, do that. Many organizations break DKIM for no good reason.

Examples of avoidable DKIM-breaking behavior:

Appending legal disclaimers to every inbound message (you don’t own the content).
Rewriting URLs for click tracking on forwarded mail (especially for external senders).
Converting MIME structures “for normalization.”

Choose to be boring. Boring is reliable.

Option B: ARC for intermediaries that must transform mail

ARC (Authenticated Received Chain) lets an intermediary record the authentication results it observed when it received the message, then sign that record. A downstream receiver can decide to trust the intermediary’s ARC assertions even if DKIM broke later.

ARC is not a silver bullet:

Receivers choose whether to trust your ARC chain.
ARC adds complexity and key management.
If your forwarder is frequently abused, your ARC reputation will suffer.

Use ARC when you must modify messages (mailing lists, security gateways) and you have the operational maturity to manage keys, monitor failures, and keep your relays clean.

Option C: From rewriting (mailing list style)

Mailing lists often rewrite the header From domain to one they control (e.g., “alice via list.example”). That aligns authentication with a domain the list can legitimately sign and authorize.

This “works” technically. It also changes user-visible identity, breaks reply workflows, and causes political arguments with the kind of intensity normally reserved for office seating plans.

Option D: Stop forwarding; use proper delegated access

If the business reason for forwarding is “I want to read my corporate mail in my personal mailbox,” the correct solution is usually delegated access or a client configuration, not SMTP forwarding.

Forwarding pushes identity, compliance, retention, and incident response into a hole you can’t monitor. If you’re responsible for production systems, you don’t build blind spots on purpose.

Joke #2: The only thing more persistent than forwarded email is the calendar invite that follows it around forever.

Fast diagnosis playbook

You have a report: “forwarded emails are missing” or “customers say they never got the message.” Don’t start by staring at DMARC aggregate reports for hours. Start with a single failing message and walk the chain.

First: identify where the drop happens

Was it accepted by the forwarder’s inbound MTA?
Was it relayed outbound from the forwarder?
Was it rejected or quarantined by the final receiver?

Second: check authentication results at the final hop

SPF result (pass/fail/softfail/neutral).
DKIM result (pass/fail, which d= domain signed).
DMARC result (pass/fail, which identifier aligned).

Third: confirm whether the forwarder changed the content

Compare headers and body before/after forwarding if possible.
Look for disclaimers, subject tags, MIME boundary changes.
Check whether a security appliance “rewrote links.”

Fourth: choose the fix based on the failure

SPF fails, DKIM passes: you can deploy SRS to reduce fragility, but you may already be DMARC passing via DKIM. Decide based on how often DKIM breaks in your environment.
SPF fails, DKIM fails: you need to stop modifying content or implement ARC or rewrite From. SRS alone won’t save you.
SPF passes, DMARC fails: alignment issue—your authenticated domain doesn’t align with header From. Fix your DKIM alignment or adjust rewriting strategy.

Paraphrased idea (Werner Vogels): “Everything fails; design so you can detect it quickly and recover automatically.” That applies to mail flows more than anyone wants to admit.

Practical tasks with commands, outputs, and decisions

Below are hands-on tasks you can run on a typical Linux mail relay (Postfix examples) or from an admin workstation. Each task includes: command, sample output, what it means, and the decision you make.

Task 1: Confirm the DMARC policy for the sender domain

cr0x@server:~$ dig +short TXT _dmarc.sender.example
"v=DMARC1; p=reject; rua=mailto:dmarc@sender.example; adkim=s; aspf=s"

What it means: The sender asks receivers to reject failing messages; strict alignment for DKIM and SPF.

Decision: If you forward mail from this domain, you must preserve DKIM alignment or expect rejection. SRS won’t align SPF to sender.example.

Task 2: Check SPF record for the sender domain (to understand why forwarding fails)

cr0x@server:~$ dig +short TXT sender.example
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

What it means: Only the listed IP range and provider are allowed. Your forwarder is not.

Decision: Expect SPF fail after forwarding unless you apply SRS (or the sender adds your forwarder, which they won’t).

Task 3: Validate that your forwarder domain has SPF allowing its own outbound IPs

cr0x@server:~$ dig +short TXT forwarder.example
"v=spf1 ip4:198.51.100.10 -all"

What it means: Your forwarder can legitimately send mail using its own domain.

Decision: SRS can be anchored on forwarder.example because SPF will pass for your outbound relay IP.

Task 4: Inspect a message’s Authentication-Results (from the final receiver)

cr0x@server:~$ grep -iE 'authentication-results|dmarc=|spf=|dkim=' message.eml | head -n 8
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@sender.example does not designate 198.51.100.10 as permitted sender) smtp.mailfrom=alice@sender.example;
       dkim=pass header.i=@sender.example header.s=s1 header.b=abc123;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender.example

What it means: SPF failed due to forwarding IP, but DKIM passed and aligned, so DMARC passed.

Decision: If your forwarding chain sometimes modifies content, you’re one disclaimer away from outages. Consider SRS and/or removing modifications.

Task 5: Inspect Postfix logs for rejection at the next hop

cr0x@server:~$ sudo grep -E "status=bounced|reject:|dmarc" /var/log/mail.log | tail -n 10
Jan 03 10:22:11 mx postfix/smtp[24190]: 9C2B81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=1.2, delays=0.1/0.0/0.6/0.5, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 This message does not pass authentication checks (SPF and DKIM both fail) 550-5.7.26 and has a DMARC policy of reject. (in reply to end of DATA command))

What it means: Final receiver rejected due to DMARC fail; both SPF and DKIM failed.

Decision: SRS alone won’t fix this if DKIM is failing due to modification. Find what changed the message or implement ARC / stop transformations.

Task 6: Confirm whether you are modifying messages (header/body) in transit

cr0x@server:~$ sudo postconf -n | egrep 'header_checks|body_checks|milter|content_filter'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
header_checks = regexp:/etc/postfix/header_checks
content_filter = smtp-amavis:[127.0.0.1]:10024

What it means: Milters and content filters are active; header checks can rewrite; amavis can re-encode.

Decision: Assume DKIM will break sometimes. Either bypass filtering for forwarded mail, preserve DKIM, or add ARC and accept the operational cost.

Task 7: Check if header_checks are adding disclaimers or tags

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/header_checks
/^Subject:/ PREPEND X-Company-Notice: scanned
/^From:/    PREPEND X-Forwarded-By: forwarder.example

What it means: You are modifying headers. Header modification can invalidate DKIM if the altered header is signed.

Decision: Stop doing this for forwarded mail, or ensure the modified headers are not in the DKIM signed header list (often not possible to guarantee).

Task 8: Confirm the forwarding flow uses a dedicated transport (so you can apply SRS selectively)

cr0x@server:~$ sudo postconf -n | egrep 'transport_maps|sender_dependent_default_transport_maps'
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo postmap -q user@forwarder.example /etc/postfix/transport
forward-srs:

What it means: This recipient is routed via a custom transport named forward-srs.

Decision: Good. You can apply SRS only on that transport, instead of rewriting everything and creating new mysteries.

Task 9: Install and enable SRS support (example: postsrsd)

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y postsrsd
...output...
Setting up postsrsd (1.10-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/postsrsd.service → /lib/systemd/system/postsrsd.service.

What it means: postsrsd is installed and enabled as a system service.

Decision: Proceed to configure Postfix to call the SRS daemon, but only for forwarding paths if you can.

Task 10: Check postsrsd is running and listening

cr0x@server:~$ systemctl status postsrsd --no-pager
● postsrsd.service - PostSRSd
     Loaded: loaded (/lib/systemd/system/postsrsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-03 10:12:44 UTC; 8min ago
   Main PID: 1827 (postsrsd)
     Tasks: 1
     Memory: 1.2M
     CGroup: /system.slice/postsrsd.service
             └─1827 /usr/sbin/postsrsd -d -p 10001 -s forwarder.example

What it means: The daemon is running and configured with SRS domain forwarder.example, listening on port 10001.

Decision: You can now point Postfix sender_canonical_maps or a dedicated cleanup service at it.

Task 11: Configure Postfix to use SRS for envelope sender rewriting (example pattern)

cr0x@server:~$ sudo postconf -n | egrep 'sender_canonical_maps|sender_canonical_classes|recipient_canonical_maps'
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:127.0.0.1:10001

What it means: Postfix will rewrite the envelope sender through the TCP map (postsrsd) for all mail using sender_canonical_maps.

Decision: If this is too broad, back up and scope it: apply via a dedicated transport or service, not global defaults.

Task 12: Reload Postfix and confirm configuration sanity

cr0x@server:~$ sudo postfix check
...output...
cr0x@server:~$ sudo systemctl reload postfix
...output...

What it means: Postfix accepted the configuration.

Decision: Proceed to a controlled test: forward a signed message from a strict DMARC domain and inspect the resulting Return-Path and auth results.

Task 13: Send a test message and confirm SRS rewriting occurred

cr0x@server:~$ sudo grep -E "from=<|to=<|srs" /var/log/mail.log | tail -n 20
Jan 03 10:28:01 mx postfix/cleanup[25102]: 1A2B312345: message-id=<test-170428@sender.example>
Jan 03 10:28:01 mx postfix/qmgr[901]: 1A2B312345: from=<SRS0=HHH=TT=sender.example=alice@forwarder.example>, size=18234, nrcpt=1 (queue active)
Jan 03 10:28:02 mx postfix/smtp[25106]: 1A2B312345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, dsn=2.0.0, status=sent (250 2.0.0 OK ...)

What it means: The envelope sender was rewritten to SRS0=…@forwarder.example and the message was accepted by Gmail.

Decision: You have reduced SPF-related breakage. Now verify DMARC outcome on the receiver side; if DKIM fails due to modifications, SRS won’t save you.

Task 14: Verify you are not creating open relay conditions while “fixing forwarding”

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

What it means: Relay is limited to trusted networks and authenticated users; unauth destinations are deferred.

Decision: Keep it this way. SRS adds legitimacy to your outbound mail; you don’t want attackers borrowing that legitimacy.

Task 15: Look for signs DKIM is being broken by transformation appliances

cr0x@server:~$ grep -iE 'amavis|altered|footer|disclaimer|repack|mime' /var/log/mail.log | tail -n 15
Jan 03 10:25:33 mx amavis[2201]: (02201-11) Passed CLEAN, but modified headers: added X-Virus-Scanned
Jan 03 10:25:33 mx amavis[2201]: (02201-11) body modified: appended disclaimer

What it means: The content is being changed. DKIM signatures from external senders will likely fail after this point.

Decision: For forwarding flows, bypass modifications or implement ARC. If your security team refuses, be honest: some forwarded mail will be rejected, and it’s not a bug, it’s policy.

Task 16: Verify ARC headers are present (if you deploy ARC)

cr0x@server:~$ grep -iE '^ARC-Seal:|^ARC-Message-Signature:|^ARC-Authentication-Results:' message.eml | head -n 10
ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=alice@sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...

What it means: The forwarder is asserting what it saw at receipt time and signing that assertion.

Decision: Confirm downstream receivers you care about actually use ARC signals. If not, ARC may not improve deliverability enough to justify complexity.

Three corporate mini-stories (pain, regret, and one win)

Mini-story 1: The incident caused by a wrong assumption

The company had a “simple” forwarding rule: all mail to acquisitions@corp.example forwarded to a deal team address hosted at a different provider. It had worked for years. Everyone assumed it was fine because there were no tickets.

Then a major partner upgraded their email authentication posture: DMARC went from p=none to p=reject with strict alignment. The forwarder still relayed mail exactly as before. SPF failed at the new provider (as it always had). DKIM would have saved it—except the corporate gateway appended a compliance disclaimer to all outbound mail, including forwarded mail. DKIM broke.

The first symptom wasn’t a bounce. It was silence. The partner’s procurement team believed the company was ghosting them. Internal folks blamed “the vendor’s spam filter,” then blamed “our provider,” then blamed each other, which is the traditional order of operations.

The fix was humbling: they disabled disclaimer injection for the forwarding transport, deployed SRS for envelope sender rewriting, and added a rule: anything that forwards externally must not be mutated unless the business accepts the risk. There was no magical “turn on DMARC” switch. Just specific plumbing decisions.

Mini-story 2: The optimization that backfired

A different org wanted to reduce latency and external dependencies. They consolidated several small MTAs into one “smart relay” that performed antivirus scanning, DLP tagging, URL rewriting, and header normalization. It was a neat box: fewer systems, fewer alerts, a dashboard that looked confident.

Then they enabled aggressive URL rewriting for threat protection. That changed message bodies routinely. DKIM signatures from external senders started failing. Most direct deliveries survived because SPF aligned and passed. Forwarded messages did not: SPF failed after forwarding, DKIM failed due to rewriting, DMARC failed, and strict senders got rejected.

The optimization “worked” by their chosen metrics—fewer servers, fewer moving parts—while quietly degrading deliverability for a specific set of business-critical workflows: forwarded mail, ticketing system notifications routed to personal mailboxes, and a few external vendor feeds.

They clawed back by building a bypass lane: messages identified as pure forwards (based on routing and recipient class) skipped body modification and URL rewriting. Security wasn’t thrilled, but they accepted it after seeing that the alternative was non-delivery with no user recourse. The best security control is the one that still allows the business to function.

Mini-story 3: The boring but correct practice that saved the day

A financial services team had a rule: any mail-handling change must be tested with a known set of external domains that publish strict DMARC policies. They kept a small corpus of test messages (DKIM signed, varied MIME types) and ran them through their relays before and after changes.

One day they upgraded a milter package. The release notes were vague but the change looked minor. Their pre-change test suite immediately showed DKIM failures on forwarded messages; the milter had started re-wrapping long lines and normalizing whitespace. SPF already failed on forwarded mail, so DMARC was now failing too.

Because they caught it before production rollout, they had options: pin the milter version, adjust configuration to avoid canonicalization changes, and apply SRS where needed. No incident. No executive escalation. No “email is down” banner in chat.

The practice was dull: a test harness, a checklist, and a small amount of paranoia. It saved them from learning the lesson in public.

Common mistakes: symptoms → root cause → fix

1) Symptom: Forwarded mail disappears, no bounce

Root cause: Final receiver silently quarantines or rejects based on DMARC; bounces may go to rewritten or invalid Return-Path, or are suppressed.

Fix: Inspect Postfix logs for DSN 5.7.26/5.7.1. Add a monitored mailbox for bounces, and ensure SRS is configured so DSNs route back to you. If DKIM is being modified, stop modifications or adopt ARC.

2) Symptom: SPF fail on every forwarded message

Root cause: Normal behavior. Forwarder IP isn’t authorized by the original sender’s SPF record.

Fix: Implement SRS at the forwarder boundary. Do not ask third parties to add your IPs to their SPF; that’s not how the world works.

3) Symptom: DKIM fails only after you enabled “legal disclaimer”

Root cause: Footer injection modifies message body; DKIM signature no longer matches.

Fix: Disable footer injection for forwarded mail and mailing list mail, or apply it only to mail you originate. If you must add notices, do it at the client/UI layer, not the SMTP payload.

4) Symptom: DMARC fails even though SPF passes

Root cause: SPF passes for a domain that doesn’t align with header From (e.g., using a bounce domain or third-party relay domain).

Fix: Ensure the domain used for SPF authentication aligns with header From (organizational alignment relaxed/strict depends on sender policy). Otherwise rely on aligned DKIM.

5) Symptom: Some providers accept forwarded mail, others reject

Root cause: Different receivers weigh DKIM/SPF/ARC differently; some enforce stricter DMARC or have local anti-abuse policies.

Fix: Engineer for strict receivers: preserve DKIM, avoid transformations, and deploy SRS. Treat “works at Provider A” as anecdote, not validation.

6) Symptom: Bounce storms or backscatter after forwarding

Root cause: Forwarder keeps original MAIL FROM, so DSNs go to the original sender even when the forwarder caused the issue, or to forged senders when spam is involved.

Fix: SRS. Also ensure you reject unauthenticated mail at SMTP time where possible to avoid generating DSNs for junk.

7) Symptom: ARC added, but nothing improved

Root cause: Receivers don’t trust your ARC chain (reputation), or you’re not sealing correctly, or your modifications are too extreme.

Fix: Validate ARC signatures, keep your relays clean, and don’t assume ARC is universally honored. If you can avoid modifications, do that instead.

Checklists / step-by-step plan

Plan A: You run a forwarder and want forwarding to “mostly work”

Inventory forwarding paths. List all rules, aliases, and mailbox-level forwards that send externally.
Separate forwarding traffic. Use a dedicated Postfix transport or instance for forwards.
Deploy SRS on that path. Ensure your forwarding domain has SPF authorizing the sending IPs.
Stop modifying forwarded mail. No footers, no subject tags, no URL rewriting. If security needs scanning, do it in a way that preserves message bytes.
Test with strict DMARC domains. Use a repeatable set of test messages and validate Authentication-Results at final recipients.
Monitor rejects by DSN codes. Alert on spikes in 5.7.26, 5.7.1, and “DMARC policy of reject.”
Keep a rollback. SRS and filters touch core mail behavior. Make it reversible without heroics.

Plan B: You operate a mailing list or gateway that must modify messages

Decide on identity strategy. Either rewrite From (works but user-visible) or invest in ARC and hope receivers trust you.
If using ARC: manage keys, rotate safely, monitor validation. Treat it like TLS cert ops: boring, scheduled, documented.
Minimize modifications anyway. Every transform is a DKIM break lottery ticket.
Provide user guidance. For strict domains, explain that direct subscription or allowlisting may be required.

Plan C: You’re a corporate IT team and people want mail forwarded to personal accounts

Don’t do it by default. Forwarding is exfiltration plus deliverability risk disguised as convenience.
Offer supported alternatives. Mobile device management, delegated access, secure webmail, or managed client configs.
If you must allow it: require MFA, apply SRS, and prohibit message modification on that forwarding lane.
Make it visible. Log and audit external forwarding rules. Treat them like data egress controls, because that’s what they are.

FAQ

1) Does SRS “fix DMARC” for forwarded mail?

No. SRS fixes SPF survivability through forwarding by rewriting the envelope sender. DMARC can still fail if DKIM fails and SPF alignment doesn’t match the visible From domain.

2) If DKIM passes, do I still need SRS?

Often yes, for resilience and bounce handling. DKIM can be brittle when mail is modified by gateways. SRS also reduces backscatter and makes your forwarding behavior more standards-friendly.

3) Why can’t the original sender just “allow” my forwarder in SPF?

Because SPF is a publish-once authorization mechanism for a domain’s legitimate senders. Adding random forwarders would be operationally impossible and increases abuse surface.

4) What about forwarding within the same provider?

It depends. Some providers implement internal forwarding that preserves authentication context, sometimes using proprietary mechanisms. But once you cross administrative boundaries and new outbound IPs, SPF will bite.

5) Can I re-sign DKIM at the forwarder to make DMARC pass?

You can sign with your own domain, but that won’t align with the original From unless you also rewrite From. Re-signing can help receivers evaluate integrity, but it doesn’t solve alignment on its own.

6) Is ARC widely supported?

Supported by major mailbox providers to varying degrees, but not consistently enough to treat as a guarantee. ARC is best viewed as a signal that helps some receivers some of the time.

7) What’s the biggest operational risk of SRS?

Mis-scoping it. If you rewrite envelope senders for mail that shouldn’t be rewritten, you can break bounce processing and complicate troubleshooting. Apply it to forwarding paths.

8) How do I know if my system is breaking DKIM?

Look for transformations: disclaimers, URL rewriting, MIME normalization, subject tags. Then confirm by comparing Authentication-Results at receipt vs after relay, or by observing DKIM=fail downstream.

9) If I stop modifying mail, will forwarding always work?

Not always. DKIM might be absent, misconfigured, or use fragile canonicalization. But stopping modifications removes a major self-inflicted failure mode and improves odds significantly.

10) What should I tell the business when forwarded mail from strict senders still fails?

Tell them the truth: modern anti-spoofing policies treat forwarding as risky unless you preserve DKIM or use supported mitigations. Offer alternatives to forwarding for critical workflows.

Next steps you can actually do this week

If you run forwarding in production, treat it like any other reliability surface: measure it, isolate it, and stop making “small harmless changes” to the payload.

Pick one failing message and trace it end-to-end. Confirm whether SPF, DKIM, or alignment is the actual failure.
Remove content mutation from forwarded flows. Disclaimers on someone else’s mail are not a compliance win; they’re a deliverability debt.
Deploy SRS on the forwarding boundary to prevent predictable SPF failures and tame bounce behavior.
Decide if ARC is worth it for flows that must transform mail. If you can avoid transformation, do that instead.
Write down your policy: which forwarding is supported, which is prohibited, and what users should do instead.

Forwarding didn’t get worse; the ecosystem got less tolerant of ambiguous identity. That’s progress. It just means the plumbing needs real engineering now.