An MX host does not resolve to an address
One of the hostnames in the MX records does not resolve to an address. A sending server that selects that host has nowhere to connect, so delivery fails or falls to another host, and if the unresolvable host has the lowest priority number, every sender tries it first and every delivery is delayed.
Check your own domainMX lookup
What causes this
A sending server looks up your MX records, then resolves each hostname to an IP address to connect to. If the hostname does not resolve, that mail exchanger cannot be reached at all. Where it is the only or highest-priority exchanger, delivery to your domain fails.
What it breaks
Mail delivery to your domain fails or is delayed while senders retry an unreachable host.
What the receiving server does
A sender collects the MX records, sorts them by priority and works through them in order, resolving each hostname to an address before connecting. A host that does not resolve produces a delay while the lookup fails, then a move to the next host. With a second working host mail still arrives, later than it should. With no working alternative, messages sit in the sender's queue and bounce after its retry period expires (typically several days), by which time the sender has usually given up on the message rather than reporting it promptly.
Priority decides how much this costs
The lowest priority number is tried first. Where the broken host is the primary, every message pays the delay; where it is a backup, most messages never touch it and the fault stays hidden until the primary has an outage.
How to fix it
Correct the hostname or remove the record.
- Check the MX hostname for typos against your provider's documentation.
- Confirm the hostname resolves. If the host has been decommissioned, remove the MX record.
If you send with
- Records left behind after a migration
- The usual cause is a mail platform migration where the new provider's MX records were added and the old ones were never removed. The old hostname eventually stops resolving, and because it is normally a backup priority, nothing appears wrong until the day it is needed.
- Typos in the hostname
- A missing trailing dot or a transposed character produces a name that does not exist. Some DNS panels append the zone to any name without a trailing dot, turning mx01.example.net into mx01.example.net.example.com, which resolves to nothing.
Confirming the fix worked
- Resolve every MX target in turn and confirm each returns A or AAAA records.
- Remove hosts that belong to a previous provider rather than leaving them as backups: a backup that does not work is worse than none.
- Check for a missing trailing dot, which is the most common cause of a hostname that silently became relative to your own zone.
- Confirm the lowest priority host is the one you intend to receive mail, since that is where nearly all delivery attempts go.
Common questions
- Mail is being delivered. Why does this matter?
- Because it is being delivered by the fallback. Every message pays a failed lookup and a connection attempt first, adding delay, and you have no working redundancy left. The next time the primary has trouble there is nothing behind it.
- What does the priority number mean?
- Lower is tried first. It is a preference order, not a weight, and the values themselves are arbitrary: 10 and 20 are conventional but 1 and 2 behave identically.
- How long before mail actually bounces?
- Most senders retry for several days before giving up, so a total inbound failure produces silence rather than immediate bounces. That is why unresolvable MX hosts are usually noticed by someone asking why a reply never arrived.
- Should I keep an old provider's MX as a backup?
- No. A backup MX that no longer accepts mail for you is a liability: senders will try it, and mail delivered there goes nowhere. Remove records for platforms you have left.