What does Cloudflare Email Routing actually do to forwarded mail's authentication?

Two documented things at two stages. On receipt, Cloudflare checks SPF, DKIM, DMARC and ARC and rejects mail that fails the sender's DMARC policy. When forwarding, in Cloudflare's own words, it 'adds an ARC seal preserving the original authentication results and rewrites the envelope sender using the Sender Rewriting Scheme. This allows SPF to pass at the destination server.' The rewritten envelope sits at your routing domain — which is why the SPF record Cloudflare installs at your root authorises Cloudflare. The original message headers and body are preserved by design, so the original sender's DKIM signature can still verify at your mailbox; DMARC for the sender's domain at the destination therefore rides on that DKIM, sealed by ARC. That is why one forwarded message can legitimately show two different DMARC verdicts: the one Cloudflare recorded at receipt, and the one your mailbox computes on arrival.

Can I send mail as my domain with Cloudflare Email Routing?

No. Email Routing is a receiving and forwarding product — it stores nothing and sends nothing from your addresses. Cloudflare's own documentation states it 'cannot be used with external mail servers' on the same domain, meaning enabling it replaces your MX setup entirely. To send as the domain you need a different product: a mailbox provider (Google Workspace, Microsoft 365, iCloud+), a sending platform for application mail, or Cloudflare's separate Email Sending product (a developer product built on Workers/REST/SMTP; sending to arbitrary recipients requires the Workers Paid plan, which includes 3,000 messages a month then $0.35 per thousand). Owners most often discover the receive-only shape when a customer replies to info@ and the answer goes out from a personal Gmail — plan the sending half before you publish the addresses.

Cloudflare · Email Routing · Setup

Cloudflare Email Routing: a one-way mirror for your domain's mail

First published 20 October 2026 · Mechanics and limits from Cloudflare's current Email Service documentation (the product now lives under Compute → Email Service → Email Routing) and its ARC announcement. Dashboard screenshots for this one can be ours — merroway.tech's own zone (see the image note in §Sources).

RECEIVE-ONLY, BY DESIGN mail flows in and forwards onward — nothing is stored, nothing sends back out

Routing makes info@yourdomain real as a destination: messages land in a mailbox you already own. It is not a mailbox, not storage, and not a sending service — three facts owners usually learn in that order. Set it up knowing all three and it's the best free tool in this whole series.

Free · 200 rules/domain · catch-all includedSend-as-the-domain: not included, ever

The setup ladder

Add destination addresses first (Email Routing → Destination addresses): each real mailbox you forward to must verify via a confirmation email. Cap: 200 destinations per account.
Enable Email Routing on the domain. Cloudflare installs the record set below — first confirming the domain has no conflicting mail setup (its words: “Cannot use Email Routing with external mail servers”).
Create routing rules: custom addresses (info@, sales@, per-person) → destinations, up to 200 rules per domain, one destination per rule (an Email Worker using forward() is the documented fan-out for multiples). Add the catch-all rule if you want every other local part delivered too.
Read the records back (§table) — they're Locked after onboarding; you unlock them only through Email Routing Settings, and disabling routing deletes all three groups.
Publish your DMARC if you haven't: routing installs no _dmarc — DMARC remains the owner's job (Cloudflare's DMARC Management is the watching tool, Article #41).

Installed by routing	Value	Purpose
MX ×3	`route1/route2/route3.mx.cloudflare.net` (priorities auto-assigned)	Your domain's mail now arrives at Cloudflare
TXT (SPF) at `@`	`v=spf1 include:_spf.mx.cloudflare.net ~all`	Authorises Cloudflare's forwarding envelope (§Auth)
TXT (DKIM) at `cf2024-1._domainkey`	Cloudflare-provided key	Per Cloudflare's docs: “authentication for routed/forwarded emails” — note the docs never spell out a signing-header step beyond that wording; we quote it rather than embellish it

§Auth — what happens to a message, stage by stage

Stage	Documented behaviour
Receipt	Cloudflare evaluates SPF/DKIM/DMARC/ARC and rejects mail that fails the sender's DMARC policy (plus blocklist rejections). Your forward is protected by the sender's enforcement — most owners never realise routing enforces for them
Forwarding	Cloudflare's lifecycle text, verbatim: it “adds an ARC seal preserving the original authentication results and rewrites the envelope sender using the Sender Rewriting Scheme. This allows SPF to pass at the destination server.” The SRS envelope is at your routing domain — which is exactly what the installed SPF record authorises
At your mailbox	The message arrives with original headers/body preserved, so the sender's own DKIM can still verify; DMARC for the sender's domain at your mailbox therefore passes (if at all) via DKIM, vouched by the ARC seal Gmail/Microsoft read

The two-verdict puzzle, solved: Cloudflare's activity log can show a message's DMARC as judged at receipt, while your mailbox shows the same message judged on arrival (post-SRS envelope, DKIM-carried). Different inputs, different verdicts, both honest. When a forwarded message lands in spam, debug with the arrival-side headers (Article #12's method), not the log alone.

Sending as the domain — your actual options

Need	Route
Humans replying/sending as info@	A mailbox provider on the domain (Workspace/M365/iCloud+ — Articles #41–#45). This replaces routing: one MX master per domain
App/website transactional mail	An ESP (SendGrid/SES class, Articles #31/#32), usually on a subdomain (Article #40)
Developer sending, Cloudflare-native	Email Sending — Cloudflare's separate product (Workers binding/REST/SMTP). Arbitrary-recipient sending needs Workers Paid (3,000/mo included, then $0.35/1,000); sends to your own verified destinations are free on any plan. It is not a Routing upgrade toggle; it's a second product
“Send as” alias in Gmail over routing	A common hack (Gmail's send-as via your real provider's SMTP) — works only if you HAVE a sending service behind it; routing itself contributes nothing to the send

Limits (Cloudflare's limits page)

200 routing rules/domain · 200 destination addresses/account · 30 Routing+Sending domains/zone
25 MiB maximum inbound message — larger is rejected, not truncated
Inbound volume listed as Unlimited (no daily cap published — read that as “no documented cap”, not a promise)
Subdomain routing exists within the same product limits (per Cloudflare's docs) — useful for a mail. stream, but it inherits every caveat above

Traps

Trap	Reality
Publishing addresses before planning replies	Customers reply to info@; your answer leaves from a personal Gmail and the thread's professionalism (and SPF) collapses. Plan the send half first (§Sending)
Enabling routing on a domain with a real mail host	It replaces the MX — the M365 collision from Article #41, now from the other side. One domain, one inbound master
Debugging from the activity log only	Two verdicts exist (§Auth). The destination mailbox's headers decide spam placement
Expecting storage/search	Routing holds nothing. If the destination mailbox loses it, it's gone — routing is a mirror, not a copy

FAQ

Does routing hurt my domain's sending reputation?

Routing never sends as your domain, so there's no sending reputation to hurt. Your published SPF authorises Cloudflare for the forwarding envelope — expected, and exactly what the installed record is for.

A sender says their mail to me bounced “DMARC”.

That's receipt-stage enforcement doing its job: their mail failed their own domain's DMARC policy. The fix lives on their side (this entire site, essentially) — send them the relevant guide.

Can a rule forward to two people?

One destination per rule in the UI; the documented fan-out is an Email Worker calling forward() per address — a small developer step, free tier included.

Sources

Cloudflare Email Service documentation — Email Routing (setup, records, Locked state, external-server exclusion) · Email lifecycle page (receipt checks; SRS + ARC sentence verbatim) · Limits page (200/200/30; 25 MiB) · Email Sending/pricing pages (separate-product scope) · Cloudflare ARC announcement blog · Packs #41/#42 (the cf2024-1 record, DMARC Management).

Verification note: mechanics and limits confirmed from Cloudflare's current documentation on 20 October 2026. Two popular claims are deliberately absent: legacy route hostnames (isaac/linda/amir) appear in no current doc, and a circulating “forwards silently fail without sender auth since June 2025” claim has no official corroboration — the documented gate is DMARC enforcement at receipt.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.