Domain IP Lookup

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

Practical Guides

What Is an MX Record? How MX Records Route Email

5 min read

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

Every outbound email starts with an MX lookup on the recipient's domain.

What an MX record looks like

A typical Google Workspace setup
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.34 is invalid; use MX 10 mail.example.com. with an A record 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 A or AAAA record. 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:

RFC 7505 null MX
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 TXT record listing which servers may send as your domain.
  • DKIM — a TXT record publishing the key that signs your outgoing mail.
  • DMARC — a TXT record 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

Sorted by priority
dig +short example.com MX

The 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

what is an mx recordmx record priorityemail dns recordsmx record explained

Frequently asked questions