When an MX record isn't working, the cause is almost always one of five things: a CNAME target instead of an A/AAAA hostname, a typo or missing trailing dot in the target, wrong or duplicate priority values, leftover records from an old mail provider, or DNS that simply hasn't propagated yet. Mail delivery failures rarely mean DNS is "broken" — they mean one specific record doesn't match what the sending mail server expects. This guide walks through each cause and how to confirm it.
What an MX record actually does
An MX (Mail Exchange) record tells sending mail servers which host accepts email for your domain. Each MX record has two parts, defined in RFC 1035: a preference (often called priority) and an exchange (the mail server's hostname). Lower preference numbers are tried first — an MX with preference 10 is used before one with preference 20.
A critical rule from RFC 5321 (the SMTP standard) and RFC 2181: the MX target must resolve to an A or AAAA record, never a CNAME, and never a bare IP address. If you point MX at an alias, some receiving and sending servers will reject it outright or behave unpredictably. This single misconfiguration is behind a large share of "mail not working" tickets.
Step 1: query the live record, not your control panel
Your registrar's dashboard can lag behind what's actually published on the internet. Query DNS directly:
dig MX yourdomain.com
or
nslookup -type=MX yourdomain.com
Both bypass your local cache and hit a resolver directly, so you see what mail servers around the world actually see. You can also run a quick check without a terminal using our free MX lookup tool — it's the fastest way to confirm what's currently published before you start changing anything.
TipAlways check MX from an external tool or a different network. A record can look correct from your office Wi-Fi (which cached the old answer) while the rest of the internet already sees the new one, or vice versa.
Common cause 1: MX points to a CNAME
If dig MX returns a target that itself has a CNAME record — for example mail.yourdomain.com which is a CNAME to ghs.example.net — that's invalid per RFC 1035/5321. Fix it by pointing the MX record straight at a hostname that has its own A/AAAA record, or by using the mail provider's canonical hostname (which they've already set up correctly on their end).
Common cause 2: trailing dot or hostname typos
In a raw zone file, a fully qualified domain name must end in a trailing dot (mail.yourdomain.com.). Miss it, and some DNS software silently appends your domain to the end, producing something broken like mail.yourdomain.com.yourdomain.com.. Most modern registrar dashboards add the trailing dot automatically, but if you're editing zone files directly (or using our DNS management with manual record entry) it's worth double-checking the exact value your provider requires.
Also confirm:
- The Host/Name field is set to
@(or left blank) for root-domain mail, notmailor the full domain name repeated. - The target hostname has no stray spaces, and matches exactly what your mail provider issued.
Common cause 3: wrong or duplicate priorities
Priority (preference) numbers control failover order, not which record is "primary" by name. A setup like this is valid and expected:
| Priority | Mail server |
|---|---|
| 10 | mx1.provider.com |
| 20 | mx2.provider.com |
Sending servers try priority 10 first and fall back to 20 only if it's unreachable. Problems show up when:
- Two records share the same priority when they shouldn't — mail load-balances randomly between them instead of failing over in order.
- A decommissioned server keeps a lower (higher-priority) number than the active one, so senders keep trying the dead host first.
Google Workspace now recommends a single MX record — smtp.google.com at priority 1 — replacing the older multi-record ASPMX.L.GOOGLE.COM setup. Microsoft 365 auto-generates one record, typically yourdomain-com.mail.protection.outlook.com at priority 0, when you verify the domain. If your records don't match your provider's current documented setup, that mismatch is your problem.
Common cause 4: leftover records from a previous provider
A very common migration mistake: you move from your old host to Google Workspace or Microsoft 365, add the new MX records, but never delete the old ones. Now you have two providers' MX records live at once, and mail gets split or bounced depending on which priority wins. Always list every MX record for the domain and delete anything that doesn't belong to your current provider.
Common cause 5: propagation delay
If the record is correct but mail still misbehaves, check the TTL (time to live) on the record. Some resolvers cache answers for up to their TTL even after you've published a fix, and certain caching layers hold on longer regardless of a lower TTL you've set. Wait out the TTL window before assuming the fix didn't take, and re-check with an external lookup tool rather than your own browser or mail client, which may be using a stale local cache.
No MX record at all — is that valid?
Yes, in one specific case. RFC 7505 defines the Null MX: a single record with preference 0 and target . (a lone dot), which explicitly tells senders "this domain accepts no mail, don't retry." This is intentional for domains used only for websites, not email — it's not a misconfiguration if you set it deliberately.
If there's genuinely no MX record and no Null MX, RFC 5321 says senders should fall back to the domain's A/AAAA record as an implicit mail host — but relying on this fallback is fragile and increasingly unsupported by newer mail systems. Don't depend on it; add an explicit MX or a Null MX instead.
MX looks fine but mail still doesn't deliver
If dig MX returns exactly what you expect and priorities are sane, the fault is usually downstream of routing, not the MX record itself:
- Missing or incorrect SPF record, causing receiving servers to reject or spam-flag mail — see our guide on creating a secure SPF record.
- Missing DKIM signing.
- A firewall on the mail server blocking port 25 or 587.
These are deliverability issues, not MX issues, but they present identically to end users ("email isn't working") — worth ruling out once the MX record itself checks out. For the full picture of how MX fits alongside A, TXT, CAA and other record types, see our DNS record types guide.
Quick diagnostic checklist
- Run
dig MX yourdomain.comor use the MX lookup tool — confirm what's actually published. - Confirm the target hostname is not a CNAME and resolves to an A/AAAA record.
- Check for trailing-dot formatting issues if editing raw zone files.
- Verify priority values match your provider's current documented setup, with no orphaned duplicates.
- Remove old MX records from any previous mail provider.
- Wait out the TTL window before re-testing after a change.
If you manage DNS for multiple domains across different registrars, keeping MX, SPF and other mail records consistent gets harder as the list grows — our DNS management gives you one place to check and edit records across every provider instead of chasing them separately.
Frequently asked questions
#Can an MX record point to an IP address instead of a hostname?
No. MX records must point to a hostname that itself has an A or AAAA record; pointing directly to an IP address is invalid per RFC 1035 and will be rejected or ignored by compliant mail servers.
#Why does my MX record work in one location but not another?
DNS answers are cached by resolvers around the world, so a recently changed record can appear correct from one network while another resolver still serves the old cached answer until its TTL expires.
#Is it OK to have no MX record at all?
Only if you set it deliberately using a Null MX record (RFC 7505) — a single MX with preference 0 and target "." — which tells senders the domain accepts no mail; simply omitting MX by accident can cause unpredictable fallback behaviour.
#What's the difference between MX priority and preference?
They're the same value under different names — RFC 1035 calls it preference, most control panels label it priority, and in both cases a lower number means the mail server is tried first.
Was dit artikel nuttig?
