Forwarding, mailing lists, and ARC

Why forwarding breaks SPF

SPF validates the sending server's IP address against the domain's SPF record. When a message is forwarded, the forwarding server's IP replaces the original server's IP in the SMTP connection. The receiving server checks SPF against the original domain, but the connecting IP now belongs to the forwarder. SPF fails.

This is not a misconfiguration. It is a fundamental limitation of SPF. The protocol was designed for direct server-to-server delivery, not for relayed mail.

What it looks like in practice

A user at [email protected] has a .forward file on their university mail server that sends everything to [email protected]. When [email protected] sends Alice a message:

1. Bob's server sends the message to company.com. SPF passes (Bob's server IP is in example.com's SPF record).
2. The university server forwards the message to Gmail. The connecting IP is now the university's server, not Bob's.
3. Gmail checks SPF for example.com. The university's IP is not in the SPF record. SPF fails.

How to spot forwarding in DMARC reports

In your aggregate reports, forwarding traffic shows up as DMARC failures from IPs that belong to known email infrastructure, not to spammers. Look for:

• High-volume failures from university mail systems, ISP mail servers, or corporate forwarding infrastructure
• Source IPs that reverse-resolve to legitimate mail servers (e.g., mail.university.edu)
• SPF failing but the source IP clearly belongs to a mail provider, not an attacker

DMARCTrust's dashboard automatically identifies forwarding traffic so you can separate it from actual abuse.

Why mailing lists break DKIM

Mailing lists modify messages. They add footers, prepend [list-name] to the subject line, rewrite the From: header, or add list management links. Each modification can break DKIM:

• Body modifications (footers, disclaimers) invalidate the DKIM body hash (bh=). The receiver recomputes the hash and it does not match the signature.
• Subject changes invalidate the DKIM signature if subject is listed in the h= (signed headers) field.
• From: rewriting removes the original DKIM alignment entirely. The message now appears to come from the list's domain, not yours.

Specific mailing list software

Google Groups. When a message arrives from a domain with p=reject, Google Groups rewrites the From: header to the group address. The original sender appears in the Reply-To: header. Google adds ARC headers to preserve the original authentication results.

Mailman 3. Supports ARC when configured with OpenARC. Can be set to wrap messages (preserving the original as an attachment) instead of modifying them. Mailman 2 does not support ARC. If you still run Mailman 2, consider upgrading.

LISTSERV. Older versions modify messages aggressively. Newer versions offer "DMARC-friendly" modes that either wrap messages or rewrite the From: header. Check your LISTSERV configuration for DMARC handling options.

ARC: Authenticated Received Chain (RFC 8617)

ARC does not fix broken authentication. Instead, it creates a chain of custody that lets receivers see what the authentication results were before the message was modified. If a receiver trusts the intermediary, it can use the ARC results to override a DMARC failure.

How ARC works

Each intermediary that handles the message adds three headers:

• ARC-Authentication-Results (i=1): the authentication results at that hop (SPF, DKIM, DMARC status when the intermediary received the message).
• ARC-Message-Signature (i=1): a DKIM-like signature of the message as seen at that hop.
• ARC-Seal (i=1): a signature over the ARC header set itself, preventing tampering with the chain.

The i= value increments at each hop. A message forwarded through two intermediaries will have i=1 and i=2 header sets.

ARC in practice: a forwarding example

1. Alice sends a message from [email protected]. SPF passes, DKIM passes, DMARC passes.
2. The message arrives at university.edu, which forwards it to gmail.com.
3. university.edu records the original authentication results in ARC-Authentication-Results (i=1).
4. university.edu signs the message with ARC-Message-Signature (i=1) and seals the chain with ARC-Seal (i=1).
5. Gmail receives the message. SPF fails (university's IP). DKIM may fail (if the message was modified).
6. Gmail checks the ARC chain. The chain is valid. university.edu is a trusted intermediary. Gmail may choose to deliver the message despite the DMARC failure.

Important: ARC trust is at the receiver's discretion. Google, Microsoft, and Yahoo honor ARC from trusted intermediaries, but not all receivers support ARC yet.

SRS: Sender Rewriting Scheme

SRS rewrites the envelope sender (MAIL FROM) to the forwarder's domain so that SPF passes at the next hop. For example, [email protected] forwarded through university.edu becomes:

[email protected]

SPF now passes because the envelope sender is university.edu, and the university's IP is in university.edu's SPF record.

However, SRS does not fix DMARC alignment. The envelope sender is now university.edu, but the visible From: header still says example.com. SPF passes but does not align with the From: domain. You need DKIM alignment or ARC to pass DMARC.

SRS + ARC together: SRS makes SPF pass at the next hop (so the message is not rejected outright by SPF-only checks), while ARC preserves the original authentication context for DMARC evaluation.

Microsoft 365 forwarding

Microsoft 365 transport rules that forward mail add ARC headers automatically. However, SPF still fails for forwarded messages because the connecting IP changes. If you use M365 forwarding rules extensively:

• Ensure DKIM signing is configured for your domain in M365 (custom DKIM with your domain's d=).
• Use c=relaxed/relaxed canonicalization to survive minor body modifications.
• Consider using shared mailbox access or delegate permissions instead of forwarding rules.

What you can do as a domain owner

Some forwarding failures are unavoidable once you enforce DMARC with p=reject. Here is what you can control:

1. Ensure robust DKIM signing. Use c=relaxed/relaxed canonicalization and set a generous signature expiry (or omit the x= tag). DKIM survives forwarding as long as the message body is not modified.
2. Monitor your DMARC reports. Quantify forwarding-related failures. If forwarding accounts for a significant percentage of your traffic, consider staying at p=quarantine instead of p=reject.
3. Communicate with your users. Inform users who forward mail that authentication will break. Suggest alternatives: configure POP/IMAP fetch in the destination mailbox instead of server-side forwarding.
4. Audit forwarding rules. Before tightening your DMARC policy, identify all forwarding rules in your organization. See our none-to-reject migration guide for a complete checklist.

Prevention

• Inventory all forwarding rules and mailing list subscriptions before moving to p=quarantine or p=reject.
• Communicate DMARC enforcement plans to users who rely on forwarding.
• Monitor forwarding-related failures in your DMARCTrust dashboard to track the impact over time.
• Review the SPF overview and DKIM overview to ensure your authentication foundation is solid before enforcing.

Related guides