MX Record Lookup
See which mail servers accept email for a domain.
Perform MX Lookup
What is a MX record?
An MX record (Mail Exchange) tells sending mail servers where to deliver email for a domain. Each MX record has two components: a priority (a non-negative integer — lower is preferred) and a hostname (the target mail server). When a sender has email to deliver to user@example.com, it queries example.com for MX records, sorts the results by priority, and attempts delivery to the lowest-priority server first.
Priority numbers are arbitrary — only their relative ordering matters. A domain with 10 mail1.example.com and 20 mail2.example.com will prefer mail1; if mail1 is unreachable, the sender tries mail2. Two MX records with the same priority are load-balanced (the sender picks one at random or round-robin). Most production setups use primary/secondary priorities (10 and 20) or equal-weight pools (all priority 10).
MX records govern incoming mail only. Outgoing mail uses the sender's own SMTP relay and doesn't consult MX records on the sender's domain — the recipient's MX is what matters. This is why a domain can publish MX records pointing to one mail provider (e.g. Google Workspace) while sending outbound email through an entirely separate ESP.
A special case: the "null MX" record (0 ., a single dot as the target) explicitly signals "this domain does not accept email" (RFC 7505). Publishing a null MX is the correct way to opt out of inbound mail — it tells senders to bounce immediately rather than retry indefinitely against a non-existent mail server.
How to read the results
The result shows each MX hostname paired with its priority. Read them as a prioritised list — the lowest priority number is the preferred server, and ties indicate load-balanced pools.
Common patterns you'll see:
— Google Workspace: a single MX at 1 aspmx.l.google.com, plus four higher-priority backup MXes in the 5–10 range
— Microsoft 365: a single MX like 0 example-com.mail.protection.outlook.com
— Hosted provider: a primary/secondary pair at priorities 10 and 20
— Self-hosted: one or more custom hostnames pointing at your own mail servers
Each MX target must resolve to an A or AAAA record — MX pointing at a CNAME is technically forbidden by RFC 2181, though some resolvers tolerate it. Most deliverability issues rooted in MX misconfiguration trace back to either a missing A record on the MX target, or a typo in the MX hostname itself.
Common issues
- No MX records at all. If the domain is supposed to accept mail, senders have nothing to deliver to. Senders will either bounce immediately (some implementations) or fall back to the A record of the domain itself (legacy RFC 5321 §5.1 behaviour), but you should not rely on the fallback — publish real MX records.
- MX pointing to a CNAME. Technically forbidden by RFC 2181. Some mail servers tolerate it, but strict ones (Microsoft, Google) reject. Always point MX records at hostnames with direct A/AAAA records.
- Mail still bouncing after MX setup. The DNS is correct but delivery is failing at a higher layer — the receiving server might reject based on sender reputation, SPF alignment, DMARC policy, or greylisting. Use our Email Header Analyzer on a bounce message to see the rejection reason.
-
MX hostname and SMTP banner hostname mismatch. If your MX says
mail.example.combut your mail server identifies itself assmtp.example.netin SMTP banners, some receivers will flag this as suspicious. Consistent forward/reverse DNS naming improves deliverability. - Null MX but users still sending mail. A null MX tells the world "don't send here" — but if you haven't disabled your outbound mail or redirected user addresses, you've created a support nightmare. Coordinate the MX change with the migration of mail functionality.
Other DNS Lookups
Automate your DNS
DMARC Busta manages SPF, DKIM, and DMARC records across 10,000+ domains — no manual lookups needed.
Start free trial