DMARC and Email Header Rewriting

18 August 2026 · DMARC Engine · 5 min read

Header rewriting is how mailing lists, forwarders and gateways change a message after you send it, and it decides whether that message still passes DMARC. Rewriting the envelope sender (Sender Rewriting Scheme, SRS) lets a forwarder pass SPF for itself but never restores alignment with your domain. Rewriting the subject or body breaks your DKIM signature. Rewriting the From header to the list's own address, often called From munging, makes the message pass DMARC for the list's domain instead of yours. Which of these an intermediary does explains most "genuine mail failing DMARC" cases.

What each kind of rewriting does

In every case below, SPF no longer aligns with your domain once the message has been relayed, so the outcome rests on DKIM.

Envelope rewriting: SRS

SPF checks the domain in the envelope sender (the MAIL FROM, or Return-Path) against the connecting IP. When a server forwards your message, its IP is not in your SPF record. Forwarders that use SRS replace the envelope sender with an address on their own domain, so SPF passes for the forwarder. Google's forwarding guidance for Gmail asks forwarders to do exactly this.

SRS does not help your DMARC result. The SPF pass is for the forwarder's domain, which does not align with your From address. What carries the message is your DKIM signature, as long as the forwarder changes nothing it covers.

Content rewriting breaks DKIM

RFC 7960, the IETF's account of DMARC and indirect mail flows, lists the changes mailing lists commonly make: tagging the subject, adding a footer to the body, stripping MIME parts, converting to plain text, and adding moderator comments. It concludes that any such modification invalidates a DKIM signature. Security gateways that rewrite links or add "external sender" banners have the same effect.

Adding a header that your signature does not cover, such as List-Id, does not break DKIM. Changing a header the signature does cover, such as Subject or From, does. Relaxed canonicalisation (c=relaxed/relaxed) tolerates whitespace and line-folding changes, but not changes to content.

Once DKIM breaks and SPF is unaligned, a message from a domain at p=reject fails DMARC at the final receiver. RFC 7960 notes the knock-on effect for lists: subscribers whose own domains publish p=reject may not receive list mail, and lists can mistake the resulting bounces for dead addresses and unsubscribe people.

From rewriting: how lists work around DMARC

Because content rewriting breaks DKIM, many lists change the From header itself so the message no longer claims to come from your domain. GNU Mailman's DMARC mitigation settings offer three choices:

• munge_from rewrites the From header to the list address, with the poster's name shown "via" the list, and moves the original address to Reply-To: (or Cc:).
• wrap_message puts the original message, headers intact, inside a new message sent from the list.
• no_mitigation changes nothing.

By default Mailman applies the mitigation only to posters whose domains publish p=quarantine or p=reject.

For example, after munging:

From: Alice Example via Discuss <discuss@lists.example.org>
Reply-To: alice@example.com

The message now passes or fails DMARC for lists.example.org, not for your domain, so your policy no longer applies to it. RFC 7960 is candid about the cost: From rewriting may to some extent defeat the purpose of DMARC, reply behaviour varies between mail clients, and wrapped messages display poorly in some clients, especially on mobile.

The X-Original-From header some systems add is informational only. DMARC does not read it.

ARC: recording what was true before the rewrite

The Authenticated Received Chain, defined in RFC 8617, lets an intermediary record the SPF, DKIM and DMARC results it saw when the message arrived, and seal that record with its own signature before it makes changes. A later receiver that trusts the intermediary can use the seal to deliver a message that now fails DMARC. Microsoft 365 lets administrators name trusted ARC sealers for this purpose.

ARC is a receiver's choice, not an obligation, and it only works if the intermediary implements it. You cannot add ARC to someone else's list or gateway. ARC explained covers it in more detail.

What you can do as the sender

1. Sign everything with DKIM using your own domain. It is the only mechanism that survives a plain forward or an SRS rewrite. Check each selector with the DKIM checker.
2. Read your reports before enforcing. Indirect mail shows up as SPF failures from list, university, ISP or gateway IP ranges. Where DKIM still passes and aligns, there is nothing to fix. Where both fail, the intermediary is modifying content. The DMARC report analyser shows each source.
3. Weigh p=reject against your users' mailing lists. The current DMARC standard, RFC 9989, says domains whose users post to mailing lists SHOULD NOT publish p=reject. p=quarantine may be the right end point for such domains.
4. Do not loosen alignment to compensate. Relaxed alignment (adkim=r, aspf=r) is already the default and compares organisational domains. It cannot rescue a broken signature or a rewritten From header.

What you can do as an intermediary

• Avoid changing the subject, body and DKIM-signed headers where you can; RFC 7960 notes some lists already run this way.
• Use SRS for the envelope sender when forwarding.
• Add ARC seals if your software supports them.
• If you must change content for posters whose domains enforce DMARC, use From munging or wrapping deliberately, and expect some reply and display side effects.

For the receiving side of the same problem, read mailing lists, DMARC and ARC and why forwarding breaks authentication. If you want indirect mail separated from spoofing in your reports, DMARC analytics groups forwarded mail and suspected spoofing separately.