Why Email Forwarding Breaks DMARC and How ARC Fixes It

Why does DMARC fail when I forward email?

You set up DMARC, SPF, and DKIM correctly. Your aggregate reports show everything passing. Then someone forwards a message to an external address, and suddenly DMARC fails.

The reason is structural. SPF and DKIM are bound to the sending domain, not the content. When a forwarding server re-injects your message, it becomes a new delivery from its infrastructure. The original SPF check pointed to a different mail server. The original DKIM signature was signed by the original sender, not the forwarder. DMARC alignment fails because the From header (your domain) no longer matches the domain that authenticated the message.

This is not a bug. It is how email authentication is designed. The forwarded message looks like it came from your domain, but the authentication results say it came from the forwarder's server.

What is ARC in email?

ARC (Authenticated Received Chain) is an email authentication extension that was designed specifically to handle forwarded mail. Rather than trying to make forwarding servers look like original senders, ARC creates a chain of custody that records how the message was handled at each hop.

When a message passes through a forwarding server that understands ARC, the server adds three headers:

ARC-Seal: A timestamp and signature that proves this MTA handled the message

ARC-Message-Signature: A copy of the original authentication results (SPF, DKIM, DMARC) from the first hop

ARC-Authentication-Results: The authentication results as this server observed them

The forwarder signs these headers with its own domain key. If the message gets forwarded again, the next server in the chain can see the entire history. The original authentication results are preserved and can be evaluated in context.

How does ARC work step by step?

Here is the sequence when a forwarded message goes through an ARC-aware chain:

1. Step 1: Your mail server sends a message to user@example.com. SPF passes for your domain, DKIM is signed, DMARC alignment passes.
2. Step 2: The recipient's mail server forwards the message to another address via an ARC-aware MTA. The MTA adds ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers, then re-injects the message.
3. Step 3: The destination server receives the forwarded message. DMARC alignment fails because the envelope sender now points to the forwarder. But the ARC headers are present.
4. Step 4: The destination server can check the ARC chain. It sees the original authentication results preserved in the ARC-Message-Signature. If the ARC seal is valid and nothing in the chain suggests tampering, the server can treat the message as lower-risk even though DMARC failed.

The key difference from standard DMARC is that ARC does not replace alignment. DMARC still fails in this scenario. ARC gives the receiving server additional context to make a more informed handling decision.

Which mail providers support ARC?

ARC support is widespread among major mailbox providers but not universal. Google, Microsoft, and Yahoo all honor ARC headers. Many forwarding services and mailing list operators also implement it.

The practical problem is that ARC only helps if the final receiving server checks it. Some servers still reject messages purely on DMARC alignment, without looking at the ARC chain.

You can check whether a message passed through an ARC-aware chain by looking for ARC headers in the raw email source:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; s=arc-2024;
sv=1; d=forwarder.example.com;

If you see ARC-Seal and ARC-Message-Signature headers, the forwarding path added them.

Practical solutions for forwarded mail

ARC helps receiving servers make better decisions, but you also have options as the sender:

Sub-addressing (plus addressing): Instead of forwarding mail to an external address, ask users to use sub-addresses like yourname+forward@example.com. The message arrives directly without a forwarding hop, so DMARC alignment is preserved. This only works if the recipient can configure their mail routing this way.

Alias services: Services like SimpleLogin, Firefox Relay, and DuckDuckGo Email Protection sit between the original sender and the final recipient. They add their own authentication and forward as a known, trusted sender. Some of these services are ARC-aware.

Mailing list handling: Most mailing list software re-injects messages, which breaks DMARC. If you run your own mailing list, enable ARC signing. The mailing list becomes an authenticated intermediary rather than an unknown forwarder. DMARC accommodates this through the "mailing list" relaxed alignment rule, but only if the list software is configured correctly.

p=quarantine instead of p=reject: If you know forwarding is common for your domain (for example, in organizations with legacy internal mail systems), setting DMARC to p=quarantine instead of p=reject gives forwarded messages a chance to land in the inbox rather than being rejected outright. This is a temporary measure, not a permanent fix.

What to look for in DMARC reports when forwarding causes failures

When forwarding creates DMARC failures, your aggregate reports show specific patterns. Look for:

Alignment failures with familiar forwarder IPs: If you see consistent alignment failures from known forwarding services (mailing lists, alias providers, internal mail gateways), those are expected and manageable.

High volume of aev (ARC validation) results: Some aggregate reports include ARC evaluation results. A passing ARC chain alongside a failed DMARC alignment tells you the forwarding path is ARC-aware and the failures are benign.

Spikes coinciding with specific forwarding events: If a new forwarding path was recently added (a new mailing list, a migration to a different alias service), you will see a corresponding spike in alignment failures.

This is where DMARCFlow becomes practical. Aggregate reports are verbose and manual to review. When forwarding-related failures are mixed with actual authentication problems, it takes time to separate signal from noise. DMARCFlow surfaces forwarding-specific failure patterns, alerts when a new forwarding source appears, and shows which forwarding paths are causing the most failures. Rather than parsing raw XML reports to find which forwarder generated the spike, you get a structured view of forwarding auth results alongside your other DMARC data, so you can decide whether to update your DMARC policy or engage with the forwarder.

When forwarding cannot be avoided

Some mail flows genuinely cannot avoid forwarding. IT administrators dealing with legacy mail migrations, organizations that consolidate email through internal gateways, and businesses that use third-party mail processing all fall into this category.

In these situations, the practical steps are:

1. Identify which forwarding paths are generating the most DMARC failures in your aggregate reports.
2. Check whether those forwarders are ARC-aware. If they are not, ask them to enable ARC support.
3. If ARC is not an option, consider whether the forwarding path can be replaced with a direct delivery flow, or whether the DMARC policy should be adjusted to p=quarantine for the affected subdomain.
4. Document the approved forwarding paths in your email infrastructure runbook so failures from unexpected sources are flagged immediately.

Frequently asked questions

Does SPF pass for forwarded email?

No. SPF is checked against the envelope sender (the MAIL FROM address), which changes when a server forwards the message. The forwarder's IP becomes the new SPF check point, and it almost certainly is not authorized to send for your domain.

Can DKIM survive forwarding?

Yes, but with a caveat. The DKIM signature is tied to the message content, so it survives the forwarding process intact. However, DMARC alignment requires the From header domain to match the domain that signed the DKIM. If the forwarder re-writes any headers or adds content, the DKIM signature breaks. Even if it does not, the alignment failure means DMARC still fails.

What happens to DMARC when email is forwarded?

DMARC alignment fails. The From header still shows your domain, but the SPF check points to the forwarder's IP and the DKIM signature is from your domain while the alignment domain is the forwarder. Two of three alignment checks fail, so DMARC authentication fails.

How does ARC help if my mail provider supports it?

ARC gives the receiving server a way to see that the message was authenticated originally and was then handled by a known intermediary. If the ARC chain is intact and valid, a receiving server that supports ARC can use that information to make a more permissive handling decision even when DMARC fails.

Should I use p=quarantine or p=reject if I forward mail?

If your domain has forwarding that you cannot eliminate or ARC-enable, p=quarantine is the safer choice while you work on a permanent fix. p=reject will silently discard forwarded messages, which can cause support tickets and lost mail with no notification to the sender.