Email Forwarding and DMARC: Why Forwarded Mail Fails Authentication
Forwarding breaks SPF but usually leaves DKIM intact, so DMARC passes as long as the original sender signed with DKIM and the forwarder did not modify the message. When those conditions are not met, DMARC fails. The fix is ARC sealing: forwarders that add ARC headers (Cloudflare Email Routing does this by default) let receiving servers honor the original authentication result despite the SPF failure at the forwarding hop.
Why SPF Fails on Forwarded Mail
SPF is a sender-side check: "Does this IP appear in the sender's SPF record?"
When a mail server forwards email, it re-sends the message from its own IP. The receiving server checks SPF against that IP, not the original sender's. The original sender's SPF record doesn't include the forwarder's IP, so the check fails.
Here's the flow:
- User sends email from
user@gmail.comto your catch-all athello@yourcompany.com. - Your forwarder (e.g., Cloudflare Email Routing, a custom mail server, or a forwarding service) receives it on its IP.
- Your forwarder re-sends it from IP
203.0.113.45to the intended recipient's server. - The receiving server checks: "Is
203.0.113.45inyourcompany.com's SPF record?" It's not (your SPF includes only your mail server's IPs), so SPF fails.
The problem is structural: SPF checks the envelope sender, and forwarding changes the envelope. (If the roles of SPF, DKIM, and DMARC aren't yet clear, that primer explains how the three checks fit together.)
DKIM Survives Forwarding (Usually)
DKIM is different. It's a cryptographic signature over the message body and specific headers (Subject, From, etc.). As long as the forwarder doesn't modify those signed headers or the body, the DKIM signature remains valid.
If the original sender's message was DKIM-signed (e.g., Gmail or any major ESP signs outbound mail), the signature travels with the message. The receiving server verifies it against the sender's DKIM public key in DNS. The forwarder doesn't break the signature because it didn't change the signed content.
This is why DKIM is more robust for forwarding than SPF.
So DMARC Should Pass, Right?
Not always. DMARC has two alignment checks:
- SPF alignment: Did the envelope sender's domain match the From header domain, and did SPF pass?
- DKIM alignment: Did the DKIM-signing domain match the From header domain, and did DKIM pass?
DMARC passes if either alignment succeeds.
After forwarding:
- SPF fails (envelope sender changed).
- DKIM passes (if the original sender had DKIM and the forwarder didn't modify the message).
So DMARC passes because DKIM alignment holds.
But here's the catch: DMARC only passes if the original sender had DKIM in the first place. If the original sender relied only on SPF, or if the forwarder modifies the message (rewrites the Subject, adds a footer, changes the body), DKIM breaks. Both SPF and DKIM fail, and DMARC fails.
When DMARC Fails on Forwarded Mail
Three scenarios:
1. Original sender has no DKIM: The sender is a small domain, internal tool, or legacy system with only SPF. Forwarding breaks SPF (as explained above). There's no DKIM to fall back on. DMARC fails.
2. Forwarder modifies the message: The forwarder adds a footer, rewrites the Subject, or changes the Reply-To header. If any signed header is modified, DKIM validation fails. With SPF already broken, DMARC fails.
3. Misaligned DKIM: The original message is DKIM-signed by a third domain (e.g., a mailing list or an email service), not the From header domain. DKIM alignment still fails even though DKIM itself is valid. With SPF already broken, DMARC fails.
ARC: Preserving Authentication Through Forwarding
ARC (Authenticated Received Chain) solves this. It's a way for the forwarder to cryptographically seal the original authentication results and add its own signature.
When a mail server forwards with ARC:
- It evaluates SPF, DKIM, and DMARC on the incoming message.
- It adds ARC headers that cryptographically seal those results.
- The receiving server sees the ARC chain and knows the message was authenticated before forwarding.
Gmail, Yahoo, Microsoft Outlook, and other major providers honor ARC results. If the original message passed DMARC, the ARC seal tells the receiving server "this passed before it got forwarded," and the final server doesn't reject it for the SPF failure at the hop.
Cloudflare Email Routing adds ARC headers to forwarded mail by default. That's why forwarding through Cloudflare to Gmail usually works without DMARC failures.
How to Check Your Forwarded Mail
Use the Email Auth Checker to inspect the headers of a forwarded message. Look for:
- SPF result:
fail(expected after forwarding). - DKIM result:
pass(if the original sender had DKIM and the forwarder didn't modify the body). - DMARC result:
pass(if DKIM alignment holds). - ARC headers: Look for
ARC-Authentication-ResultsandARC-Seal(present if the forwarder supports ARC).
Practical Advice
If you forward email and see DMARC failures in your aggregate reports:
Check whether the original senders have DKIM. If they do, DMARC should pass even after forwarding (assuming the forwarder doesn't modify the message). If they don't, forwarding will break DMARC. When failures persist beyond forwarding, our guide to why your DMARC is failing covers the other common culprits.
If your domain receives p=reject and you forward heavily:
Consider staying at p=quarantine for now. p=reject tells receiving servers to outright reject mail that fails DMARC. If your domain is forwarded to external addresses, and those senders don't have DKIM, rejection will silently fail deliverability. Move to p=reject only when you're sure all your inbound mail either passes DMARC natively or is forwarded by an ARC-aware router.
For indie developers using Cloudflare Email Routing to Gmail:
This scenario works well. Cloudflare adds ARC headers, Gmail honors them, and forwarded mail lands in the inbox even if SPF fails at the Cloudflare hop.
Use the Email Auth Checker to see how your domain's authentication is configured and how forwarding affects specific messages.