Direct answer: ArawaMail requires an active Cloudflare zone whose name matches the domain exactly. Unlock or disable Cloudflare Email Routing before Activate receiving, keep every mail-related hostname DNS-only (grey cloud), then Activate sending so DKIM CNAMEs and custom MAIL FROM records can publish. Create mailboxes only after receiving is active. An Email Worker is not a staff inbox.
Fix the three setup failures before the happy path
Most “Cloudflare domain connected but mail still broken” tickets in 2026 collapse into three causes. Resolve these first; then the official order is short.
- Email Routing still owns the MX. When Routing is enabled, Cloudflare manages and can lock the zone’s MX (commonly
route1/route2/route3.mx.cloudflare.net, plus an SPF include). ArawaMail cannot share those MX records. Activate receiving will fail or leave inbound on Cloudflare until you unlock or disable Routing. - Orange-cloud proxy on a mail hostname. MX itself is always DNS-only, but the hostname an MX points at must also resolve without the proxy. Unexpected names like
_dc-mxordc-#####usually mean Cloudflare rewrote a proxied mail target. Flip those hostnames to DNS-only. - An Email Worker treated as a mailbox. Workers can inspect, route, or drop inbound messages. They do not give staff IMAP, sent-mail history, or a durable inbox. ArawaMail needs a real mailbox after receiving is active. For product-level comparison, see ArawaMail vs Cloudflare Email Service.
Does the domain have to live on Cloudflare?
Yes, for ArawaMail. The product publishes inbound MX and outbound authentication through a Cloudflare zone you authorize. The connected Cloudflare account must own an active zone whose name matches the domain shown in ArawaMail exactly. If ArawaMail lists example.com, the zone must be example.com, not a parent or a sibling.
OAuth asks for zone read and DNS write only. If the authorization flow expires or fails, return to the domain details page and start activation again. Do not leave a half-connected token sitting in another browser tab.
What to do if Email Routing is already on
Founders often forwarded hello@ through Email Routing to a personal Gmail and now want a company mailbox. Routing and ArawaMail cannot both own apex MX.
Cloudflare’s disable options still work as two paths:
- Unlock and keep DNS records — the migration path. Unlock so ArawaMail can publish its MX before Routing stops. Use this when inbound mail must keep flowing during the cutover window.
- Delete and Disable — removes Routing MX immediately. Use this only when you can tolerate a brief inbound gap, or when the domain has never received important mail.
Per-record Unlock applies to Email Routing records on the root (MX, SPF, DKIM). Email Sending records on a cf-bounce subdomain stay managed by Cloudflare for the life of that Cloudflare Email Sending configuration. Do not edit or delete cf-bounce records while Cloudflare Email Sending is still enabled.
If ArawaMail cannot publish MX, go back to Email Routing / Email Service settings, unlock or fully disable Routing, then retry Activate receiving.
Happy path: connect the domain in order
Documented order from ArawaMail domain onboarding: add the domain → confirm an active, exact-name Cloudflare zone → Activate receiving → Activate sending → create accounts → optional API keys.
- Add the domain in ArawaMail → Domains. The list shows three statuses: Domain (overall readiness), Receiving, and Sending.
- Open domain details and confirm the Cloudflare zone is Active and the name matches exactly.
- Activate receiving. Authorize Cloudflare if prompted. ArawaMail finds the matching zone and publishes the MX records required for inbound delivery. If the zone already has MX, confirm the replacement warning only when you are ready for inbound to leave Workspace, cPanel, or Email Routing. Confirming too early cuts the previous provider mid-day.
- Confirm Receiving = Active on the domain details page before creating anyone’s mailbox. Accounts cannot be created until receiving is active. Usernames may contain letters, numbers, dots, underscores, and hyphens.
- Activate sending. Sending requires receiving first. ArawaMail creates or retrieves the outbound identity, adds DKIM CNAME records, configures a custom MAIL FROM domain, and adds MAIL FROM MX plus SPF in Cloudflare. Mailbox SMTP and HTTP API sending fail while sending is inactive.
- Create the first mailbox (for example
founders@orhello@), then send a test message to an external inbox and reply back. Catch-all is a later domain-details choice: one active mailbox, not part of first activation. See Should you use a catch-all inbox?. - Connect a client last. IMAP on port 993 and SMTP on port 465 over TLS. Copy the hostnames shown in your account, not invented production hosts.
API keys are optional and come after the domain can receive and send. Agents that only hold a send key still need a mailbox if humans have to read replies. That is a separate operating decision, not a DNS step.
Why you can “send” in the UI but not receive
Receiving and sending are separate statuses. Sending publishes DKIM CNAMEs and MAIL FROM records so outbound mail authenticates. Receiving publishes MX so other servers deliver to you. If MX still points at Routing, Google Workspace, or an old cPanel host, inbound never arrives in ArawaMail even when outbound looks fine.
The other direction also happens: receiving is active, sending is not. Then mailboxes exist but SMTP and the HTTP API refuse to send. Activate both, then test both directions.
If you are cutting over from Workspace rather than from Routing, use the cutover window in How to move business email off Google Workspace. Confirm ArawaMail’s MX replacement warning only inside that window.
Should MX or mail hostnames be proxied?
No. Leave mail-related records DNS-only. Proxying HTTP for the website is unrelated and can stay orange-clouded. Mixing the two is how teams create _dc-mx decoy names and then wonder why MX lookups look “wrong.”
Copy the records ArawaMail writes into the zone. Exact MX, DKIM, and SPF values are shown in the product at activation time; do not paste hostnames from a blog post. After records exist, check them with the lookups on ArawaMail free email tools.
Three common starting points
- New SaaS domain already on Cloudflare DNS, Routing never enabled. Skip the unlock step. Activate receiving, confirm MX, activate sending, create the first mailbox, send a test.
- Founder forwarded hello@ through Routing to Gmail. Unlock Routing (prefer unlock-and-keep if mail must keep arriving), activate receiving, create a real
hello@mailbox, then turn Routing off. Do not keep Routing MX “as a backup.” - Workspace or cPanel MX still on the zone. Plan a cutover window. Activate receiving only when you are ready for inbound to leave the previous provider. Custom-domain mail versus a consumer inbox is covered in Custom-domain business email vs Gmail.
Reset, catch-all, and what not to clean by hand
Use Reset only when you intend to disconnect the domain and start over. Reset stops receiving and sending until you activate again. Remote Cloudflare cleanup is best-effort; if the Cloudflare token has expired, review the zone manually.
Do not delete Cloudflare cf-bounce records while Cloudflare Email Sending is still enabled on that account. Do not treat a Worker route as the company inbox. Do not create API keys before the domain can receive—there will be nowhere for replies to land.
Methodology note
This procedure follows ArawaMail’s documented order (domain onboarding, Cloudflare requirements, activate receiving, enable sending, email accounts) plus Cloudflare’s current Email Routing lock/unlock behavior as of draft day, 1 September 2026. We do not invent production MX or IMAP hostnames; those are issued in-product. For how SPF, DKIM, and DMARC fit together after sending is active, read SPF, DKIM, and DMARC explained. Client protocol choice is in IMAP vs POP3 for business email. Hub pages: business email and pricing.
FAQ
Does the domain have to live on Cloudflare?
Yes. ArawaMail publishes mail DNS through an active Cloudflare zone that matches the domain name exactly and is owned by the connected Cloudflare account.
What if Cloudflare Email Routing is already enabled?
Unlock or disable it before Activate receiving. ArawaMail cannot share Routing’s locked MX. Prefer Unlock and keep DNS records when inbound mail must keep flowing.
Why can we send but not receive after connecting?
Sending and receiving are separate activations. Outbound can work while MX still points at Routing or Workspace. Confirm Receiving = Active and that MX is the set ArawaMail published.
Should MX or mail hostnames be proxied (orange cloud)?
No. Keep mail-related hostnames DNS-only. Unexpected _dc-mx names usually mean a proxied mail target.
When do we create mailboxes versus API keys?
Mailboxes after receiving is active. Sending after receiving. API keys after the domain can send. Humans who must read replies need a mailbox, not only a key.
Is a Cloudflare Email Worker a substitute for an inbox?
No. A Worker can process or drop mail. It is not a hosted staff mailbox with IMAP and sent history.