How should a product team implement Cloudflare email routing safely?

Define the inbound job and ownership boundary

Start by writing down the exact inbound job: which domain and local parts should accept mail, who owns each destination, whether a message should be forwarded, processed by code, or dropped, and how long operational evidence may be retained. Cloudflare Email Routing is an inbound routing layer. It does not by itself create a support ticket, establish sender identity, prove that forwarded mail reached a human, or guarantee mailbox placement at the destination. Keep those later application states separate. Assign an operational owner for DNS, routing rules, Worker code, destination verification, security incidents, and rollback. Use dedicated aliases such as support@ or invoices@ rather than a catch-all during the first rollout. A narrow route reduces accidental collection, makes test outcomes interpretable, and limits the impact of a mistaken destination or Worker branch.

Onboard the domain without treating DNS as a blind install step

Cloudflare's current Email Service documentation says the domain must use Cloudflare DNS for Email Routing. The onboarding flow can add MX records for inbound routing plus SPF and DKIM-related TXT records described by the product. Review the exact proposed records before applying them. Inventory existing MX, SPF, DKIM, DMARC, mailboxes, forwarding services, verification tokens, and subdomain delegations first. Replacing MX records changes where new inbound SMTP sessions go, so coordinate a maintenance window and preserve the prior values as a rollback record. Avoid creating multiple SPF TXT records at one owner name. After the change, query authoritative and public resolvers, then test delivery from an account unrelated to the destination. DNS propagation estimates are not proof that every sender now sees the same answer, and a green dashboard does not prove end-to-end forwarding.

Verify destinations before creating active routes

Cloudflare documents destination addresses as account-level resources that must be verified before routing rules can use them. The verification step is an important anti-abuse boundary: it demonstrates control of the mailbox at that moment, but it does not establish ongoing business authorization or correct team membership. Record the requesting owner, purpose, verification date, and review date in your own system. Prefer a team-controlled destination over an employee's personal address. Remove departed-user destinations promptly and check which rules depend on an address before deletion, because Cloudflare documents that deleting a destination disables routes that use it. Treat verification emails as security-sensitive and never auto-click or forward them into untrusted automation. For production changes, require a second-person review in your normal infrastructure process even if the dashboard itself allows a single operator to save the rule.

Create explicit rules and understand precedence

A routing rule pairs an email pattern with either a verified destination or a Worker. Cloudflare documents three actions: send to an email, send to a Worker, and drop. Create the most specific local-part routes first, name their owner in change records, and confirm there is only one intended rule per pattern. The documentation warns that if multiple rules use the same pattern, only the rule listed first processes incoming mail. Do not rely on visual order as an informal business rule; remove ambiguity instead. Keep drop rules narrowly justified because deletion is intentionally non-delivery. Enable catch-all only after enumerating its privacy, spam-volume, typo, and storage consequences. A catch-all can collect addresses nobody meant to create, so it should have a dedicated destination or Worker policy, alerts, and a fast disable path rather than quietly inheriting a personal mailbox.

Use subaddressing deliberately

Cloudflare documents optional plus addressing consistent with RFC 5233. When enabled, mail for an address such as user+detail@example.com can match the base user@example.com rule while preserving the detail in the message recipient exposed to a Worker and logs. That can support routing tags, testing identifiers, or per-workflow aliases, but the detail is sender-controlled text. Do not treat it as authenticated tenant identity, authorization, or a secret. Normalize and bound it before using it as a database key, metric dimension, or queue name. Cloudflare also documents that an explicit rule for the full subaddress takes precedence over the base rule. Test both the explicit and fallback cases so a later specific rule does not silently change an existing workflow. Avoid putting personal or confidential data in plus tags because they can appear in headers, logs, forwarded messages, support exports, and analytics.

Choose a Worker only for real processing needs

Use direct forwarding when the requirement is simply one address to one verified mailbox. Route to a Worker when you need controlled branching, message inspection, storage, rejection, replies, or multiple forwards. Cloudflare's email handler exposes the envelope sender and recipient, headers, a raw MIME stream, its size, and methods to forward, reply, or reject. Keep the handler small: validate recipient policy first, enforce message and parsing bounds, make external calls through time-bounded queues where possible, and define the outcome for every error. Headers, subjects, display names, attachments, links, and MIME boundaries are attacker-controlled. Do not log raw bodies or full addresses by default. If content must be stored, encrypt it, restrict access by tenant and job, define deletion, and scan attachments outside the synchronous routing path. A parsing exception must not fall through to an unintended forward or reply.

Implement one explicit decision path

A safe handler should compute an approved action before performing side effects. For example, map the exact envelope recipient to a configured workflow, reject unknown recipients, enqueue a bounded metadata record, then forward only to a verified destination selected from configuration. Never accept a destination from a message header, subject, plus tag, or body. When forwarding to several destinations, Cloudflare's limits documentation says a Worker must call forward once per verified destination; decide whether partial success is acceptable and record each attempt separately. Use a stable internal correlation identifier rather than recipient content in logs. If the handler may reply, follow Cloudflare's current reply constraints and add loop protection. A reply is not an acknowledgement from a human team. If durable application intake is required, store the ticket or event before sending an automatic response and reconcile ambiguous failures rather than promising that work was created.

Treat forwarding and replies as evidence-scoped outcomes

A successful Worker method call is evidence about the platform operation, not the final user outcome. SMTP defines transfer between systems, while later filtering, forwarding, quarantine, mailbox rules, and human reading remain outside that hop. Model states such as received by Cloudflare, Worker invoked, action attempted, destination server accepted, delayed or failed, and application record created separately. Do not label them all delivered. Keep structured, privacy-minimized logs with rule identity, Worker revision, action, timestamp, correlation identifier, and coarse result; store full addresses or content only where a documented operational need justifies it. Alert on invocation failures, size rejections, abnormal catch-all volume, repeated sender patterns, destination failures, and sudden traffic changes. Sample controlled test messages continuously, but never use real customer content as an observability fixture.

Respect current platform limits and failure modes

Cloudflare currently documents Email Routing limits including 200 routing rules per domain, 200 destination addresses per account, a 25 MiB inbound message-size limit, and standard Workers CPU and memory limits for Worker-routed messages. Treat these as current provider documentation, not permanent constants. Read the live limits page during planning and alert well before approaching a cap. Large MIME messages can exhaust memory or CPU even below the platform's raw size ceiling if decoded incautiously. Stream or reject unnecessary content, cap attachment counts, and place expensive parsing behind bounded asynchronous work. A Worker rename can break its routing binding according to Cloudflare's routing documentation, so include route inspection in deployment verification. Failed invocations should be visible in Workers logs, but logs alone do not create replay. Decide whether a sender should retry through SMTP, whether an operator can safely replay an application job, and how duplicate downstream records are prevented.

Test rollout and rollback as one change

Create a staging or low-risk route first. Send controlled messages from a different account than the verified destination, covering plain text, multipart content, expected attachments, plus addressing, unknown local parts, and deliberately malformed inputs within safe limits. Verify DNS answers, dashboard configuration, Worker revision, forwarding result, downstream record, and privacy behavior. Then test negative paths: unverified destination, disabled rule, Worker exception, oversized message, repeated delivery, and a rule that would otherwise fall into catch-all. Record expected evidence for each stage. Before expanding traffic, rehearse disabling the rule, restoring the earlier MX records if necessary, detaching the Worker, and communicating delayed or rejected mail. Roll back on unexplained routing loss, cross-tenant exposure, content leakage, unexpected replies, unbounded storage, or sustained Worker failure. Preserve configuration snapshots and test results without retaining message content longer than needed.

How SendHQ fits

SendHQ supports inbound email. This guide covers Cloudflare Email Routing; follow each service's documentation for its own setup and limits.

Frequently asked questions

Sources

• Route emails — Cloudflare
• Email routing rules and addresses — Cloudflare
• Workers API for routed email — Cloudflare
• Cloudflare Email Service limits — Cloudflare
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC Editor