Email Routing architecture
Email Routing receives mail for a Cloudflare DNS zone and forwards or processes it; it is not a mailbox or outbound SMTP service.
What Email Routing provides
Email Routing receives messages for addresses on a Cloudflare DNS zone and forwards them to verified destination addresses or to a Worker with an email handler. It is not a mailbox, outbound SMTP relay or message archive. Replies are sent by the destination mailbox unless a separate sending service is configured.
DNS records required for inbound routing
The domain must use Cloudflare authoritative DNS. Enabling the service publishes MX records for Cloudflare and TXT records used for SPF and DKIM. Existing MX records should be inventoried first because ordinary inbound mail must not be split unpredictably between unrelated providers.
- Preserve SPF, DKIM and DMARC data used by every legitimate outbound sender.
- Mail records remain DNS only.
- DNS propagation commonly completes in minutes but cached answers can live for the configured TTL.
Domain and routing configuration
MX records, verified destinations and ordered routing rules form one delivery path that must remain internally consistent.
Destination addresses and verification
A destination address is account-level and reusable across zones. Cloudflare sends a verification message before routing to it. A rule that points to an unverified destination remains disabled. Deleting a destination disables every rule that uses it.
- Protect the destination mailbox with strong authentication.
- Remove destinations when the owner no longer requires access.
- Verification proves control of the mailbox; it does not authorize outbound sending from the source domain.
Literal addresses, catch-all and drop rules
A literal rule matches one local address. A catch-all receives addresses not matched by a more specific rule and can attract spam and mistakes. A drop action discards matching mail. Design specific aliases first, then add a catch-all only when its operational value outweighs the noise.
- Avoid loops where the destination forwards back to the source domain.
- Use a monitored destination for business-critical aliases.
- Document intentional drop rules so missing mail is not diagnosed as a delivery fault.
Delivery validation
Test from an unrelated sender and inspect authentication and forwarding results before depending on a new route.
Email Workers
An Email Worker can inspect a message and decide whether to forward, reject or process it. The Worker needs an email event handler and an explicit policy for allowed senders, destinations, attachments, size and failures. Do not log message bodies or credentials unless a defined security and retention requirement demands it.
Authentication and forwarding consequences
Forwarding preserves the original message but changes the delivery path. SPF can fail after forwarding because the forwarding server is not the original sender; DKIM and DMARC outcomes depend on the original signature and alignment. Inspect received headers before changing authentication policy in response to one failed message.
Limits and troubleshooting
Loops, catch-all traffic, stale MX answers and destination verification are the common boundaries of a forwarding design.
Test an Email Routing deployment
Send messages from an unrelated external mail system to every critical alias. Confirm delivery, original From and Reply-To behaviour, attachments, spam placement and authentication results. Test a non-existent address to confirm the catch-all or rejection behaviour.
Troubleshoot missing or looping mail
Check public MX and TXT answers, destination verification, rule enabled state and destination spam folders. Inspect message headers and any Worker errors. For a loop, disable the affected rule before changing several mail systems. For a failed cutover, restore the recorded MX set and keep both old and new destinations monitored during cache expiry.
