Why Email Forwarding Breaks DMARC (and How to Fix It)

If you forward email from one address to another — say, you forward your old-company.com mail to Gmail, or a customer sends to your CRM and the CRM forwards to your team — you've probably seen this: legitimate forwarded emails land in spam, get blocked, or bounce with a DMARC failure.

The reason is straightforward: email forwarding breaks the authentication chain that SPF, DKIM, and DMARC depend on. Here's exactly why, and what you can do about it.

Why Forwarding Breaks SPF

SPF works by checking whether the sending server's IP address is listed in the domain's SPF record. When an email is forwarded:

1. Original sender (e.g., alice@company.com) sends mail through their own server (IP: 1.2.3.4).
2. Forwarding server receives it and relays it to the final recipient. Now the mail comes from the forwarder's IP (e.g., 5.6.7.8).
3. Recipient's server checks SPF for company.com — but 5.6.7.8 is not in company.com's SPF record.
4. SPF fails.

The original sender has no way to list every possible forwarding server in their SPF record. Even if they could, SPF has a hard limit of 10 DNS lookups, so it's usually impractical.

Why Forwarding Can Break DKIM

DKIM uses a cryptographic signature that survives forwarding — unless the forwarding server modifies the email. Common modifications that break DKIM include:

• Adding a footer (like "This email was forwarded by...").
• Changing the subject line.
• Wrapping the body in HTML.
• Re-encoding attachments.

Any of these changes invalidates the DKIM signature. When both SPF and DKIM fail, DMARC fails too.

How DMARC Applies to Forwarded Mail

DMARC requires either SPF or DKIM to pass with alignment — meaning the domain used in SPF or DKIM must match the domain in the From: header.

For forwarded mail:

• SPF alignment fails because the envelope sender is often rewritten and the forwarding IP isn't authorized.
• DKIM may still pass if the signature survives, but strict alignment (aspf=s) can cause it to fail if the forwarding domain differs from the From: domain.

The result: a domain with p=reject will bounce forwarded email entirely, which is why many organizations stay at p=none or p=quarantine even when they'd rather enforce.

Solutions

1. SRS (Sender Rewriting Scheme)

SRS rewrites the envelope sender address (the Return-Path) when mail is forwarded. Instead of bounces@company.com, the forwarder sets the envelope sender to something like company.com+bounces=forwarder.com@forwarder.com. This preserves SPF for the forwarder's domain while tracking bounces.

SRS is widely used by mailing lists and forwarding services. Most major providers support it.

2. ARC (Authenticated Received Chain)

ARC is a newer standard that lets each hop in a forwarding chain seal the authentication results it saw. An ARC seal proves the email was authenticated when it reached the forwarder, even if SPF and DKIM fail for the final hop.

Major recipients (Gmail, Yahoo, Microsoft) now recognize ARC. For the forwarder to support ARC, their outgoing mail system must add the ARC headers. This is the cleanest fix for complex forwarding chains.

3. Relaxed DKIM Alignment

The original sender can use relaxed DKIM alignment (adkim=r instead of adkim=s), which allows the DKIM d= domain to be a subdomain or organizational domain of the From: domain. This doesn't fix forwarding directly, but it reduces false positives when forwarding breaks SPF.

4. Publish Forwarders in Your SPF Record

If you control the original domain and the forwarding is predictable (e.g., a specific CRM or mailing list), add the forwarder to your SPF record. This only works for known, fixed forwarders — it's not a solution for general email forwarding.

What About p=reject?

If you're enforcing DMARC with p=reject, forwarded email will be blocked unless the forwarder uses SRS or ARC. This is why the DMARC rollout process recommends:

1. Start at p=none and monitor reports.
2. Identify which forwarded emails are legitimate.
3. Work with major forwarders to implement SRS or ARC.
4. Only then move to p=quarantine or p=reject.

Many organizations run p=reject on their main domain and accept that some forwarded email will bounce — but for domains where forwarding is critical, SRS and ARC are the real fixes.

Check Your Domain's Authentication

Not sure whether your domain is set up to handle forwarded mail? Run a free scan to check your SPF, DKIM, and DMARC records, including alignment settings and policy configuration. The scanner shows exactly what's in place and highlights anything that could break under forwarding or enforcement.