Why Email Forwarding Breaks DMARC and How to Fix It

What happens to email when it is forwarded

Email forwarding breaks DMARC because the forwarding server changes the authentication context between receiving the message and delivering it. Specifically:

The forwarding server receives an email, then resends it from its own IP address and infrastructure. This changes the SMTP envelope sender (MAIL FROM) to the forwarder's domain. The original From-header is usually preserved, but the receiving server now sees two different domains: the envelope says it came from the forwarder, while the From-header says it came from the original sender. If the receiver enforces DMARC alignment, those domains must match. They do not.

The result: DMARC fails even when the original sender has perfect SPF, DKIM, and DMARC configured.

Why SPF and DKIM alone cannot save forwarded email

SPF checks whether the IP address sending the email is authorised for the domain in the SMTP envelope. When a forwarder resends the message, it sends from its own IP address, not the original sender's. The original SPF record covers the original sender's IP range, not the forwarder's, so SPF fails for the forwarding server.

DKIM digitally signs email headers at the original sending server using a private key associated with the sending domain. The forwarding server does not have that private key and cannot re-sign the message with the same DKIM signature. When the forwarder adds its own headers or modifies existing ones, any existing DKIM signature becomes invalid.

DMARC requires both authentication (SPF or DKIM passes) AND alignment (the header From domain matches the domain used for authentication). Forwarding breaks alignment on both SPF and DKIM simultaneously, which is why simply having both protocols configured does not prevent forwarding-related DMARC failures.

What ARC does and how it helps

ARC (Authenticated Received Chain) was designed specifically to solve the forwarding authentication chain problem. It works by having each server in the forwarding chain add a set of ARC headers that preserve the original authentication results.

The ARC headers are:

ARC-Seal: a signature that covers the ARC header set itself, providing integrity

ARC-Message-Signature: mirrors DKIM but covers the message as the forwarding server received it

ARC-Authentication-Results: records the SPF, DKIM, and DMARC results at each relay step

When the final recipient receives the forwarded message, the ARC headers tell it what the original authentication results were, even though the forwarding server's own SPF and DKIM checks would fail. The receiving server can then evaluate whether the forwarding chain is trustworthy and adjust its handling accordingly.

ARC does not replace DMARC. It is a supplementary layer that allows receivers to make a more informed decision about messages that pass through forwarding infrastructure. Many major email providers, including Google and Microsoft, evaluate ARC headers when present.

How to configure ARC for common mail servers

#### Microsoft Exchange and Microsoft 365

Microsoft 365 automatically adds ARC headers to inbound mail that passes through its infrastructure. For on-premises Exchange, you need to ensure that the Transport service is configured to preserve authentication results.

In Exchange Server, the key setting is on the Receive connectors: ensure that "Allow or block email based on authentication results" is not stripping ARC headers. In practice, if you are forwarding mail through Exchange to the internet, Exchange will add its own ARC-Seal automatically.

For M365 forwarding scenarios, if you are using rules to redirect mail to an external address, the external recipient's server will see ARC headers from M365 if M365 was the last hop. This helps your forwarded mail pass DMARC checks at the destination.

#### Postfix

Postfix supports ARC through the dkim Archer milter or via custom policy filters. To enable ARC signing on forwarded mail:

1. Install the aresolver or dkim Archer milter that supports ARC
2. Configure it to add ARC headers on outgoing forwarded mail
3. Set the policy to sign ARC-Seal and ARC-Message-Signature

For Postfix receiving forwarded mail from external sources, you generally do not need to do anything special - Postfix will pass through existing ARC headers if they are present in the inbound message.

#### Sendmail and Exim

Both Sendmail and Exim support ARC via custom filters or configuration changes. The general approach is to add an ACL (Access Control List) rule in Exim that calls a macro to insert ARC headers before relaying. This requires custom configuration that is specific to each deployment.

If you are running Exim and forwarding mail, look for the ARC-related macros in Exim 4.89 or later, which added native ARC support.

What to check in DMARC reports when forwarding is the issue

When forwarding is causing DMARC failures, the DMARC aggregate reports will show a specific pattern. Look for:

Authentication results where SPF passes and DKIM passes for the original sending domain
DMARC result showing "fail" or "bestmatch pass" with reason "forwarded"
The envelope-from domain belonging to the forwarding server, not the original sender

This pattern tells you that the failure is caused by forwarding, not by a misconfigured SPF or DKIM record. The sending domain is legitimate, but the forwarding chain is breaking alignment.

High volumes of forwarded mail can inflate your p=failure rate even when the forwarding is legitimate and expected. If you have forwarding rules set up for specific use cases, you may see a persistent percentage of failures that is not actually a security problem.

Reading raw DMARC XML reports to find this pattern is time-consuming. A dedicated DMARC reporting tool like DMARCFlow parses the XML automatically and flags forwarding patterns as a separate category from genuine authentication failures, so you do not have to manually search for the "forwarded" reason code across thousands of records. This matters because the fix for forwarding failures is different from the fix for SPF or DKIM misconfiguration, and treating them as the same problem leads to wasted troubleshooting time.

Before you change any DNS records, use DMARC reports to confirm that your forwarding-related failures share the same pattern: passing SPF and DKIM on the original domain, failing alignment because the forwarder is the immediate sender. That single observation rules out most other causes and narrows the solution space considerably.

When forwarding cannot be fixed with ARC

Some forwarding services strip all authentication headers, including ARC, before relaying the message. This is particularly common with:

Legacy mailing list software

Some webmail providers that modify messages before delivery

Certain forward-as-attachment services

When ARC is stripped and the forwarding server changes the envelope, DMARC alignment will fail at the receiving server. In these cases, the practical options are:

1. Contact the forwarding service and ask them to preserve authentication headers
2. Authorise the forwarding server as a legitimate sender by adding its mail servers to your SPF record (if the forwarding is from a fixed set of servers)
3. Consider an alternative forwarding approach, such as having the original sender blind-copy a monitoring address rather than relying on the forwarding chain for visibility
4. Use a subdomain strategy: send marketing or automated mail from a subdomain that is not subject to the same strict DMARC policy as the primary domain

Communicating with the forwarding party about their server configuration is often the fastest path to a permanent fix, since ARC support has been standard for several years and many providers are not aware they are stripping headers.

Frequently asked questions about DMARC and email forwarding

Does enabling ARC affect my DMARC policy?
No. ARC is read-only for receivers. It provides additional context but does not change how your DMARC policy is evaluated. Your p=none, quarantine, or reject policy remains in effect. Think of it as a footnote that receivers can read to understand the chain of custody of a message.

Can I whitelist specific forwarding servers in my DMARC record?
Not directly via the DMARC record itself. You can add the forwarding server's mail servers to your SPF record if they are a fixed set. You can also use a subdomain with a relaxed policy for mail that is expected to be forwarded.

Does DMARC p=reject block all forwarded email?
It can, if the forwarding server changes the From header and the receiver enforces strict alignment. This is one reason why transitioning to p=reject should be done gradually and with DMARC reporting enabled. ARC helps prevent legitimate forwarded mail from being rejected when receivers support it.

Why do some forwarded emails arrive and others do not?
It depends on the receiving server's DMARC policy and whether it evaluates ARC headers. Gmail and Microsoft 365 both support ARC and use it to make exceptions for mail from trusted forwarding chains. Smaller receivers may reject based purely on the immediate SPF/DKIM failure without considering ARC.

What is the difference between forwarding and mailing list rebouncing?
Mailing lists often rewrite the From header entirely, not just resend from a new envelope. This is a more severe change that breaks DKIM even with ARC present. Forwarding (as described in this post) preserves the original From header but changes the envelope. Both cause DMARC failures for different reasons.