Domains and DNS

What is an MX record?

Almost every “we are not receiving email” problem ends at the MX records, and almost every explanation of them gets the priority numbers backwards.

An MX (Mail eXchanger) record is a DNS record that names the server which accepts email for a domain, together with a preference number. A sending mail server looks up the MX records for the part after the @, sorts them by preference, and tries the LOWEST number first — so 10 is tried before 20. If a domain has no MX record at all, the sender falls back to the A or AAAA record; if it publishes a null MX (a single record with preference 0 and a target of .), the domain is declaring that it accepts no mail at all.

Worked out 2026-09-11 (IST) · standard SMTP mail routing as defined in RFC 5321

How a message actually finds your server

When a mail server has a message for you@example.com, it does not look up example.com in a directory of companies. It performs one DNS query for the MX records of example.com, and everything else follows from the answer.

The lookup, step by step
Step	What happens	What can go wrong
1. Query MX for the domain	Returns a list of preference/host pairs	No MX records at all — sender falls back to the A record, which is usually a web server
2. Sort by preference, lowest first	10 before 20 before 50	Nothing; this step is deterministic
3. Resolve the chosen host to an address	A or AAAA lookup on the MX target	Target is a CNAME, or does not resolve — the record is skipped or rejected
4. Connect on port 25 and deliver	SMTP conversation	Firewall, greylisting, or the receiving server rejects on SPF/DMARC
5. On failure, try the next preference	The backup MX	A backup MX that does not know the domain becomes a spam relay or a black hole

What a real MX set looks like

Common providers and their published records
Provider	Typical MX set	Shape
Google Workspace	1 smtp.google.com	A single record; the old five-record ASPMX set is legacy
Microsoft 365	0 yourdomain-com.mail.protection.outlook.com	One record, tenant-specific
Zoho Mail	10 mx.zoho.in, 20 mx2.zoho.in, 50 mx3.zoho.in	Primary plus two fallbacks
Self-hosted	10 mail.yourdomain.com	One record pointing at your own host
Accepts no mail	0 .	Null MX per RFC 7505 — senders fail fast instead of timing out

Reading the four faults that actually happen

Symptom to cause
Symptom	Most likely cause
No mail arrives at all, senders get "domain not found"	MX records missing, or the domain's name servers are wrong
Mail arrives hours late	The lowest-preference host is unreachable and senders are queueing before falling back
Some senders deliver, others bounce	MX target is a CNAME, or one host in the set has a broken certificate
Mail goes to the old provider after a migration	Old MX still cached — wait out the TTL
You receive mail but yours lands in spam	Nothing to do with MX. That is SPF, DKIM and DMARC.

MX records govern mail coming in. They have no effect whatsoever on whether the mail you send is accepted — that is decided by the three records covered in SPF, DKIM and DMARC.

Sources: IETF RFC 1034 and RFC 1035 (domain names), RFC 2181 (clarifications to the DNS specification), RFC 5321 (SMTP) and RFC 7505 (null MX).

Check your own numbers

Read the live MX records for any domain, with their preference numbers.

DNS LookupA, AAAA, MX, NS, TXT, CNAME and SOA records, live from the resolver.

Frequently asked

Does a lower MX priority number mean less important?

No, the opposite, and this is the single most common misunderstanding. The number is a preference, not a rank - it is the order in which a sender should try hosts, lowest first. An MX at preference 1 is your primary mail server; one at preference 50 is the last resort. The absolute values do not matter, only their relative order, so 1/5/10 behaves identically to 10/20/30.

Can I have two MX records with the same priority?

Yes, and it is how load balancing is done. When several MX records share a preference number, the sender picks among them at random, which spreads inbound mail across the hosts. Google Workspace and Microsoft 365 both publish equal-preference sets for exactly this reason.

Can an MX record point at an IP address?

No. RFC 5321 requires the MX target to be a host name that itself resolves to an address record, and it must not be a CNAME. Pointing an MX at a bare IP, or at an alias, is a configuration error that some senders tolerate and many reject - which produces the worst kind of fault, where most mail arrives and some silently does not.

How long does an MX change take to work?

It takes as long as the old record's TTL, because resolvers that already cached it will keep using the cached copy until it expires. Lower the TTL to 300 seconds a day before you migrate, make the change, then raise it again once mail is flowing. The change itself is instant at your authoritative name server; the wait is entirely in other people's caches.

Need domain and DNS checks inside your own product?

We build WHOIS, RDAP, DNS and SSL lookups as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.