Mail follows the lowest-preference MX record that senders can actually use. A domain can look moved in a new dashboard while public DNS still advertises the old host, a backup MX, or a filter in front of the mailbox. Query the domain’s authoritative name servers (not only a public resolver) and check preference numbers before declaring the cutover complete.
Mail follows the lowest-preference MX that works
Per RFC 5321, lower MX preference numbers are tried first. Multiple equal preferences can be load-shared. A higher-number backup MX is not proof the primary is unused. If the published set still points at the previous provider, new senders will continue delivering there even after you activated receiving elsewhere.
Check authoritative DNS and TTL, not just a public resolver
A public resolver can still show the old MX until the previous TTL expires. Always query the domain’s authoritative name servers as well. Lower TTL before a planned cutover so cached records expire faster.
Null MX is a different failure
A Null MX (RFC 7505: preference 0, exchange “.”) means the domain does not accept mail at all. That is distinct from pointing at the wrong host. Do not confuse the two when diagnosing.
What Arawa Mail receiving activation does
Arawa Mail receiving activation publishes the MX records required for inbound delivery and routes mail to Arawa Mail. If MX records already exist, the product shows a confirmation step before replacing them. Confirm only when inbound mail should move. Docs do not publish the exact MX hostname in the guide; we do not invent one. Resetting a domain registered with Arawa Mail removes the receiving MX record that activation created (Cloudflare cleanup is best-effort). A leftover MX after reset is a documented cleanup case, not a successful cutover.
See the migration checklist for the full cutover and rollback picture: Custom-Domain Email Migration Checklist. Cloudflare domain connection is covered in How to Connect a Cloudflare Domain to ArawaMail.
Other common wrong-destination cases
- Cloudflare Email Routing or Email Workers owning the MX while the team expects a mailbox.
- A backup MX still preferred by some senders.
- Filter or security service in front of the real mailbox host.
Do not infer that a message was delivered because a provider accepted it. Wrong MX means the next sender may still deliver to the old host.
How we analyzed this
We verified against RFC 5321 preference mechanics, RFC 7505 Null MX, Arawa Mail receiving activation docs (confirmation before replacing existing MX, no published hostname), and standard DNS TTL / authoritative-query practice. No production MX hostnames were invented.
FAQ
How do I know the MX still points at the old provider?
Query the authoritative name servers and compare the exchange hostname and preference to what the new provider expects.
Why does a public dig still show the old record?
TTL caching. Public resolvers hold the previous value until the TTL expires.
What is a Null MX?
Preference 0, exchange “.” — the domain accepts no mail (RFC 7505).
Does Arawa Mail replace existing MX automatically?
No. It shows a confirmation step first. Confirm only when you are ready for inbound mail to move.
Related: SPF, DKIM, and DMARC explained, Why your emails go to spam.