How an email finds your mail server
Sender
you@gmail.com
MX lookup
who takes mail?
Mail server
priority 10 first
Inbox
delivered
Lowest priority number wins; higher numbers are backups
What Is an MX Record? How MX Records Route Email
When someone sends a message to you@example.com, their mail server has to answer one question before anything else: which machine accepts mail for example.com? The MX record is the answer.
MX stands for Mail Exchange, and an MX record is the DNS record that names the server accepting a domain's email. Without one, mail to your domain bounces — even if the website works perfectly. Website records and mail records are completely independent.
How an email finds your mail server
Sender
you@gmail.com
MX lookup
who takes mail?
Mail server
priority 10 first
Inbox
delivered
Lowest priority number wins; higher numbers are backups
What an MX record looks like
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.The number before the hostname is the priority (sometimes called preference). Everything else is a standard record.
How priority actually works
A sending server sorts your MX records by priority and tries them in order. If the lowest-priority host refuses the connection or times out, it moves to the next. This is genuine redundancy: mail keeps flowing while one server is down.
Records sharing the same priority — the two 5 entries above — are load-balanced. The sender picks between them at random, spreading volume across both.
The rules MX targets must follow
- The target must be a hostname, not an IP address.
MX 10 93.184.216.34is invalid; useMX 10 mail.example.com.with anArecord on that name. - The target must not be a CNAME. The specification requires MX targets to resolve directly to address records. Some mail servers refuse delivery otherwise. See CNAME vs A.
- The target needs its own
AorAAAArecord. An MX pointing at a name that does not resolve is the same as having no MX at all.
Null MX: declaring that a domain sends no mail
If a domain will never receive email, say so explicitly with a single MX record pointing at the root zone:
example.com. 3600 IN MX 0 .A lone . as the target means this domain accepts no mail. Senders reject immediately with a permanent error instead of retrying for days, and it makes the domain a less attractive target for spoofing. Worth setting on every domain you own that is not used for email.
What happens when there is no MX record
The historic fallback is that senders try the domain's A record and attempt delivery there. Relying on this is a bad idea: behaviour varies between mail servers, and if your A record points at a web server or CDN with no mail daemon, messages bounce.
Key takeaway
If you want mail, publish an explicit MX. If you do not want mail, publish a null MX. Leaving it blank and hoping the A-record fallback works is how domains lose messages silently.
MX records are not the whole story
MX decides where mail is delivered. Three other records decide whether it is trusted — and without them your legitimate mail lands in spam folders:
- SPF — a
TXTrecord listing which servers may send as your domain. - DKIM — a
TXTrecord publishing the key that signs your outgoing mail. - DMARC — a
TXTrecord telling receivers what to do when SPF or DKIM fails.
All three are covered in SPF, DKIM, and DMARC explained. A fourth factor, reverse DNS, matters for servers that send mail directly.
The failures that lose mail, and how to spot them
MX misconfiguration rarely announces itself. Mail does not stop — it thins out, or it arrives late, or one sender complains while everyone else is fine. These are the patterns worth recognising.
Records pointing at a provider you no longer use
The single most common cause of mysteriously missing mail. A migration leaves the old provider’s MX records alongside the new ones, so senders distribute between them by priority and a fraction of messages land in a mailbox nobody reads. Symptom: mail from some senders arrives, from others it vanishes, with no bounce.
The MX target has no address record
An MX pointing at mail.example.com when that name does not resolve is functionally identical to having no MX at all. Senders either bounce immediately or queue and retry for days before giving up. Always verify the target resolves, not just that the MX record exists.
A firewall blocking port 25
Perfect DNS, unreachable server. Inbound SMTP arrives on port 25, and cloud providers commonly block it by default on new instances. The MX lookup succeeds, the connection never completes, and senders queue silently.
Checking your MX records
dig +short example.com MXThe lookup tool returns MX records already sorted by priority, with a null MX shown explicitly rather than as a confusing empty value — which makes it easy to confirm at a glance that your primary is the one you expect.
Need to check a domain's public DNS addresses? Use the Domain IP Lookup tool.
Free tools for this topic
Frequently asked questions
Related reading
The records you will meet in nearly every zone
SPF, DKIM and DMARC Explained: Email DNS TXT Records
Three TXT records stand between your email and the spam folder. What each one does, how to read the syntax, and the safe order to deploy them.
Reverse DNS runs the lookup backwards
IP address
93.184.216.34
the starting point
PTR lookup
in-addr.arpa -- their zone, not yours
Hostname
the answer
The reverse zone belongs to whoever owns the IP block -- not the domain owner
Reverse DNS Lookup Explained: PTR Records and IP Addresses
The lookup that runs backwards — why your hosting provider controls it, and why missing it quietly sends your email to spam.
The records you will meet in nearly every zone
DNS Record Types Explained: A, AAAA, CNAME, MX and TXT
Every record type worth knowing, what it does, what it looks like, and the mistake people make with it — in one reference page.