Skip to main content

Command Palette

Search for a command to run...

cloudflare email routing tags ur domain as "forwarder" (its fine)

Updated
โ€ข2 min read
B
Backend engineer running BaoDev.studio โ€” a small team of senior engineers powered by AI agents. We ship production software fast: sprint delivery in 1-5 hours, full system builds in 2-8 days. Tech I use most: Go, Next.js, Python, TypeScript, PostgreSQL, Redis, Qdrant, LLM agents, RAG pipelines, microservices, Docker, Cloudflare. See more at BaoDev.studio.

set up cloudflare email routing for baodev.studio a few weeks ago. ran a usercheck.com deliverability check the day after to confirm nothing was broken. domain came back tagged "forwarder" ๐Ÿ˜ฌ

panicked for an hour. its actually fine.

whats happening

cloudflare email routing accepts inbound mail on cloudflare's own MX servers, then forwards to ur destination mailbox (usually gmail/workspace). MX records look like:

@   IN MX 10 route1.mx.cloudflare.net.
@   IN MX 20 route2.mx.cloudflare.net.
@   IN MX 30 route3.mx.cloudflare.net.

any third-party scanner that classifies by MX shape (usercheck, mailtester.com, mxtoolbox) reads this as a forwarder configuration. thats literally what it is at the protocol level โ€” cloudflare-owned servers that dont themselves host mailboxes.

but gmail/outlook/apple mail dont use that classification for delivery decisions. they look at SPF and DKIM at the destination, which cloudflare handles correctly through envelope-sender rewriting during the relay step.

what cloudflare actually does

envelope-sender rewriting: when cloudflare forwards a message, it replaces the envelope From with a cloudflare-controlled address. this prevents SPF failures at the destination โ€” the SPF check now passes against cloudflare's own SPF record, which is permissive.

DKIM signatures from the original sender survive the relay untouched. gmail can validate the original DKIM and treat the message as legitimate. the message envelope is rewritten but the Authentication-Results header at the destination reports the original DKIM pass.

you can see this directly. in gmail, open the message, click the three-dot menu, "Show original". look for dkim=pass in Authentication-Results.

what to actually check

send urself a test message from another mailbox (gmail โ†’ baodev.studio in my case). check it arrives in the destination inbox. open headers, look for dkim=pass and spf=pass. thats the real deliverability signal.

then run mail-tester.com on a test outbound. mine scores 9/10 with the default cloudflare routing setup, no extra config. anything 8/10+ is healthy.

if Authentication-Results shows dkim=fail or spf=fail at the destination, thats the actual problem worth digging into. the "forwarder" classification by itself is just a literal MX-shape description.

tldr

forwarder tag alone = ignore. forwarder tag + DKIM/SPF failures at destination = real config issue.

this pattern affects any setup where ur MX server forwards to a different mailbox (not just cloudflare). worth knowing so u dont spend an hour debugging a non-problem.