How to troubleshoot MX record problems
A practical MX troubleshooting guide covering missing MX records, wrong targets, bad priorities, and how to verify mail routing during migrations.
Start by confirming whether MX records exist
The first and most basic check is whether the domain publishes MX records at all. A domain that receives email normally needs valid MX records, although some mail systems may fall back to the domain's A record in limited situations.
If no MX records exist where you expect them, mail routing may fail completely or behave unpredictably depending on the sending system.
This is the first thing to verify before looking at priorities, providers, or authentication.
Check the actual MX values
An MX record contains two key parts: a preference number and a target hostname.
0 mail.protection.outlook.comThe preference value controls delivery order. Lower numbers are preferred first. The target hostname identifies the platform that should receive mail for the domain.
An MX record can be syntactically valid and still be operationally wrong if either of these values is incorrect.
Confirm the targets belong to the intended mail provider
One of the most common real-world problems is that a domain publishes MX targets for the wrong provider. This often happens after migrations, partial cutovers, or when administrators add new records without removing old ones.
For example, a domain intended to use Microsoft 365 may still publish legacy Google Workspace, Mimecast, or hosted Exchange MX records.
A syntactically valid MX record can still be wrong if it points to the wrong platform.
Check priorities carefully
MX priorities determine which host is preferred. Lower values are tried first by sending systems.
If priorities are wrong, mail may still be delivered to an old environment, a backup platform, or a lower-priority system that was never intended to handle primary traffic.
This is a frequent migration issue when old and new MX records coexist but the new provider has not been given the preferred priority.
- 0 is preferred over 10
- 10 is preferred over 20
- Equal priorities may be used for shared load
- Unexpected priorities can silently misroute mail
Resolve the target hostnames
The MX value is a hostname, not an IP address. That hostname must resolve correctly through A or AAAA records.
If the MX target does not resolve, mail routing can fail even though the MX record itself exists.
This is an important distinction: the MX record may look fine in DNS, but if the target hostname is broken, mail still cannot be delivered.
Check propagation during migrations
During a migration, MX records may appear correct from one resolver and outdated from another because of caching and propagation delays.
This can make mail routing appear inconsistent, especially just after cutover.
You should compare multiple resolvers and, where possible, confirm what the authoritative nameservers are returning.
Common migration mistakes
- Old provider MX records left in place
- New provider records added without removing the old ones
- Wrong priorities after migration
- Target hostnames that do not belong to the intended platform
- Cutover assumed complete before propagation finished
- Authentication records not updated alongside MX changes
MX records and authentication problems
A practical MX troubleshooting workflow
- Check whether MX records exist
- Confirm the number and priority of published MX records
- Resolve the MX target hostnames to make sure they work
- Confirm the targets match the expected mail provider
- Compare results across multiple resolvers if a migration is in progress
- Check whether old provider records are still present
- Review SPF, DKIM, and DMARC if mail issues continue