Why Email Forwarding Breaks SPF—and What SRS and ARC Actually Fix

Email forwarding creates a second SMTP delivery. The original sender connected to the forwarding provider, then the forwarding provider connected to the final mailbox. SPF evaluates the server making the current connection, so a message that passed SPF on the first hop can fail on the second even though nobody forged it.

Three controls are often presented as interchangeable fixes, but they protect different evidence. SRS rewrites the envelope sender so the forwarder’s delivery can pass SPF and bounces can return through that forwarder. DKIM can preserve an aligned author signature when the message is not modified. ARC records what an intermediary observed so the final receiver can apply informed local policy. None is a universal “make DMARC pass” switch.

This explanation is for domain owners, mail administrators, help-desk teams and technically curious site owners who can obtain raw message headers. It assumes no prior knowledge of SMTP envelopes: the relevant identities are defined as the message crosses each boundary.

Follow one message across two SMTP connections

Suppose [email protected] sends mail to [email protected], which forwards to a mailbox at another provider. People see one message, but receiving systems see two deliveries.

The direct hop has matching evidence

On the first connection, an outbound server authorized by example.org presents an envelope sender such as [email protected]. The receiving forwarder checks that connecting IP against the SPF policy published for the envelope domain. If the authorization is valid, SPF can pass.

The visible From: field also says [email protected], but SPF does not authenticate that header directly. DMARC later asks whether a passing SPF domain or passing DKIM signing domain aligns with the visible From domain.

Forwarding changes the connecting server

During the second connection, the final receiver sees the forwarding server’s IP. If the forwarder leaves MAIL FROM:<[email protected]> unchanged, the receiver asks whether the forwarder’s IP is authorized by example.org. Usually it is not, because the forwarder is not one of Alice’s outbound systems.

That behavior follows the SPF evaluation model in RFC 7208: the checked identity is the SMTP MAIL FROM domain, or the HELO identity when the reverse path is empty. SPF does not carry a reusable pass token from the first connection.

SPF is correct to distrust the new hop

Authorizing every possible forwarder in the original sender’s SPF record would be both impractical and unsafe. A domain controls its own outbound systems; it does not control every alias, alumni address, help-desk redirect or recipient-side rule that might relay a message later.

Adding the forwarder’s IP to example.org would also authorize that system to use the domain’s envelope identity for unrelated mail. The right repair must be owned by the intermediary that creates the new SMTP connection, not by arbitrary original senders.

DNS availability still matters because receivers must retrieve SPF, DKIM and DMARC records. A temperror caused by lookup failure is different from an SPF fail; operators facing inconsistent authenticated results should first investigate DNSSEC validation failures instead of editing authentication records during a resolver incident.

SRS repairs the forwarding envelope, not the visible author

Sender Rewriting Scheme changes the envelope sender to an address in a domain controlled by the forwarder. Conceptually, the second hop becomes:

Envelope sender domain: forwarder.test (SRS-rewritten)
Visible From domain: example.org

The exact SRS address format depends on the implementation. Its important properties are a forwarder-owned domain, a protected reversible mapping to the original return path and an expiry boundary. The forwarder publishes SPF authorization for its SRS domain, so the final receiver can evaluate the forwarding server against an identity that server legitimately controls.

Microsoft’s SRS documentation also emphasizes bounce handling: non-delivery reports sent to the rewritten address must be decoded and routed back to the original sender. A rewrite that passes SPF but loses legitimate bounces is incomplete.

Why SRS alone does not align SPF for DMARC

DMARC SPF alignment compares the authenticated envelope domain with the visible From domain. After SRS, those domains are normally forwarder.test and example.org. SPF may pass for the rewritten envelope while SPF alignment for DMARC remains false.

That is not a defect in SRS. SRS owns forwarding authorization and return-path continuity; it does not claim that the forwarder became the visible author. The DMARC identifier-alignment rules in RFC 7489 keep those roles separate.

If you operate the forwarder, use a dedicated SRS domain or subdomain with controlled DNS, signing secrets, monitoring and documented retention. Teams that are unsure who may change those records should first establish domain, DNS and hosting ownership because an authentication repair without a named DNS owner is difficult to maintain or reverse.

DKIM can preserve the original author’s aligned proof

DKIM signs selected headers and a canonicalized form of the message body. A forwarder may change the SMTP envelope without breaking DKIM because the envelope is outside the signed message. If the original signature still verifies and its d= domain aligns with the visible From domain, DMARC can pass through DKIM even when forwarded SPF fails or SRS SPF is not aligned.

Preservation has limits. Subject tags, mailing-list footers, MIME conversion, body rewriting and changes to signed headers can invalidate the signature. Even harmless-looking modifications may change the bytes covered by the signature’s canonicalization rules.

Forwarders should therefore avoid rewriting From: or modifying content unless their actual product requires transformation. Original senders need stable signing keys and selectors; Voxfor’s DKIM selector-overlap guide explains how to rotate those keys without making forwarded mail depend on a DNS swap race.

According to RFC 6376, a DKIM pass establishes responsibility for a signed message through the signing domain. It does not prove that every intermediary was benign, nor does it repair a signature after a forwarding system changes covered content.

ARC preserves a chain of observations, not a guaranteed verdict

Authenticated Received Chain lets an intermediary record the authentication results it observed, sign the message as it handled it and seal those records into an ordered chain. RFC 8617 describes this as an authenticated chain of custody.

For a forwarder, an ARC set can say that SPF, DKIM or DMARC had a particular result before later handling changed the evidence. The next receiver validates the ARC chain and decides how much confidence to place in the sealer and the recorded result.

ARC does not change the current SPF result, restore broken DKIM bytes or force DMARC to pass. It supplies signed context to the final receiver’s local policy. A valid ARC chain from an unknown or poorly operated intermediary is not equivalent to a trusted result, and receivers are free to weigh ARC differently.

These controls complement each other: preserve author proof with DKIM where possible, and record trustworthy intermediary evidence with ARC where forwarding changes the path. Neither makes the other redundant.

Choose the control by the broken layer

One message can contain several simultaneous results. Read them as separate claims before changing policy.

The last row matters operationally. status=sent at a Postfix relay proves that the next SMTP system accepted the message, not that a user saw it. Use Postfix queue evidence to separate transport acceptance from later forwarding, filtering or mailbox placement.

Test the path with headers from both routes

Create controlled direct and forwarded deliveries to the same final provider. Use a sender domain you administer, a unique subject marker and an address that does not contain real customer data. Avoid relying on a single provider pair because receiver policy can hide a defect that another destination exposes.

Capture evidence at each boundary

For each copy, save the raw headers and the SMTP or forwarding log entry. Record:

• the connecting host seen by each receiving boundary;
• the envelope sender before and after forwarding;
• spf=, dkim= and dmarc= results plus the domains each result evaluated;
• ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal instances where present;
• final delivery or rejection status, including the enhanced SMTP code;
• whether a controlled non-delivery report returns to the real original sender.

Start reading Authentication-Results from the final provider’s trusted boundary. Message headers can contain older or attacker-supplied fields, so the mere presence of an authentication-looking line is not proof that the receiver trusted it. Return-Path is normally inserted at final delivery and reflects the envelope seen there; compare it with logs rather than treating it as an immutable original header.

Define acceptance before changing policy

A useful forwarding test passes when the direct copy and forwarded copy reach the intended mailbox, the forwarded hop uses an authorized envelope identity, an aligned DKIM signature survives when expected, ARC validates when the forwarder claims to seal it, and a forced bounce reaches the original sender without becoming a backscatter path.

Do not lower a DMARC policy merely to make one test disappear. First locate whether the failing claim belongs to the connection, envelope, signed message, custody chain or mailbox. If delivery itself fails under disk or metadata pressure, Dovecot Maildir inode recovery addresses that storage boundary; authentication changes will not create free inodes.

Common shortcuts that create a different problem

Adding the forwarder to every sender’s SPF: recipients do not control arbitrary senders’ DNS, and broad authorization expands who may use the sender’s envelope domain.

Rewriting the visible From field: this may avoid one alignment result by changing the author identity users see, but it changes reply behavior and message semantics. Mailing lists have distinct transformation requirements; a transparent alias normally should not impersonate the forwarder as author.

Treating ARC as a DMARC override: ARC provides evidence for local policy. A receiver may accept a message because it trusts a valid chain, yet the current DMARC evaluation can still report failure.

Assuming SRS fixes every forward: SRS repairs the envelope and bounce route. Content modification can still break DKIM, and ARC quality still depends on correct sealing and receiver trust.

Testing only inbox arrival: spam placement or acceptance can change without proving the intended identity path. Keep the raw headers, logs and bounce result as the reproducible record.

Keep the three verdicts separate

Forwarded mail is easier to reason about when every result retains its scope. SPF answers whether the current connecting server may use the current envelope domain. DKIM answers whether the signed message still verifies for its signing domain. ARC answers whether a receiver can validate an intermediary’s chain of authentication observations.

SRS belongs between the first and second answers: it gives the forwarding hop an envelope identity it owns and a reversible return path. A sound deployment proves all four boundaries—connection, envelope, signed content and custody—without pretending that one pass erases the others.