
read receipts
Why the Email You Forwarded to Yourself Landed in Spam
You didn't do anything wrong. SPF did. Here's the mechanic nobody at your provider will explain.
Set up an auto-forward from your old account to your new one, and some of that mail will quietly vanish into spam — not because your provider is broken, but because forwarding rewrites who's sending the message without rewriting the cryptographic proof. SPF checks the wrong server, the DMARC verdict flips to fail, and a legitimate email you sent yourself gets quarantined. The fix has a name: ARC, defined in RFC 8617 back in 2019.
Why does forwarding make my mail fail SPF?
Because SPF checks the last server that relayed the message, and forwarding changes that server. SPF — Sender Policy Framework — is a DNS record that lists which IP addresses are allowed to send mail for a domain. When bank.com sends you a receipt, the receiving server checks: did this arrive from an IP bank.com authorized? Yes. Pass.
Now forward that receipt from your Gmail to your new address. Google's servers relay it onward. The final receiving server runs the SPF check and asks: is Google authorized to send for bank.com? No, it isn't. SPF fails. Google's own Workspace documentation spells this out plainly — forwarded messages fail SPF because the forwarding server isn't in the original domain's SPF record. Nothing was spoofed. The check is just looking at the wrong hop.
So why does that send it to spam?
DMARC. SPF failing alone used to be survivable; DMARC turned it into a verdict. DMARC ties SPF and DKIM together and tells receivers what to do when both fail: nothing, quarantine, or reject. By 2024, large senders had no choice — Google and Yahoo began requiring DMARC on anyone sending more than 5,000 messages a day to their users.
DKIM, the other pillar, is a signature baked into the message. In theory it survives forwarding, because it signs the content, not the route. In practice, anything that touches the message breaks it. A mailing list that appends a "you are subscribed, unsubscribe here" footer, a server that rewrites the subject line, even a change in how a line wraps — the signature no longer matches, and DKIM fails too. Now both pillars are down, DMARC says fail, and your own receipt is in the junk folder.
What is ARC and does it actually fix this?
ARC — Authenticated Received Chain, RFC 8617 — lets an honest forwarder vouch that the mail passed authentication before it touched it. The forwarding server stamps the message with a sealed record saying "when this reached me, SPF and DKIM were valid — trust my word for the leg you can't verify." The final receiver, if it trusts that forwarder, can override the DMARC fail and deliver.
The catch is in "if it trusts." ARC isn't a password; it's a reputation system. A receiver weighs whether the ARC sealer is a known, well-behaved operator. Google both stamps ARC headers and honors them from senders it trusts, which is why a Gmail-to-Gmail forward usually survives while a forward through some ancient university relay does not.
If you run the forwarding yourself, two concrete moves help. Use Server-Side Redirect / SRS-style rewriting if your host offers it, which rewrites the envelope sender so SPF checks against your forwarder instead of the original domain. And prefer forwarding between providers that both support ARC. If you're consolidating accounts and want the destination to just handle the authentication mess for you, that's exactly the kind of plumbing an AI email platform is built to absorb.
When should I stop blaming my provider?
When the pattern is "only forwarded mail fails," the provider is doing its job correctly — the protocol is the problem. Here's the tell: open the missing message's headers and look for the Authentication-Results line. If you see spf=fail alongside a sending IP that belongs to a forwarder rather than the original sender, that's SPF checking the wrong hop. If dkim=fail shows up on mail that went through a list or a relay that edits messages, that's a mangled signature, not a forgery.
The uncomfortable truth is that email authentication was bolted on, layer by layer, over two decades to a system that never assumed anyone would lie. SPF came in 2006, DKIM in 2007, DMARC in 2015, ARC in 2019 — each one patching a hole the last one opened. Forwarding is the seam where all four rub against each other, and your inbox is where you feel the friction.
Sources
- IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
- Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
- Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold