Email Forwarding and Redirection, Explained

Forwarding looks trivial - a message arrives for one address and is sent on to another - but it is where email authentication quietly falls apart. The moment a forwarder relays a message from its own IP, the original domain’s SPF no longer matches; the moment a mailing list adds a footer or a subject tag, the original DKIM signature no longer verifies. Both failures cascade into DMARC, and the cascade is exactly what RFC 7960 was written to document. This guide explains precisely what breaks, what survives, and the mechanisms - Sieve redirect, .forward/aliases, list rewriting, SRS, and ARC - that try to limit the damage.

The 60-second version

• SPF breaks on forwarding by design. The forwarder’s IP is not in your SPF record, so the receiver sees an unauthorized IP for your domain (RFC 7960 §2.2).
• DKIM survives a clean forward because it signs content, not the connecting IP - unless the forwarder modifies the signed parts. Mailing lists almost always do (RFC 7960 §2.3, §3.2.3).
• Sieve redirect (RFC 5228) is server-side forwarding that makes no body/header changes but cancels the implicit “keep”; redirect :copy (RFC 3894) keeps a local copy too.
• SRS (Sender Rewriting Scheme) rewrites the envelope MAIL FROM/Return-Path to the forwarder’s domain so SPF passes for the hop - but it does not fix DMARC alignment to the original From:.
• ARC (RFC 8617) preserves the original authentication verdict across hops so a final receiver may honor it - advisory, not a pass (see the ARC deep dive).
• The durable fix is aligned DKIM that survives the relay, plus minimizing message modification.

Why SPF breaks (and why that is not your fault)

SPF authorizes IP addresses to use your domain in the envelope MAIL FROM (see the SPF deep dive). When a message is forwarded, it reaches the final receiver from the forwarder’s IP, which is not in your SPF record. RFC 7960 §2.2 lays out the two cases precisely:

• If the forwarder keeps the original MAIL FROM, SPF fails for your domain unless the forwarder happens to be an authorized part of your infrastructure (it usually is not).
• If the forwarder replaces the MAIL FROM with its own domain, SPF can pass - but for the forwarder’s domain, which does not align with your From:. So SPF stops contributing to DMARC.

Either way, RFC 7960 concludes: “SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon.” This is structural, not a misconfiguration. It is the reason DMARC accepts either aligned SPF or aligned DKIM, and the reason DKIM is the load-bearing mechanism for any indirect flow.

What survives: DKIM, if you don’t touch the message

DKIM signs the message content (selected headers plus the body), so a forward that does not alter the signed parts leaves the signature intact and the d= domain still aligned with From:. That is why a plain alias or a clean .forward can still pass DMARC via DKIM even though SPF failed.

The fragility is in modification. RFC 7960 §2.3 is explicit: “Modification of email content invalidates most DKIM signatures, and many message-forwarding systems modify email content.” DKIM does define a body-length flag (l=) that allows appending without breaking the signature, but RFC 7960 notes it “is seldom used due to security issues” (a truncation/append attack; see RFC 6376 §8.2) - so do not rely on it. The practical rule: a forwarder that wants DKIM to survive must not change the signed headers or the body at all.

Mailing lists: the canonical DKIM-breaker

A mailing list is the worst case because breaking the message is its job. RFC 7960 §3.2.3 enumerates exactly what lists do that invalidates DKIM:

• prepending a tag to the Subject: (e.g. [list-name]);
• adding an administrative footer to the body;
• removing MIME parts or converting the message to text-only;
• encrypting the body to recipients with PGP or S/MIME;
• rewriting banned words to enforce community standards;
• letting moderators add commentary.

“Any such modifications would invalidate a DKIM signature.” And because the relaying IP also breaks SPF, list mail under a strict policy is doubly broken. RFC 7960 §3.2.3.1 spells out the fallout: subscribers whose providers enforce DMARC may simply not receive posts from authors whose domain publishes p=reject, and lists may misread the resulting rejections as undeliverable addresses and suspend or unsubscribe those members. This is precisely why DMARC in 2026 (RFC 9989) advises that domains whose users post to mailing lists should not publish p=reject.

Sieve redirect and the keep/discard model (RFC 5228)

Sieve is a mail-filtering language run at delivery time. Understanding its action model explains how server-side forwarding actually behaves.

Sieve defines four actions; implementations MUST support keep, discard, and redirect (and SHOULD support fileinto):

• keep - file the message into the user’s main mailbox (what happens “in lieu of all other actions”).
• discard - silently throw the message away. It works by “simply canceling the implicit keep,” and it MUST be silent (no DSN/MDN).
• fileinto - deliver into a named mailbox.
• redirect - “send the message to another user at a supplied address, as a mail forwarding feature does.”

The key concept is the implicit keep (RFC 5228 §2.10.2): if no action cancels it, the message is kept in the inbox. redirect, fileinto, and discard each cancel the implicit keep. So a bare redirect forwards the message and does not also keep a local copy.

Crucially for authentication, RFC 5228 §4.2 says redirect “makes no changes to the message body or existing headers, but it may add new headers” - and “existing Received headers MUST be preserved.” That is the good case: a Sieve redirect is the kind of forwarding that leaves DKIM intact (only SPF breaks). It is explicitly not a MUA-style forward, which “creates a new message with a different sender and message ID, wrapping the old message in a new one.” It also handles loops: if the message has an empty envelope sender, the outgoing copy MUST also have an empty envelope sender (RFC 5228 §4.2), and implementations MUST implement loop control.

redirect :copy (RFC 3894)

By default redirect cancels the implicit keep, so the message is forwarded but not stored locally. RFC 3894 adds the :copy keyword (capability string copy) so that “fileinto” or “redirect” “does not cancel the implicit keep. Instead, it merely files or redirects a copy in addition to whatever else is happening to the message”:

require ["copy"];
redirect :copy "archive@example.org";

RFC 3894 also illustrates the subtle bug :copy exists to avoid: an explicit keep is not the same as the implicit keep, because a later discard cancels the implicit keep but a written keep survives it, so the “discarded” message still lands in the inbox. :copy expresses “also send a copy” without that side effect.

.forward files and aliases

The oldest forms of forwarding are mailbox-level. RFC 7960 §3.2.1 classifies these as Aliases: “a simple re-addressing facility” implemented “by mailbox-level forwarding (e.g., through dot-forwarding), Sieve-level forwarding (through the Sieve redirect action), or other methods.” Examples it lists: forwarding between free email providers, consolidating several addresses into one account, and university/alumni “vanity” addresses that forward for the duration of a membership.

The important property: “When an Alias preserves message content and does not make significant header changes, DKIM signatures may remain valid. However, Aliases often extend the delivery path outside of the scope covered by the originating ADMD’s SPF record(s).” In plain terms - a .forward that just relays the bytes will usually keep DKIM (DMARC can still pass) but will always break SPF for your domain. That is the cleanest forwarding case, and it is why DKIM matters so much for it.

A related signal worth knowing: the Delivered-To header (RFC 9228) records each delivery address as a message moves through aliases, prepended newest-on-top, and is widely used for loop detection - “the presence of an existing Delivered-To: header field, for the same address, typically indicates a handling loop.” If you build forwarding, emitting and checking Delivered-To is a cheap loop guard (see headers and the envelope).

SRS: Sender Rewriting Scheme (non-RFC)

SRS is the standard workaround for the SPF half of the problem. It is not an IETF RFC; it originates in draft-mengwong-sender-rewrite and is described in Shevek’s paper “The Sender Rewriting Scheme” (the reference for the format below). The reference implementation is the libsrs2 C library, with equivalents like Mail::SRS and PostSRSd.

The problem SRS solves, in the paper’s own table: a message from source.com forwarded by forward.com to destination.com is rejected at hop 2 because the Return-Path is still user@source.com while the connecting IP is forward.com. SRS fixes this by having the forwarder rewrite the envelope MAIL FROM into its own domain, encoding the original sender so bounces can still be routed back. The SRS0 format (first hop) is:

SRS0=HHH=TT=orig-domain=orig-localpart@forwarder.example

The fields (from the SRS paper):

• SRS0 - a tag marking this as an SRS address (the 0 is a version/hop marker).
• HHH - a cryptographic hash over the timestamp, domain, and local-part, keyed by a secret only the forwarder holds. It stops attackers from forging SRS addresses to use the forwarder as an open relay.
• TT - a timestamp that expires the address (typically days to a few weeks), limiting replay/backscatter abuse.
• orig-domain / orig-localpart - the original sender, so a bounce to the SRS address can be unwrapped and returned.

For a second forwarder, the address is rewritten to the SRS1 form so the address does not grow without bound:

SRS1=HHH=first-forwarder==HHH=TT=orig-domain=orig-localpart@second-forwarder.example

What SRS does and does not do:

• It makes SPF pass for the forwarded hop, because the envelope domain is now the forwarder’s, with the forwarder’s SPF record.
• It rewrites only the envelope sender (Return-Path), not the visible From:. The header From: - and therefore the recipient’s display - is untouched.
• It does NOT create DMARC alignment with the original author domain. RFC 7960 §2.2 is explicit: if the forwarder replaces MAIL FROM with its own domain, SPF may pass but alignment with From: fails. So SRS alone does not produce a DMARC pass; you still need aligned DKIM that survived the forward for DMARC to pass on the original From: domain.
• It requires the rewrite domain to be deliverable - valid SPF and a working MX - or bounces to the SRS address are lost.

So SRS is best understood as envelope-path repair: it keeps the forwarding hop SPF-clean and keeps bounces routable; it is not a substitute for DKIM.

ARC: preserving the verdict across hops (RFC 8617)

SRS patches SPF; ARC patches the loss of information. When a forwarder or list breaks SPF and DKIM, the final receiver has no trustworthy record that the message authenticated before it was relayed. ARC (Authenticated Received Chain) carries that earlier verdict forward: each participating hop adds an ARC Set of three headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) recording what authentication looked like on arrival, sealed so the chain can be validated.

The honest framing (covered fully in the ARC deep dive): a receiver MAY use a valid ARC chain to override a DMARC failure, but is not obligated to - ARC is advisory, not a pass (RFC 8617 §7). It is also “not a trust framework” (RFC 8617 §9.3): a malicious relay can seal spam. And per RFC 9989 §7.4, as of 2026 ARC “ha[s] not become widely used.” So if you forward, sealing correctly is good citizenship, but you should not design as if the final receiver will act on your chain. Major providers do recommend ARC for forwarding - for example, Apple requires ARC headers on forwarded bulk mail, and Yahoo and Microsoft recommend it.

What breaks: a summary table

Scenario	SPF	DKIM	DMARC outcome
Clean .forward / alias (no edits)	Breaks (forwarder IP)	Survives	Passes via aligned DKIM
Sieve redirect (no edits)	Breaks	Survives	Passes via aligned DKIM
Forward + SRS (no edits)	Passes for forwarder (not aligned)	Survives	Passes via aligned DKIM; SPF does not align
Mailing list (subject tag / footer)	Breaks	Breaks (content changed)	Fails unless receiver honors ARC, or sender uses list-friendly policy
MUA “forward inline” (ReSender)	N/A (new message)	Breaks (new message)	New author identity; original DMARC not preserved

(Behavior derived from RFC 7960 §2.2, §2.3, §3.2.1-§3.2.3 and RFC 5228 §4.2.)

Best practices for building a forwarding product

If you operate forwarding or a list, the goal is to do the least harm to authentication while still routing mail and bounces correctly:

1. Preserve DKIM by not touching signed content. Do not rewrite the Subject:, do not append footers, do not re-encode MIME parts unless you must. Every edit you avoid is a DKIM signature that survives and a DMARC pass that holds (RFC 7960 §2.3).
2. Apply SRS to the envelope sender so the forwarding hop is SPF-clean and bounces route back through you, using a rewrite domain with valid SPF and a working MX (SRS paper; RFC 7208).
3. Keep bounces routable and parse them. SRS gives you a return path you own; feed hard bounces into suppression (see bounces and DSN and suppression and consent).
4. Add ARC and seal correctly - one well-formed ARC Set per hop - so receivers that honor ARC can recover the original verdict, while understanding it is advisory (RFC 8617).
5. Detect loops. Honor and emit Delivered-To (RFC 9228) and count Received: lines; Sieve redirect requires loop control, and a null envelope sender must stay null (RFC 5228 §4.2).
6. If you run a list whose authors use p=reject domains, expect breakage. The standards-aligned mitigations are author-domain From: rewriting (changing the visible From: to a list-owned address, which changes the displayed author) or relying on ARC at honoring receivers - both with real trade-offs. Do not assume p=reject authors’ mail will reach DMARC-enforcing subscribers untouched (RFC 7960 §3.2.3.1; RFC 9989 §7.4).
7. Don’t pretend SRS fixes DMARC. It fixes SPF for the hop. Aligned, surviving DKIM is what makes DMARC pass on the original author domain.

Common confusion

• “SRS makes forwarded mail pass DMARC.” No. SRS makes SPF pass for the forwarder’s domain, which does not align with the original From:. DMARC still needs aligned DKIM that survived the forward (RFC 7960 §2.2).
• “Forwarding keeps DKIM, so I’m fine.” Only if nothing edits the signed content. A list that tags the subject or adds a footer breaks DKIM regardless (RFC 7960 §3.2.3).
• “ARC turns a broken chain into a DMARC pass.” Only if a receiver chooses to honor it, which it is not required to do, and most do not as of 2026 (RFC 8617 §7; RFC 9989 §7.4).
• “Sieve redirect rewrites the message.” It makes no changes to body or existing headers; it may add headers and must preserve Received: lines (RFC 5228 §4.2). A bare redirect does not keep a local copy unless you add :copy (RFC 3894).
• “The DKIM l= length flag lets lists append safely.” It exists but is “seldom used due to security issues”; don’t rely on it (RFC 7960 §2.3, RFC 6376 §8.2).

What Egressif does

Where we forward or relay, we bias every decision toward preserving the original author’s authentication. We avoid modifying signed content so aligned DKIM survives the hop - the one identifier that keeps DMARC passing when SPF cannot - and we apply SRS on the envelope sender so the forwarding hop stays SPF-clean and bounces route back to a mailbox we parse into suppression. We seal ARC correctly while being honest that it is advisory and thinly deployed, so we never treat it as a rescue for alignment. And we are candid about the hard case: mail from p=reject author domains through a modifying list will break for DMARC-enforcing receivers no matter what the forwarder does - the fix lives with the author’s policy and signing, not with a clever rewrite. None of this guarantees the inbox; it minimizes the structural authentication damage forwarding inevitably causes.