Fix When SPF Passes but DKIM Fails on Forwarded Newsletters

Opened my email Monday morning and found three newsletters in spam. All three from senders I'd been reading for years. SPF: pass. DKIM: fail. DMARC: fail.

The thing that made no sense: these same newsletters delivered fine to my direct inbox. They only failed when forwarded through my personal domain's catch-all to my main account.

Took me longer than I'd like to admit to figure out what was happening. (Embarrassingly long, actually.) The forwarder was rewriting body content — appending a footer, modifying some HTML — and that broke the DKIM body hash. The signature that was perfectly valid when the newsletter left Substack or Mailchimp became invalid the moment the forwarder touched the body.

This is one of those problems that looks like a sender issue but isn't. The sender did everything right. The authentication was valid when they sent it. The forwarder broke it. (If you're seeing DKIM 'none' errors from third-party senders instead, that's a different problem — check that guide first.)

We're the JustEmails team — JustEmails is built by Velocity Digital Labs. We see this in support threads constantly: "my forwarded email goes to spam" or "DKIM fails but only sometimes." It's almost always this exact scenario — a forwarding step that modifies the message body after DKIM signing. Here's how to diagnose it, understand why it happens, and actually fix it.

Why DKIM Breaks on Forwarded Email (and SPF Doesn't)

SPF and DKIM authenticate different things. This matters more than you'd think for forwarding.

SPF checks whether the sending server's IP is authorized to send for the Return-Path domain. When you forward an email, your forwarding server becomes the sender. If your forwarder uses its own Return-Path (most do), SPF checks against the forwarder's domain — and passes, because your forwarder is authorized to send from its own domain. SPF doesn't care about the original sender at all in a forwarded message.

DKIM is different. DKIM signs specific headers plus a hash of the body. That signature is created by the original sender and travels with the message. When the message arrives at the final destination, the receiver recalculates the body hash and checks it against the signature.

Here's where forwarding breaks things. If the forwarder modifies the body — and they often do — the hash no longer matches. The DKIM signature becomes invalid. Common modifications that break DKIM:

• Adding a forwarding footer ("This message was forwarded by...")
• Stripping tracking pixels or images
• Reformatting HTML (different line lengths, character encoding)
• Removing attachments
• Adding mailing list footers

Even a single character change invalidates the signature. Not a bug. That's just how cryptographic hashes work — the signature proves the body wasn't modified. If the body was modified, the signature fails. I'll admit I spent way too long thinking this was broken behavior before accepting it's working exactly as intended.

DMARC ties this together. DMARC requires either SPF or DKIM to pass and align with the From domain. In a forwarded message:

• SPF passes for the forwarder's domain, not the original sender — no alignment
• DKIM fails because the body was modified — no alignment

Result: DMARC fails. If the original sender has p=reject, the email gets rejected. If p=quarantine, it goes to spam. This is correct behavior from DMARC's perspective — it can't verify the message's authenticity.

Diagnosing the Problem

When newsletters suddenly start hitting spam after being forwarded, verify it's actually a DKIM body hash issue and not something else.

Step 1: Check raw headers at the destination.

In Gmail, open the message, click the three dots, "Show original." In Outlook, View → View message source. Look for the authentication results:

Authentication-Results: mx.google.com;
       dkim=fail (body hash did not verify)
       spf=pass (google.com: domain of forwarder@yourdomain.com designates ...)
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT)

The key phrase: "body hash did not verify." That confirms the body was modified after signing. If you see "signature did not verify" instead, it could be a key lookup problem. But "body hash" specifically means modification.

Step 2: Compare to the direct-delivered version.

If possible, subscribe to the same newsletter at both addresses — the forwarded destination and a direct mailbox. When the next issue arrives, compare headers. The direct delivery should show:

dkim=pass header.i=@newsletter.substack.com
dmarc=pass

The forwarded version fails with the body hash error. Same email, different authentication results. That confirms the forwarder is the problem.

Step 3: Check what the forwarder adds.

Look at the body of the forwarded message. Is there a footer you didn't see in the original? Lines like "Forwarded by email-forwarding-service.com" or "This message was relayed through..."? That's your smoking gun.

The Fix: ARC (Authenticated Received Chain)

ARC exists for exactly this situation. It lets forwarders preserve the original authentication results even when they modify the message. Honestly, it's the kind of thing that should have existed from day one — but email standards move slowly.

Here's how it works:

1. Email arrives at the forwarder with valid DKIM and DMARC
2. The forwarder records the authentication results in ARC-Authentication-Results headers
3. The forwarder signs these results with its own key (creating ARC-Message-Signature and ARC-Seal headers)
4. The forwarder modifies and forwards the message
5. The destination receives the modified message with broken DKIM
6. But the destination also sees the ARC headers, verifies the forwarder's signature, and if it trusts the forwarder, honors the original authentication

ARC doesn't fix the broken DKIM signature — it can't, because the body was modified. Instead, it creates a chain of custody. "Yes, this DKIM is invalid now, but it was valid when I received it, and here's my signature proving I'm telling the truth."

Gmail, Microsoft 365, and Yahoo all support ARC on the receiving side. They maintain lists of trusted forwarders. If your forwarder is trusted and adds valid ARC headers, your forwarded newsletters will authenticate correctly.

Checking if your forwarder supports ARC:

Send a test through the forwarding path and check headers at the destination. Look for:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; s=arc-2024...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.com...
ARC-Authentication-Results: i=1; mx.forwarder.com; dkim=pass; spf=pass; dmarc=pass

If you see these ARC headers, the forwarder is doing its job. If you don't see them, it's not.

Services that support ARC:

• Gmail / Google Workspace forwarding
• Microsoft 365 forwarding
• Cloudflare Email Routing (they added this in 2024)
• Fastmail forwarding
• Proton Mail forwarding
• Most enterprise email gateways (Mimecast, Proofpoint, Barracuda)

Services that often don't support ARC:

• Simple forwarders bundled with domain registrars (varies — check headers)
• Legacy mail servers
• Some cheaper email forwarding services
• Self-hosted forwarders without ARC configured

If your current forwarder doesn't support ARC, switching to one that does is the cleanest fix. Yes, it's annoying. But it beats missing important emails.

Workarounds When ARC Isn't Available

Sometimes you can't switch forwarders. Maybe you're locked into infrastructure, or the forwarder is a mailing list you don't control. Options:

Receive newsletters directly at the destination.

Instead of forwarding me@mydomain.com to me@gmail.com, subscribe to newsletters directly at me@gmail.com. This isn't always practical if you want the mydomain address on file, but it eliminates the forwarding step entirely.

For newsletters you care about, this is often the simplest fix. Use the forwarding address for things you don't mind landing in spam occasionally. Not elegant, but it works.

Whitelist the newsletter sender at the destination.

Gmail's filter system lets you mark emails from specific senders as "never send to spam." This doesn't fix authentication — the DMARC failure still gets logged — but it prevents the practical problem of missing the email.

Create a filter:

1. From: newsletter@example.com
2. Never send to spam
3. Apply to existing conversations

(If you're cleaning up authentication for multiple domains, our DMARC ramp-up guide covers how to handle third-party senders without breaking your policy. For teams managing email across many product domains — something we do at VDL with JustAnalytics, ClickzProtect, and JustBrowser — keeping forwarding paths clean prevents cascading authentication failures.)

The downside: you're training yourself to ignore authentication failures, which kind of defeats the purpose of DMARC. Use this sparingly. I'm not a fan of this approach, but sometimes you just need your newsletters to show up.

Ask the sender to add your forwarding destination.

Some newsletter platforms let subscribers add multiple delivery addresses. If the sender can send to both me@mydomain.com and me@gmail.com, you get direct delivery at both — no forwarding needed.

Worth asking. Small newsletter operators are usually pretty accommodating if you explain the situation.

Use a forwarder that doesn't modify the body.

Some forwarders relay messages without adding footers or modifying content. The body passes through unchanged, DKIM stays valid. If you control the forwarder (self-hosted, or a service with configuration options), turn off footer insertion.

This is fragile though. Even character encoding normalization can break DKIM. But if the forwarder passes messages byte-for-byte, the signature survives. (I've seen this break for no apparent reason when a mail server got upgraded — fun times.)

Don't Weaken Your DMARC Policy

Tempting response: "I'll just change p=reject to p=none so my forwarded email works."

Don't. Your DMARC policy protects your domain from spoofing. Weakening it to accommodate forwarding failures means anyone can send email pretending to be you, and receivers won't reject it. This is a terrible trade-off.

The fix is the forwarding infrastructure, not the authentication policy. Switch forwarders, use ARC, receive direct — these solve the problem without opening your domain to abuse.

If you're a sender worried about your newsletters being rejected when recipients forward them, that's different. You can't control every recipient's forwarding setup. But if your DKIM is valid when you send and ARC-enabled forwarders preserve it, you've done your part. Recipients using non-ARC forwarders will have issues, but that's on their infrastructure, not yours.

Monitoring Forwarding-Related Failures

DMARC aggregate reports (the rua reports) show authentication failures. If you're seeing a pattern of DKIM body hash failures from specific IPs, those are probably forwarders — either yours or your recipients'.

Tools like dmarcian, Postmark DMARC Digests, or Valimail break down failures by source IP and show the failure reason. A cluster of "body hash did not verify" from IPs you recognize as forwarders confirms this is the issue.

(For anyone running email across multiple product domains — we manage nine domains at Velocity Digital Labs, including VeloCalls and VeloCards — centralizing DMARC reporting makes this kind of pattern spotting much easier.)

You can't fix recipients' forwarders. But you can verify your own domain's authentication is correct when messages leave your servers. If DKIM passes at the first hop and fails after forwarding, the problem isn't you.

Common Errors

Error: "dkim=fail (body hash did not verify)"

The message body was modified after DKIM signing. Either the forwarder added/removed content, or there was a character encoding change. The signature is cryptographically invalid.

Fix: Use an ARC-enabled forwarder, or eliminate the forwarding step.

Error: "dkim=temperror" or "dkim=permerror" on forwarded messages

The receiver couldn't look up the DKIM key (temperror) or the key record is malformed (permerror). This isn't forwarding-specific — it's a DNS issue.

Fix: Check that the sender's DKIM DNS records are published and correctly formatted. Use dig TXT selector._domainkey.senderdomain.com to verify.

Error: "arc=fail" despite ARC headers present

The ARC seal verification failed. Either the forwarder's ARC signing is broken, or a subsequent hop modified the ARC headers themselves.

Fix: Contact the forwarder. ARC signatures should be valid if the forwarder is operating correctly.

Error: DMARC passes intermittently on forwarded mail

Some messages forward without body modification (plain text), others get modified (HTML newsletters with added footers). The inconsistency depends on content type.

Fix: Same as above — ARC forwarder or direct delivery for consistent results.

Next Steps

If forwarding is breaking your newsletter deliverability, start with the diagnostic: check headers, confirm "body hash did not verify," and verify whether your forwarder supports ARC.

From there, the cleanest path is usually switching to an ARC-enabled forwarder. Cloudflare Email Routing is free and supports ARC. Gmail forwarding supports it. Microsoft 365 supports it. (If you need to set up MTA-STS alongside forwarding changes, our MTA-STS setup guide covers that piece.)

For newsletters you really can't miss, direct subscription at the destination mailbox is foolproof. No forwarding, no modification, no broken signatures.

The frustrating thing about this problem is that everyone did their job correctly. Sender signed the email. Forwarder forwarded it. Receiver enforced DMARC. The system worked as designed — it just doesn't account for legitimate forwarding that modifies content. ARC bridges that gap. If your forwarder supports it, great. If not, switch. Your inbox will thank you.

Frequently Asked Questions

Why does DKIM fail when email is forwarded but SPF passes?

DKIM signs a hash of the message body. When a forwarder modifies the body — adding a footer, stripping tracking pixels, reformatting HTML — the hash no longer matches what the sender originally signed. The DKIM signature becomes invalid. SPF, by contrast, only checks the sending IP against authorized servers and doesn't care about body modifications. So SPF passes (the forwarder's IP is authorized for their domain), but DKIM fails (the body hash mismatch), and DMARC fails because neither authentication mechanism aligns with the original sender's domain.

What is ARC and how does it fix forwarding authentication problems?

ARC (Authenticated Received Chain) is a protocol that lets forwarders preserve the original authentication results. When an ARC-enabled forwarder receives an email that passes DKIM and DMARC, it records those results in ARC headers before modifying the message. Downstream receivers (like Gmail) can then check the ARC chain: if the forwarder is trusted and the ARC seal is valid, the receiver honors the original authentication even though DKIM now fails. ARC doesn't fix the broken signature — it creates a chain of custody that lets receivers trust the forwarding path.

How can I tell if my email forwarder supports ARC?

Send a test email through the forwarder and check the raw headers at the destination. Look for headers starting with ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. If these are present, the forwarder is adding ARC headers. Gmail, Microsoft 365, Cloudflare Email Routing, and major enterprise forwarders support ARC. Many simple email forwarding services and legacy servers don't. If you don't see ARC headers, the forwarder isn't preserving authentication — you'll need a different forwarding solution or to receive newsletters directly.

Should I loosen my DMARC policy to fix forwarding failures?

Don't weaken your DMARC policy (moving from p=reject to p=quarantine or p=none) just to accommodate forwarding failures. That opens your domain to spoofing. Instead, fix the forwarding path: switch to an ARC-enabled forwarder, receive newsletters at the destination mailbox directly instead of forwarding, or ask the sender to add your forwarding destination to their list. A strict DMARC policy protects your domain — work around the forwarding problem without compromising that protection.

---

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares