What does the number before the hostname mean?

It is a preference value, and lower is tried first. It is not a weight or a ranking of quality. Two records with the same number are used interchangeably; a higher number is only reached when every lower one is unreachable.

Can I point an MX record at an IP address?

No. An MX target must be a hostname that itself has A or AAAA records. Publishing an IP address there is invalid and many senders will reject it outright. Create a hostname such as `mail.example.com`, give it an address record, and point the MX at that name.

Do I need a backup MX record?

Almost certainly not. Modern mail servers queue and retry for days when a destination is unreachable, which gives you the same protection without extra infrastructure. A backup MX only helps if it can genuinely relay to your primary, and a misconfigured one attracts spam and creates bounce loops.

What does an MX record of "0 ." mean?

That is a null MX, defined in RFC 7505. It states explicitly that the domain accepts no email, so senders fail immediately with a clear error instead of retrying for days. It is the correct configuration for a domain used only for a website or only for outbound sending.

Why does my MX lookup differ from my provider dashboard?

You are probably seeing cached data. Your resolver holds the previous records until their TTL expires, while the dashboard shows what is configured now. Check the propagation checker to see the spread across public resolvers, and query your authoritative nameservers directly to see the current truth.

Does changing MX records affect my website?

No. MX records control mail routing only. Your website is reached through A, AAAA, or CNAME records, which are entirely separate. This is exactly why a broken MX record can go unnoticed — the site stays up while mail quietly disappears.

Should www.example.com have MX records?

Normally no. Mail is addressed to the domain in the address, which is usually the apex, so that is where MX belongs. This tool queries the exact name you enter without stripping "www", so if you check a www hostname you will correctly see that it has no MX records of its own.

MX Lookup — Check MX Records for Any Domain

An MX lookup shows which mail servers accept email for a domain, and in what order senders should try them. Enter a domain and this tool queries its MX records live, sorted by priority, exactly as a sending mail server would before delivering a message.

What an MX record actually does

When a mail server has a message for [email protected], it does not look up the A record for example.com. It asks DNS for the MX records of example.com, gets back a list of hostnames each tagged with a preference number, and tries them in ascending order of that number. Each MX hostname is then resolved to an address and contacted on port 25.

This indirection is what lets you host your website on one provider and your email on another. It is also why a nameserver change that drops your MX records will break inbound mail while the website keeps working perfectly — a failure mode that catches people out constantly. If mail stopped after a DNS change, start with Mail bouncing after a DNS change.

How to read the priority number

The number in front of each hostname is a preference, and lower wins. It is not a weight, a percentage, or a quality score. A sender tries the lowest number first and only moves to a higher one when the lower host cannot be reached.

Records	What senders do
`10 mail.example.com`	Single destination. Every message goes here; if it is down, senders queue and retry.
`10 a.example.com` and `20 b.example.com`	`a` is primary, `b` is a backup used only when `a` is unreachable.
`10 a.example.com` and `10 b.example.com`	Equal preference — senders pick between them arbitrarily, spreading load across both.
`0 .`	A null MX (RFC 7505): an explicit declaration that this domain sends no mail and accepts none. Senders reject immediately instead of retrying for days.

Read the full explanation of mx lookup results ↓

A backup MX that does not know how to relay to your primary is worse than no backup at all. It accepts mail, cannot deliver it onward, and either bounces it later or becomes a spam magnet. Unless you are deliberately running a store-and-forward relay, one priority level is the right answer.

Rules that MX records must follow

An MX target must be a hostname, never an IP address. 10 192.0.2.1 is invalid; publish 10 mail.example.com and give that name an A record.
An MX target should not point at a CNAME. Most receivers cope, but the standards forbid it and some strict implementations will fail.
The target must resolve. An MX pointing at a hostname with no A or AAAA record makes your domain undeliverable.
A domain cannot have both a CNAME at its apex and MX records — CNAME cannot coexist with other record types. See CNAME vs A record.
If a domain has no MX records at all, senders historically fall back to its A record. Do not rely on that: publish MX records, or a null MX if the domain should never receive mail.

Checking MX records from the command line

This tool runs the same query dig does. To confirm a result independently, or to check against a specific resolver:

# MX records, one per line, as "priority hostname"
dig +short example.com MX

# Ask a specific public resolver rather than your local one
dig @8.8.8.8 +short example.com MX

# Full answer with TTLs, useful while waiting for a change to propagate
dig example.com MX +noall +answer

# Resolve what an MX target actually points to
dig +short mail.example.com A

Note that +short output is not guaranteed to be sorted by priority — read the numbers, not the order.

Common problems this lookup exposes

No MX records returned

Either the domain never had them, or they were lost. The most common cause is a nameserver change where the new provider started from an empty zone: the site was migrated, the MX records were not, and inbound mail silently stopped. Republish them, then verify with this tool before telling anyone the problem is fixed.

MX records exist but mail still bounces

Routing is only the first of three things that must be right. Once MX is correct, receivers still need to authenticate you: check SPF, DKIM, and DMARC, and confirm the sending IP has valid reverse DNS with the PTR lookup. The deliverability test runs all of those at once.

MX points somewhere unexpected

A domain whose MX suddenly points at an unfamiliar host is worth investigating immediately — it can indicate a compromised DNS account. Compare against what you expect to see, and check WHOIS for recent registrar changes.

Changes not showing up yet

MX records are cached like any other record. Until the old TTL expires, some senders will keep using the previous values. Use the propagation checker to see what resolvers around the world currently hold, and read how long DNS propagation takes for what actually controls the wait.

What a healthy configuration looks like

MX records exist and every target resolves to a reachable address.
Priorities express a deliberate intent — one primary, or several equal hosts you actually operate.
No MX target is an IP address or a CNAME.
SPF, DKIM, and DMARC are published and aligned for every service that sends as this domain.
The sending IP has a matching PTR record, which Yahoo and Microsoft now expect from bulk senders.
A domain that should never receive mail publishes a null MX (0 .) rather than nothing at all.

Email Deliverability Test

SPF + DKIM + DMARC + MX + PTR on one screen

MX Lookup