An MX (Mail Exchanger) record is a DNS resource record that names the host or hosts allowed to accept inbound mail for a domain. It does not send mail, store mailboxes, or prove SPF, DKIM, or DMARC. After a provider change, an MX lookup is how you confirm the advertised destination actually moved — not how you prove the message will land in the inbox.
The typical failure is operational, not theoretical. You flipped a panel from Google Workspace, Microsoft 365, or cPanel to a new host, sent a test from your phone, and it still arrived at the old inbox. An MX lookup still showed the previous exchanger because TTL had not expired, leftover MX rows were still published, or the mail hostname was orange-cloud proxied.
What an MX record actually controls
When someone sends mail to [email protected], the sending server asks DNS: “Which host should accept this?” The answer is the MX set. Everything else — mailbox storage, IMAP, SMTP submission, DKIM signing — lives on other records and other services.
- MX answers: where inbound SMTP should connect for this domain.
- MX does not answer: whether the mailbox exists, whether the message will be spam-foldered, or whether your outbound API is authenticated.
- Related, different jobs: SPF/DKIM/DMARC authorize senders. SPF, DKIM, and DMARC explained covers that stack. MTA-STS and TLS-RPT constrain how inbound TLS is advertised. Neither substitutes for MX.
ArawaMail publishes inbound MX when you Activate receiving on a matching Cloudflare zone, and warns before it replaces existing MX. Receiving cannot share MX with Cloudflare Email Routing, Google Workspace, Microsoft 365, or cPanel local delivery. Exact host strings belong on Domain details in the app and in the published ArawaMail DNS Records reference — not invented in this article.
MX priority: 10 vs 20 is preference, not a second inbox
Each MX row has a preference number (often labeled “priority”). Lower numbers are tried first. Equal numbers can share load. A higher number is a backup path, not a carbon copy of the mailbox.
| Preference | What senders do | What operators often assume (wrong) |
|---|---|---|
| 10 | Try this host first | “Primary inbox” — only if that host is configured to accept the domain |
| 10 (second host) | May share load with the other 10 | “Two copies of every message” — not how MX works |
| 20 | Tried if lower-preference hosts fail | “Automatic archive / failover mailbox” — only if that host also accepts and stores mail for the domain |
If the backup host is not provisioned for the domain, a failover just delays the bounce. Priority is a retry order, not a replication protocol.
How to look up MX (and what the result means)
An MX check answers one question: which hosts are advertised right now from the resolver you used? Run the same domain through ArawaMail’s free email tools MX lookup, then compare with what Domain details shows after Activate receiving.
- Look up the apex (and any mail subdomain you actually use).
- Note every target hostname and preference number.
- Confirm mail hostnames are DNS-only (grey-cloud), not proxied. Proxied names often resolve to unexpected
_dc-mx-style targets. - If two tools disagree, wait for TTL and query more than one public resolver. Cached answers are normal for minutes to hours.
A clean MX lookup is necessary for a cutover. It is not sufficient for inbox placement. Placement still depends on reputation, content, and authentication — see why emails go to spam.
Why mail still arrives at the old host after you “changed MX”
Operators usually did change a record. They did not change the set the internet is still using.
- Leftover rows. Old Google, Microsoft, or cPanel MX still published next to the new ones. Senders may keep hitting the lowest remaining preference on the old host.
- TTL and cache. A 1-hour or 4-hour TTL means some networks still have the previous answer.
- Wrong zone. Website nameservers moved the same afternoon as MX. You edited a panel that is no longer authoritative. Pair MX work with the custom-domain email migration checklist.
- Routing lock. Cloudflare Email Routing MX cannot sit beside ArawaMail receiving MX. Disable Routing and replace MX in one planned window. Details live in How to Connect a Cloudflare Domain to ArawaMail.
- Orange-cloud proxy on the mail hostname. Keep mail names DNS-only.
How we analyzed this
This explainer is constrained by Arawa Mail public docs (Introduction, domain onboarding, Cloudflare requirements, Activate receiving / sending) and the live DNS reference on arawamail.com. Public docs describe record kinds and the receiving replace warning. They do not publish guessed live MX host strings. MTA-STS and TLS-RPT remain operator-owned unless a product screen says otherwise.
What to do next
- Look up your domain on the MX tool.
- If you are moving inbound mail to ArawaMail, Activate receiving on the matching Cloudflare zone and accept the MX replace prompt — do not keep Workspace, Microsoft 365, cPanel, or Email Routing MX in parallel.
- Create mailboxes after receiving is on. Sending (DKIM + custom MAIL FROM) is a separate activation and requires receiving first.
- Clients still need IMAP or SMTP settings from Connect Device in-app. MX is inbound routing only; see IMAP vs POP3 for how users fetch mail after it arrives.
MX is the sign on the door. The mailbox, the sending API, and authentication are separate rooms. Confirm the sign first, then finish the rest of the domain.
FAQ
What does an MX record control?
Only the advertised inbound mail hosts for the domain. Not sending, not storage, not spam placement.
What does MX priority 10 vs 20 mean?
Lower numbers are tried first. 20 is a backup path if 10 is unreachable. It is not a second mailbox unless that host is also configured to accept and store mail.
Why do two MX lookups disagree after a change?
TTL and resolver cache. Wait out the previous TTL and query more than one resolver before assuming the cutover failed.
Can Cloudflare Email Routing MX share the zone with ArawaMail receiving?
No. Receiving cannot share MX with Email Routing, Google Workspace, Microsoft 365, or cPanel local delivery.
Does a successful MX lookup mean mail will land in the inbox?
No. It only means senders are pointed at the advertised host. Inbox placement is a different problem.