MX records explained: priority, lookups and what breaks

What an MX record is, and what it is not

Every email address has a domain after the @, and every delivery begins by asking that domain one question: who takes mail for you? The answer is an MX record — MX for Mail eXchanger — and it is two things joined together, a number and a hostname.

That is the entire record. It names a machine, and it names it in a way that lets a domain list several of them in an order. It sits in DNS beside the A record that points at the website, and the two have nothing to do with each other: a domain can serve its site from one company and take its mail at another, which is what most domains actually do.

Not an address

The record belongs to example.com, not to you@example.com. DNS has never heard of the part before the @. One MX record serves every address on the domain — the ones that exist and the ones nobody has thought of.

Not an IP address

The value is a hostname, which the sender then resolves to an address of its own in a second lookup. An IP address written where the hostname goes is a well-formed record that no sender can use.

Nothing to do with sending

Nothing consults your MX record when you send a message. What proves an outgoing message really came from your domain is SPF, DKIM and DMARC — different records, in a different place, doing a different job.

Not a promise that the mailbox exists

An MX record says where to knock. Whether anybody answers to a particular name is decided by the server at the other end, during the conversation, long after DNS has finished.

This is why an MX record can be perfect while mail still fails, and why it can be missing while mail still arrives. It is one step of seven, and it is the only one that happens before anything connects to anything.

Reading one: two fields and a full stop

One command, on any machine that has dig installed:

$ dig +short MX example.com

A domain that takes mail answers with one line per record:

10 mx1.example.com.
20 mx2.example.com.

Four things are now in front of you, and only two of them are the record.

10

The preference. A whole number between 0 and 65535, where lower means tried first. It is compared with the other numbers in this same answer and with nothing else in the world.

mx1.example.com

The host that accepts the mail. A name, not a machine: the sender has to resolve it to an address in a second lookup before it can connect to anything at all.

The trailing dot

It marks the name as complete, from here up to the root of DNS. Your provider may add it for you, may print it, or may hide it — all three spellings mean the same name.

What +short is hiding

The TTL, the class and the type. They matter exactly once, on the day you change the record, and the last section of this guide prints them.

Three ways to ask the same question, depending on what is installed where you are:

What the number actually decides

The number is called a preference, and the name is exact. It is not a rank of quality, not a share of the traffic and not a version. A sender takes the hosts it was given, sorts them by that number smallest first, and starts at the top.

Only the ORDER carries meaning. 10 and 20 do precisely what 1 and 2 would do, and precisely what 5 and 4000 would do. Ten, twenty, thirty is a habit that leaves room to slide something in later, and that is its whole justification.

Two hosts sharing one number is not a mistake either. When preferences tie, the sender is expected to pick between them at random, and that is how a domain spreads incoming mail across several machines. It is the only load sharing DNS offers here, and for mail it is enough.

None of this is the failover story people expect. The next host down is reached when the one above refuses the CONNECTION: it is switched off, the port is closed, the name resolves to nothing. A host that answers and then rejects the recipient has finished the job — the sender has a verdict, and a verdict is not a reason to go and ask somebody else.

The seven steps a sending server takes

From the moment somebody presses send, the MX record is consulted once, quite early, and then never again for that message.

1. It splits the address. Everything after the last @ is the domain. Everything before it is carried along untouched and means nothing until step five.
2. It asks DNS for that domain's MX records. One question, answered out of a cache more often than not.
3. It sorts the answer by preference, smallest number first, shuffling at random any hosts that tie.
4. It resolves the first hostname to an A or AAAA record. This is a second lookup, and a hostname with no address record of its own is a host that cannot be tried.
5. It connects on port 25 and holds an SMTP conversation: who is sending, who it is for, and then the message itself.
6. It reads the reply code. A 2xx means accepted and the work is over. A 5xx means refused for good, and the message comes back as a bounce.
7. It retries anything temporary. A 4xx, a refused connection or a timeout puts the message back in the queue, where it is tried again for several days — five is the usual figure — before anybody is told it failed.

Two useful things fall out of that list. A message is never delivered by DNS, only routed by it, so a correct MX record on its own proves nothing about whether mail arrives. And a wrong MX record usually produces silence for hours rather than an error in seconds, because step seven is patient by design.

Nothing in that sequence looks at the part before the @ until step five, which is why an MX record can never tell you whether an address exists. That question is answered by a server, in a conversation — and on a domain pointed here the answer is yes to every name on it, which is what a catch-all is.

When there is no MX record at all

A domain with no MX record is not a domain that refuses mail. The standard says a sender must then fall back to the domain's own address record and deliver there, exactly as though a record with preference 0 had been published pointing at the domain itself. It is called the implicit MX, and it is why a small company whose entire DNS is one web server goes on receiving mail nobody ever configured.

It is also why deleting an MX record does not stop mail. The attempts simply move to whatever the A record points at, which usually refuses the connection, and the messages then sit in the sender's queue for days before anyone is told anything at all.

The record that genuinely says this domain accepts no mail is the null MX: one record, preference 0, and a value that is a single dot and nothing else.

The whole value of a null MX0 .Copy

A sender that meets one stops immediately with a permanent failure instead of retrying for five days, and whoever wrote to you learns at once that they cannot. It belongs on a domain you own and never read — a brand you have parked, a name you bought so that somebody else could not.

Six ways an MX record goes wrong

Almost every broken MX is one of these six, and four of them look entirely correct in the DNS provider's own interface.

The value points at an alias

An MX must name a host that has an address record, never a CNAME. The standards forbid it outright, and the punishment is worse than an error message: many senders follow the alias anyway and some refuse to, so the domain loses a share of its mail and keeps the rest.

The value is an IP address

There is nowhere in the record for one. A sender reads the value as a hostname, fails to resolve it, and moves on to whatever comes next — or gives up entirely when there is nothing next.

The trailing dot is missing in a zone file

In a raw zone file a name without a final dot is relative, so smtp.grabmail.io quietly becomes smtp.grabmail.io.example.com. Web interfaces normally add the dot for you; the ones that hand you a plain text box do not.

There is a second record nobody remembers

A record left behind by a previous provider does not conflict with the new one. It takes its share of the mail, in silence, and the symptom is the worst one there is: some messages arrive and some do not.

It was published on the wrong name

An MX on mail.example.com routes mail addressed to @mail.example.com, which is not what anybody typed. The record belongs on exactly the name that appears after the @.

The zone being edited is not the zone being read

If the domain's nameservers were delegated elsewhere, the DNS page at the registrar still works and still saves, and nothing on the internet ever reads it. This is the one failure where everything you can see is correct.

That last one deserves a command rather than a paragraph, because it is invisible from inside the interface that is misleading you:

$ dig +short NS example.com

Those are the machines that answer for the domain. If they are not the ones whose control panel you have been editing, nothing you typed has ever been published anywhere.

The one record that points a domain at GrabMail

One record on the domain, and every address on it becomes readable here — the ones you have thought of and the ones you have not, which is what makes an endless supply of test addresses a DNS record rather than a feature. Nothing else in the zone is touched: the website, the TXT records and the subdomains stay exactly where they are.

The preference and the host, as one line10 smtp.grabmail.ioCopy

1. Publish the record. Type MX, name @ — or the bare domain, or an empty box, since providers disagree about the spelling and all three mean the same thing — preference 10, value smtp.grabmail.io.
2. Delete every other MX record. Not so that ours wins, but because two providers means part of your mail goes elsewhere and nothing will tell you which part.
3. Wait out the OLD record's TTL, not the new one's. If the previous answer said an hour, an hour is what you wait.
4. Check it, then send yourself anything at all. The first message that arrives is the confirmation, and it is kept rather than discarded.

The check is the same command as everywhere else in this guide, pointed at your own domain:

$ dig +short MX yourdomain.com

You want exactly one line back, reading 10 smtp.grabmail.io. — one preference, one host, nothing underneath it. If a second line appears, that is the record quietly eating your mail. There is no account to open and no token to paste, because the record is itself the proof: nobody who did not control the domain could have published it.

When it still looks wrong an hour later

DNS pushes nothing anywhere. Your change is live at your own provider the instant you save it, and it reaches everybody else only as their caches expire — and the number that decides how long that takes is the TTL of the record that was there BEFORE, which you can no longer read anywhere. The long form of the lookup at least prints the one you have now:

$ dig +noall +answer MX example.com

example.com.        3600    IN    MX    10 mx1.example.com.
example.com.        3600    IN    MX    20 mx2.example.com.

3600 is the TTL, in seconds: how long anything that already holds this answer is entitled to go on using it. To see the truth with no cache in the way, ask a machine that is authoritative for the domain instead of asking a resolver:

$ dig +short MX example.com @ns1.example.net

The nameserver to put after the @ is one of the names dig +short NS example.com gave you. If the authoritative answer is right and your own is wrong, there is nothing left to fix — only a cache to outlive.

1. Ask an authoritative nameserver. If the record is correct there, it is published, and everything after this is waiting.
2. Count from the old TTL. An hour is common and a day is not rare. The new TTL changes nothing until the old answer has expired everywhere.
3. Check the nameservers. The zone you edited and the zone the world reads have to be the same zone.
4. Look for a second MX. One correct record plus one forgotten record is the hardest failure on this page to see.
5. Resolve the target. The host named in the record needs an A or AAAA record of its own, or there is nothing to connect to.
6. Then stop looking at DNS. Once the record is right, what is left is a conversation between two servers, and the bounce is where that conversation is written down.

Nothing you can do makes a cached answer expire early, and no service anywhere « flushes DNS worldwide ». Lowering a TTL helps only if it is lowered before the change, never after — which is the one piece of DNS advice that has to be taken a day early to be worth anything at all.

The short version

1. An MX record is a preference number and a hostname, published on the domain that follows the @.
2. Lower is tried first. The number means nothing on its own, and equal numbers share the load at random.
3. The next host down is for a host that does not ANSWER. A refusal is a verdict, and a verdict ends the delivery.
4. The target is a hostname that has an address record — never a CNAME, never an IP address.
5. No MX means senders fall back to the A record. Only a null MX, 0 ., means no mail at all.
6. One MX provider per domain, or you lose a share of your mail to the other one and never learn which share.
7. After a change, ask an authoritative nameserver and then wait out the old TTL. There is genuinely nothing else to do.

If the record is right and mail still does not arrive, the problem has moved somewhere DNS cannot see it. A message that never turned up and a message that came back are two different investigations, and both of them begin where this one ends.

Questions