Skip to content
DomainVigil
Sign up

Reference guide

What is an MX record?

An MX record names the machines that receive a domain's mail, and the preference says which order to try them in. Two fields, and still one of the most commonly misconfigured records there is.

8 min readUpdated September 12, 2026

In short

An MX record says which server to deliver a domain's mail to. Each line carries a preference value and a hostname; the sending server tries the lowest value first, then works upward. With no MX record at all, mail falls back to the domain's own address.

What an MX record is for

When a server wants to deliver a message to an address, all it has to go on is the domain after the at sign. The MX record answers that question: here are the machines that accept mail for this domain. Without it, mail does not know where to land — or lands in the wrong place, which is worse.

The record carries two things, not one: the hostname, and a number saying in what order to try it. That number is a preference, not a score: the lower it is, the higher the priority. It catches everyone out the first time, and it stays the commonest source of error.

A domain can publish several MX records, and every hosted mail service does: they hand you two to five so delivery survives one of their machines going down. What that redundancy does not cover is a mistake in your own zone — there, every MX record is wrong at once.

An MX record, term by term

Two lines are enough to describe a domain receiving mail on two machines, one taking precedence over the other.

example.com. 3600 IN MX 10 mail1.example.net. example.com. 3600 IN MX 20 mail2.example.net.

  1. example.com.The domain of the addresses

    The name appearing after the at sign. A subdomain that receives mail publishes its own MX records: it inherits none from the domain.

  2. MXThe type

    Inbound mail only. It says nothing about what leaves the domain — that is the job of SPF, DKIM and DMARC.

  3. 10The preference

    A whole number from 0 to 65535. The lowest gets tried first. The values mean nothing on their own: only their order relative to each other counts.

  4. mail1.example.net.The machine name

    A name that resolves straight to an address. Not an alias, and not an IP address written where the name belongs: both are forbidden and behave unpredictably.

MX preferences and what they mean

No value is good in the abstract. What matters is the order they describe, and only one value carries a special meaning in the standard.

ValueWhat it meansTypical case
0The strongest possible priority. Paired with a target reduced to a single dot, it has a special meaning: the domain receives no mail at all.A single server, or an explicit statement that a domain has no mailboxes.
1 to 10The main server, the one meant to handle nearly all the traffic.The value most hosted mail services give their first machine.
20, 30, 40The servers tried next, in ascending order, when the earlier ones do not answer.The same provider's other machines, spread across other sites.
Two lines at the same valueNeither takes precedence: the sender picks between them at random.Two strictly equivalent servers, to spread the inbound load.
50 and aboveA distant backup, contacted only when everything else is unavailable.A third-party relay — only worth setting up if that relay actually knows the domain's mailboxes.
65535The highest value the format allows.No practical use: nothing separates 100 from 65535 once it is the last line.

Check your own domain, right now

Enter a domain name: the tool shows its MX records, their preferences and the machines they name.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

What a sending server does, in order

This sequence explains nearly every symptom you will meet: late messages, lost messages, messages landing at the previous host.

  1. 1

    It asks for the destination domain's MX records

    One query, which returns every line at once with its preference.

  2. 2

    It sorts them by ascending preference

    Lowest value first. On a tie, it picks between the tied machines at random, which spreads the load on its own.

  3. 3

    It tries the first machine

    If that machine accepts the message, it is done: the others are never contacted.

  4. 4

    On failure, it moves down the list

    A temporary refusal or an unreachable machine sends it to the next one. A permanent refusal stops everything: the message goes straight back to the sender.

  5. 5

    If nothing was delivered, it queues

    The message is held and retried at widening intervals for several days before being given up. That delay is what lets you repair a broken zone without losing mail.

With no MX record at all, the sending server falls back on the domain's own address. A domain with no MX but with a website therefore receives mail connections on its web server.

The five situations that decide a message's fate

Some setups declare the exact opposite of what whoever wrote them intended.

ConfigurationWhat it declaresReal consequence
No MX, an address on the domainNothing explicit: the standard falls back on the domain's address.The web server receives delivery attempts it cannot handle. Messages are lost or rejected late.
A single MX, target reduced to a dotThis domain receives no mail, deliberately.Senders give up immediately with a clear message, instead of retrying for days. The right setting for a defensive domain.
MX pointing at an aliasNothing valid: the standard requires a name that resolves straight to an address.Some servers follow it anyway, others refuse. Delivery becomes unpredictable from one sender to the next.
MX containing an IP addressNothing valid either: the field expects a machine name.Most senders fail. Those that tolerate the setup do so with no guarantee.
A third-party backupThat this machine should accept mail when the others are down.Useful only if that relay knows the list of valid mailboxes. Otherwise it accepts everything, then bounces refusals back at innocent senders.

The mistakes that lose mail

  • After the migration, messages still arrive at the old host

    What causes it: The new MX records are published but nobody deleted the old line — or the record's time to live was too long for the switch to be immediate.

    What fixes it: Delete the old lines, and lower the time to live more than one full duration before the migration. Keep the old mailbox reachable for a few days.

  • A domain with no mail service receives and bounces mail

    What causes it: It has no MX record but carries an address for its website: the standard therefore sends mail to the web server.

    What fixes it: Publish the standard null MX: one MX line, preference zero, target reduced to a single dot.

  • Delivery works from some senders only

    What causes it: The MX names an alias. Strict servers refuse that setup, tolerant ones accept it.

    What fixes it: Replace the target with the canonical name, the one that resolves straight to the machine's address.

  • The backup server sends out bounces in bulk

    What causes it: It accepts every message without knowing which addresses are valid, finds out too late that they do not exist, and bounces to a sender who is usually being impersonated.

    What fixes it: Remove the backup, or give it the list of valid mailboxes. A backup that cannot refuse at the door does more damage than plain downtime.

The questions that come next

Is a backup mail server needed?

Rarely. The protocol already has the sender hold the message and retry for several days: a few hours of downtime loses nothing. A badly configured backup, on the other hand, loses messages for good.

What happens if I publish two MX records with the same priority?

The sender picks between them at random, which spreads inbound traffic. It is a valid setup, provided both machines serve exactly the same mailboxes.

Does a subdomain inherit the domain's MX records?

No. Every name that receives mail publishes its own. A subdomain with no MX but with an address will receive mail at that address, which is almost always unintended.

How long is a message retried before it is lost?

It depends on the sending server, but the standard recommends persisting for several days before giving up. That delay is what gives you time to repair a zone mistake before it costs you mail.

A deleted MX record makes no noise

The site keeps answering, visitors see nothing, and mail simply stops arriving — usually discovered days later by a client who never got a reply. DomainVigil re-reads the MX records on every domain you own each day and emails you at the first change.

Start for free

Five domains free, forever. No card required.

The other reference guides