Domain Email with Cloudflare: Receiving, Sending, DNS and the Abuse Boundary

I used to think Cloudflare could only receive mail

A lot of old tutorials write Cloudflare domain email as a one-way street: mail forwards in, and sending has to be found elsewhere. That line is no longer complete.

As of this article's verification date, Cloudflare's Email Service includes both Email Routing and Email Sending (Beta). The former handles mail coming into the domain; the latter targets transactional email, and is bound by the current plan and Beta conditions.

But "can send" isn't the same as owning a full mailbox. Forwarding, an inbox, transactional email and marketing blasts are still four different products, and DNS, sender reputation, bounces and abuse responsibility don't disappear just because you're on Cloudflare.

This round didn't buy a new domain, deploy Cloud Mail or send test mail. The architecture below comes from Cloudflare's current docs and the maillab/cloud-mail repo; an actual deployment still has to re-check the plan, limits and project version.

Four needs that can't be blurred together

Mail forwarding

For example, forwarding mail received at [email protected] to your existing Gmail.

You don't necessarily own a full mailbox backend — you're just making a custom address an entrance.

A full mailbox

Users can log in, view the inbox, manage attachments, send mail and maintain the account.

Projects like Cloud Mail sit at this layer, needing a database, permissions, storage and a frontend.

Transactional email

Sign-up codes, password resets, order confirmations and system alerts. These are triggered by the application and emphasize deliverability, authentication and logging.

Marketing blasts

Newsletters and promotions. These need unsubscribes, complaint handling, list provenance, frequency and legal compliance.

Don't make a lightweight forwarding setup carry a full mailbox, and don't turn a transactional sending API straight into a marketing blaster.

The minimal setup: just custom-address forwarding

If you only want to publish [email protected], the simplest path is usually Email Routing:

1. Host the domain on Cloudflare.
2. Enable Email Routing.
3. Add and verify a real destination mailbox.
4. Create the custom address and a forwarding rule.
5. Add or confirm the DNS records the platform prompts for.
6. Send a test mail from an external mailbox.
7. In the destination mailbox, check the arrival time and the headers.

The success criterion isn't the console showing Active — it's external mail actually arriving, with the reply path behaving as you expect.

This setup doesn't automatically give you a full mailbox experience that sends from [email protected].

What a full Cloud Mail adds

The maillab/cloud-mail official repo shows the project is built on Cloudflare Workers and combines several services:

• D1 stores structured data.
• KV for caching or config.
• R2 stores attachments.
• A sender like Resend handles outbound mail.
• A Vue frontend provides the mailbox and admin UI.
• Turnstile prevents bulk abuse.
• Workers AI can handle extended abilities like CAPTCHA recognition.

The more components, the less you can treat it as "copy a few DNS records and you're done."

You're also responsible for:

• User permissions.
• Admin accounts.
• Database migrations.
• The attachment lifecycle.
• Sending credentials.
• Abuse limits.
• Backup and recovery.
• Version updates.

DNS: understand at least four record types

MX

Tells other mail servers where mail for this domain should go.

When MX is wrong, usually nothing arrives at all — it's not "arriving a little late."

SPF

Declares which servers may send on behalf of the domain.

SPF isn't better the longer it is. Multiple conflicting SPF records cause verification failures.

DKIM

The sending service uses a signature to prove the mail's content and identity. The public key is usually published via DNS.

Don't copy a DKIM value from someone else's tutorial — every domain and service has its own record.

DMARC

Tells recipients how to handle mail when SPF or DKIM don't pass, and can provide reports.

For a first setup, start from a monitoring policy: watch real traffic first, then tighten gradually. Setting a strict reject straight away can block your own legitimate mail too.

Receiving and sending have to be accepted separately

Receiving test

• Send from different external mailboxes.
• Check plain text and attachments.
• Check that forwarding keeps the necessary headers.
• Check the spam folder.
• Check how a non-existent address is handled.

Sending test

• Send to Gmail, Outlook and your own other mailboxes.
• Check From, Reply-To and Return-Path.
• Look at the SPF, DKIM and DMARC results.
• Check bounces.
• Check whether it lands in spam.
• Check the sending log.

A sending API returning 200 doesn't mean the recipient received it, let alone that the deliverability is good.

Domain email is not an identity-eligibility machine

An edu suffix, a corporate suffix or a custom address may look like some kind of organizational identity, but other platforms have their own eligibility checks and terms.

Don't use domain email for:

• Bulk-registering platform accounts.
• Impersonating a school or company.
• Bypassing student-eligibility checks.
• Getting discounts you don't qualify for.
• Receiving codes of unknown origin.
• Selling temporary mailboxes.

Technically possible isn't the same as compliant. Abuse can also damage the reputation of the whole domain and sending service.

Security checks for the admin backend

A full mailbox backend needs at least:

• A strong admin password.
• Two-step verification or controlled login.
• Least-privilege roles.
• Turnstile or rate limiting.
• Login and sending audits.
• Redaction of sensitive logs.
• Database backups.
• Attachment type and size limits.
• User registration closed or strictly reviewed.
• Admin interfaces that don't expose secrets directly.

The default admin password must be changed on first startup. Example values from the repo must not reach production.

Why attachments add risk

Attachments don't just take R2 storage — they can also carry malicious content and private data.

You need to be clear on:

• The maximum file size.
• The allowed types.
• How long they're kept.
• Who can download them.
• Whether the URL is guessable.
• Whether attachments are deleted when an account is deleted.
• Whether backups include attachments.
• Whether a virus scan runs.

Don't treat a public R2 bucket as a private mailbox-attachment directory.

The cost is the whole chain

Places that can incur cost include:

• Domain renewal.
• Workers requests.
• D1 usage.
• KV operations.
• R2 storage and reads.
• Email Sending.
• Resend or another third-party sender.
• Logs and monitoring.
• Over-quota and abuse requests.

Free tiers and Beta conditions change. Before deploying, check the current pricing pages for Cloudflare Email Service, Workers, D1, R2 and the sending service.

How to locate the common failures

Nothing arrives at all

Check the domain status, MX, routing rules and destination-mailbox verification.

Only some mail doesn't arrive

Check the sender's bounces, spam filtering, mail size and rule conditions.

Can receive but can't send

Confirm whether you configured Routing or Sending, and whether the sending service and domain authentication are complete.

Sent mail lands in spam

Look at SPF, DKIM, DMARC, domain reputation, mail content and complaints — not just swapping to a different SMTP.

Attachments won't open

Check R2 permissions, the object path, signed URLs, content type and lifecycle.

The backend lets anyone register unlimited users

That's not success — it's a sign you need to add access control and abuse limits immediately.

A personal site usually doesn't need a full mailbox system

If it's just a contact entrance:

• Use Email Routing to forward.
• Don't stand up a full mailbox backend.
• Use one long-term destination mailbox.
• Publish only a few addresses externally.

If the application needs codes and system notifications:

• Use a transactional email service.
• Configure SPF, DKIM and DMARC.
• Keep sending and bounce records.

Only when you genuinely need multiple users, inboxes, attachments and a backend should you deploy Cloud Mail.

For a personal site, stably getting one contact address into your own long-term mailbox is often already enough. Only when a real business needs inboxes, attachments and multiple users should you take on the maintenance responsibility of a full mailbox system.