Cloudflare email is three products, not one mail stack
Cloudflare can forward inbound mail, run code on it, and send transactional mail. Each capability has a different setup gate. A verified forwarding address is not an onboarded sending domain.
| Product surface | Direction | What it does | Prerequisite | What it does not replace |
|---|---|---|---|---|
| Email Routing | Inbound | Maps an address or catch-all to a verified destination or Worker | Domain onboarded for routing; routing MX, SPF, and DKIM records | A mailbox, outbound sender, campaign system |
| Email Workers | Inbound, plus constrained reply/forward | Runs an email() handler over the raw message | Active route bound to a deployed Worker; destinations verified before forwarding | General arbitrary outbound on the free plan |
| Email Service / Email Sending | Outbound | Sends transactional mail through a Worker binding, REST, or SMTP | Sending domain onboarded; Paid plan for arbitrary recipients; send_email binding for Workers | Marketing automation, customer subaccounts, full ESP operations |
Verified destinations are free on every plan; arbitrary recipients require Workers Paid. Paid includes 3,000 outbound messages per account each month, then costs $0.35 per 1,000. Inbound is unlimited, although processing consumes Worker resources.
Evidence status
Observed marks first-party measurements or runtime receipts from the named environment. Derived marks arithmetic calculated from cited inputs. Specified marks vendor or standards documentation. Implemented and deployed name code and live-state evidence, respectively. Reproduced means the stated procedure was rerun. Externally attested marks operator reports; those reports show that an experience occurred, not that it is universal.
The setup begins with DNS, not code
For inbound routing, the dashboard path is:
Cloudflare dashboard → account → Compute → Email Service → Email Routing → Onboard Domain
For example.com, Cloudflare creates this root-domain shape:
MX @ route1.mx.cloudflare.net
MX @ route2.mx.cloudflare.net
MX @ route3.mx.cloudflare.net
TXT @ "v=spf1 include:_spf.mx.cloudflare.net ~all"
TXT cf2024-1._domainkey "v=DKIM1; h=sha256; k=rsa; p=<Cloudflare public key>"Cloudflare assigns MX priorities. Merge the Cloudflare include: into an existing SPF record; two SPF records are invalid, and SPF has a ten-lookup ceiling.
For outbound Email Sending, onboarding is separate:
Cloudflare dashboard → account → Compute → Email Service → Email Sending → Onboard Domain
The outbound records live under cf-bounce.example.com, leaving the inbound root MX records alone:
MX cf-bounce route1.mx.cloudflare.net
MX cf-bounce route2.mx.cloudflare.net
MX cf-bounce route3.mx.cloudflare.net
TXT cf-bounce "v=spf1 include:_spf.mx.cloudflare.net ~all"
TXT cf-bounce._domainkey "v=DKIM1; h=sha256; k=rsa; p=<Cloudflare public key>"
TXT _dmarc "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Cloudflare says DNS commonly settles in 5–15 minutes but can take up to 24 hours. The practical gate is that the Email Sending screen shows the domain onboarded and DNS queries return the records. Start DMARC at p=none if other providers still send for the domain; enforce only after their identities align.
Routing rules, verified destinations, and the catch-all
Forwarding requires a destination address that the recipient has verified. The dashboard path is:
Compute → Email Service → Email Routing → Destination Addresses
Cloudflare emails that address a verification link. A routing rule pointing at an unverified destination remains disabled. Once verified, create a rule under:
Compute → Email Service → Email Routing → Routing Rules → Create routing rule
The action is send to a verified address, send to a Worker, or drop. If two rules use the same pattern, only the first processes the message. Renaming a Worker breaks routes that point to its old name.
The catch-all is a separate rule on the Routing Rules screen. Turn it on, choose Send to a Worker, select the deployed Worker, and save. It catches every otherwise-unmatched local part, so add size checks, sender policy, and retention.
| Intent | Route | Destination |
|---|---|---|
| Ordinary inbox alias | hello@example.com | Verified personal or team inbox |
| Support ingestion | support@example.com | Email Worker |
| Per-customer intake | inbox+customer-id@example.com | Email Worker with subaddressing enabled |
| Any unmatched local part | Catch-all | Worker, then explicit allow/reject logic |
| Address that should appear valid but retain nothing | Named rule | Drop |
With subaddressing enabled, inbox+acme@example.com matches inbox@example.com while preserving +acme in message.to.
A runnable inbound Worker that parses MIME and stores attachments
The useful inbound architecture is short:
Cloudflare MX → Email Routing catch-all → email() handler → postal-mime → R2 objects + application record
Install postal-mime, bind an R2 bucket, and deploy the Worker:
npm install postal-mime
npx wrangler r2 bucket create inbound-attachments
npx wrangler deploy{
"name": "inbound-mail",
"main": "src/index.ts",
"compatibility_date": "2026-07-01",
"r2_buckets": [
{ "binding": "ATTACHMENTS", "bucket_name": "inbound-attachments" }
]
}import PostalMime from "postal-mime";
interface Env {
ATTACHMENTS: R2Bucket;
FORWARD_TO: string;
}
function safeName(name: string): string {
return name.replace(/[^a-zA-Z0-9._-]/g, "_").slice(0, 180);
}
export default {
async email(message: ForwardableEmailMessage, env: Env): Promise<void> {
if (message.rawSize > 25 * 1024 * 1024) {
message.setReject("Message exceeds the 25 MiB inbound limit");
return;
}
const parsed = await PostalMime.parse(message.raw);
const received = new Date().toISOString();
const mailId = crypto.randomUUID();
for (const [index, attachment] of (parsed.attachments || []).entries()) {
const filename = safeName(attachment.filename || `attachment-${index}`);
const key = `mail/${received.slice(0, 10)}/${mailId}/${filename}`;
await env.ATTACHMENTS.put(key, attachment.content, {
httpMetadata: {
contentType: attachment.mimeType || "application/octet-stream"
},
customMetadata: {
envelopeFrom: message.from,
envelopeTo: message.to,
subject: (parsed.subject || "").slice(0, 500)
}
});
}
await message.forward(env.FORWARD_TO);
}
} satisfies ExportedHandler<Env>;message.raw is a single stream. If two consumers need it, buffer once with new Response(message.raw).arrayBuffer(). The handler also exposes envelope addresses, headers, size, setReject(), forward(), and reply().
postal-mime handles multipart boundaries, encodings, and character sets. Treat filenames and MIME types as untrusted. Generate the key, cap size, and scan before serving.
One operator reports: “I’m using Cloudflare Email Routing with a catch-all address that triggers a Worker. The Worker parses the email and stores the attachments in R2.” It is one working implementation, not a universal guarantee.
For the storage half, see R2 cuts a 10 TB delivery bill from $923 to $18.45. That chapter covers binding calls, public versus private objects, versioning gaps, and cost.
Replying is not the same as arbitrary sending
The inbound message object can forward to verified routing destinations. It can also reply with a raw EmailMessage constructed from cloudflare:email:
import { EmailMessage } from "cloudflare:email";
import { createMimeMessage } from "mimetext";
export default {
async email(message: ForwardableEmailMessage): Promise<void> {
const msg = createMimeMessage();
msg.setSender({ name: "Example support", addr: "support@example.com" });
msg.setRecipient(message.from);
msg.setSubject("Re: " + (message.headers.get("subject") || "your message"));
msg.addMessage({
contentType: "text/plain",
data: "We received your message."
});
const reply = new EmailMessage(
"support@example.com",
message.from,
msg.asRaw()
);
await message.reply(reply);
}
};This is tied to the inbound message. message.reply() throws above 100 References entries, and forwarding destinations must be verified.
New outbound mail uses Email Service
After onboarding, bind Email Service to a paid Worker:
{
"send_email": [
{ "name": "EMAIL" }
]
}Call env.EMAIL.send() with an onboarded-domain from, recipient objects, subject, text, and HTML.
The prerequisite chain is:
- The zone is in the Cloudflare account.
- Email Sending shows the domain as onboarded.
- The
cf-bounceMX, SPF, DKIM, and DMARC records resolve. - The Worker is on Workers Paid for arbitrary recipients.
- The Worker has a
send_emailbinding and uses the onboarded domain infrom. - The message stays inside recipient, header, and size limits.
Before onboarding, sends are limited to verified destinations and routing domains. After onboarding, arbitrary recipients are allowed, subject to daily quota and reputation. New accounts start with a conservative quota that Cloudflare adjusts over time rather than publishing one universal number.
Current limits include 50 combined recipients, 998 subject characters, 16 KB of custom headers, and 5 MiB total. Verified-destination mail may be 25 MiB. A zone may have 30 combined Routing and Sending domains; Routing allows 200 rules per domain and 200 verified destinations per account.
The site's own split proves why the prerequisite must be visible
This build has a Pages endpoint at POST /api/email/send. It authenticates the owner, then proxies the body to a sibling Worker because Pages cannot carry the send_email binding. The sibling declares:
[[send_email]]
name = "EMAIL"The public diagnostic response currently says:
{
"inbound": {
"loop@miscsubjects.com": "forward → cyrus@dsco.co",
"build@miscsubjects.com": "worker → ledger + forward"
},
"sending": "Enable Email Sending on miscsubjects.com in CF dashboard (Pages cannot bind send_email)"
}Code and a binding are not proof of a send-capable domain. The prerequisite remains open until onboarding and an observed delivery receipt.
On July 26, 2026, miscsubjects.com resolved three Cloudflare routing MX records, root SPF, cf2024-1 DKIM, and DMARC p=reject. The sending selector also returned a key, but DNS alone does not prove onboarding or delivery. No email was sent.
SPF, DKIM, DMARC, and ARC in plain language
| Mechanism | What it asserts | What forwarding changes |
|---|---|---|
| SPF | The connecting server is authorized for the envelope sender's domain | A forwarder connects from a new IP, so the original SPF relationship can break |
| DKIM | A domain signed selected headers and body bytes with a key published in DNS | It can survive forwarding if the signed bytes remain intact |
| DMARC | The visible From: domain must align with a passing SPF or DKIM identity, then applies a policy | Forwarding can disturb SPF; mailing-list or gateway modifications can disturb DKIM |
| ARC | Intermediaries preserve a signed chain of the authentication result they observed | A destination can evaluate the forwarder's attestation when direct SPF or DKIM no longer tells the whole story |
Cloudflare uses Sender Rewriting Scheme, changing the envelope sender so SPF can pass from its relay while leaving visible From: unchanged. Routing adds DKIM, and ARC preserves authentication results through the forwarding hop.
ARC is evidence, not an override switch. The final provider still applies its own reputation, block-list, policy, and content decisions. A message can authenticate and still be rejected or placed in spam.
The Outlook reports are real, but they are not a universal result
Two independent operator reports describe Microsoft blocking Cloudflare Email Routing IP ranges. Handy-Man writes that Outlook “just blocks Cloudflare IP ranges and emails never get routed to my Outlook mail box.”
In a separate discussion, doubled112 reports that Microsoft “intermittently block Cloudflare email routing IPs too,” despite the surrounding SPF, DKIM, and DMARC work.
A third independent account documents Outlook failures through Cloudflare routing.
These reports establish a failure mode, not prevalence. Shared relays can inherit reputation from other traffic. Authentication improves identity evidence; it does not require a provider to accept an IP.
When forwarded mail disappears, inspect the Email Routing activity log first. Separate these cases:
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| Rule is disabled | Destination never verified | Destination Addresses status | Resend verification and activate the rule |
| No routing event | MX or rule mismatch | dig MX, rule order, exact recipient | Finish onboarding; repair the pattern |
| Worker invocation failed | CPU, memory, exception, or renamed Worker | Workers logs; route target | Fix the exception or rebind the renamed Worker |
| Forward call rejects | Destination is not verified | Destination list and Worker log | Verify the exact address before forwarding |
| Routing says delivered, inbox has nothing | Destination provider rejected, deferred, or filtered it | Routing activity, SMTP response, spam/quarantine | Test another verified destination; give Cloudflare the event and SMTP evidence |
| Sending call succeeds but Routing summary says “dropped” | Outbound Worker mail is shown that way in Routing | Email Sending metrics and logs | Use Email Sending observability, not the Routing label |
Local attachment test throws Cannot serialize value: [object ArrayBuffer] | Local runtime limitation | Reproduce on deployed Worker | Test binary attachments against the deployed Worker |
| Reply throws on a long thread | More than 100 References entries | Count References values | Start a new message or trim the reply path |
Cloudflare warns about multiple SPF records, missing selectors, alignment, new-domain reputation, bounces, and provider filtering. Binary attachments can also hit a local ArrayBuffer serialization limit even when deployment works.
One developer followed the cloudflare:email and EmailMessage path, verified an address, and reported no arrival or error. The unanswered report cannot establish cause. It does show why a resolved Promise is not delivery proof. Check destination verification, onboarding, Email Sending logs, spam, quarantine, and SMTP events.
Where Cloudflare Email Service still is not SendGrid
Transactional sending is not the whole ESP product.
One SendGrid operator creates subaccounts by API so customers can verify their own domains with DKIM and SPF. Cloudflare's documented flow onboards zones from its account; it does not document an equivalent delegated subaccount system. Do not promise one without a specific API and proof.
The gaps are operational: durable bounce handling, suppression recovery, versioned templates, tenant analytics, and marketing consent or unsubscribe controls. Conservative daily quotas, reputation scaling, 50 recipients per message, and the limit-increase process keep “transactional” a real boundary.
A project can build those layers on Workers, D1, R2, and Queues. One operator is building an AGPL email platform in each user's Cloudflare account. Once those layers are included, the work is an email product, not a send call.
Cost is attractive; replacement scope is the constraint
At current list price, Cloudflare Paid includes 3,000 outbound messages monthly and charges $0.35 per 1,000 after that.
| Outbound transactional volume | Cloudflare Email Service usage line | What the arithmetic excludes |
|---|---|---|
| 3,000/month | Included in Workers Paid | Paid plan itself; application work |
| 10,000/month | $2.45 above the included 3,000 | Templates, bounce workflow, analytics |
| 100,000/month | $33.95 above the included 3,000 | Reputation operations and support |
| 1,000,000/month | $348.95 above the included 3,000 | Quota approval and product controls |
The formula is max(0, messages - 3,000) / 1,000 × $0.35. Accepted hard bounces count; API-boundary rejections do not. Verified-destination sends are free.
Resend packages volume with retention, domain, team, and feature limits. Compare the operating requirement, not only cost per thousand.
Cloudflare's price works best for receipts, password resets, alerts, and other application mail from one owned domain. Customer-domain onboarding, mature suppressions, templates, analytics, and marketing change the comparison.
The decision table
| Workload | Best first choice | Why |
|---|---|---|
| Receive-only aliases into an existing inbox | Email Routing | No mailbox migration; verified forwarding destination |
| Receive and inspect, reject, archive, or branch | Email Routing → Email Worker | Code runs at the SMTP ingress and can store to R2 |
| Inbound email webhook with attachments | Catch-all or named route → Worker → parser → private R2 | One event path; binary payload leaves D1 |
| Transactional mail from one owned domain | Email Service on Workers Paid | Onboarded domain, low unit price, native binding |
| Send only to a few fixed internal addresses | Verified destinations | Free, constrained anti-abuse path |
| Customer-owned sending domains and subaccounts | Established ESP until proven otherwise | Tenant onboarding and reputation boundaries are product features |
| Marketing campaigns and newsletters | Marketing ESP | Consent, unsubscribe, segmentation, templates, analytics |
| Full hosted mailbox with IMAP, folders, search, calendars | Mail provider | Cloudflare Email Service is transport and compute, not a mailbox |
Migrate in the same order: verify inbound routing and destination receipt, then the Worker and stored R2 objects. Onboard sending separately and keep the ESP until bounces, suppressions, quotas, logs, and delivery have owners.
The final test is one real message in, the intended Worker invocation, the expected object or forward, and the result at the destination. Outbound needs the production send plus recipient delivery. Until then, it is configured, not proven.
Key evidence
6 more ranked claims
Ask this article · 8 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.