How to look up MX records (3 ways)
Three ways to look up MX records for any domain: a free MX records lookup tool, dig and nslookup from a terminal, and a few lines of Ruby or Python.
You need an MX records lookup when you set up a new email provider, debug a delivery problem, or audit a vendor. The lookup itself is fast. Knowing how to read the answer is the part that matters.
This guide shows three ways to look up MX records for any domain, then explains how to read the result. No setup needed for the first option.
What an MX records lookup tells you
When MX records exist, each record has:
- A priority value, also called preference. Lower numbers are tried first.
- A mail server hostname, also called the exchange.
- One or more IP addresses that the hostname resolves to through A or AAAA records.
A lookup that returns no MX records means the domain has no explicit mail exchanger. Under RFC 5321, standards-compliant SMTP senders then treat the domain’s A or AAAA address as an implicit MX. That fallback exists for compatibility, but it is not how modern hosted mail should be configured.
A lookup that returns a single record of 0 . means the domain explicitly refuses email under RFC 7505, known as a null MX.
Three ways to look up MX records
1. Use a free MX records lookup tool
The fastest option. Open our free MX records lookup, type a domain, and submit. The tool returns every MX record sorted by priority, resolves each mail server’s IPv4 and IPv6 addresses, and identifies the email provider behind the host when it recognizes one.
Best if you want priorities, hosts, IPs, and providers in one view without touching a terminal.
2. Use dig or nslookup
If you have a Unix terminal:
dig +short mx yourdomain.com
Output looks like:
1 smtp.google.com.
For more detail (TTL, authority records):
dig mx yourdomain.com
On Windows or any system with nslookup:
nslookup -type=mx yourdomain.com
To find the IP addresses for an MX hostname, run a second lookup against that host:
dig +short a smtp.google.com.
dig +short aaaa smtp.google.com.
dig is the standard troubleshooting tool. Reach for it when you need to see exactly what the resolver returns, including the trailing dot on hostnames and the TTL.
3. Resolve programmatically
In Ruby:
require "resolv"
domain = "yourdomain.com"
Resolv::DNS.open do |dns|
dns.getresources(domain, Resolv::DNS::Resource::IN::MX)
.sort_by(&:preference)
.each { |mx| puts "#{mx.preference}\t#{mx.exchange}" }
end
In Python:
import dns.resolver
domain = "yourdomain.com"
for mx in sorted(dns.resolver.resolve(domain, "MX"), key=lambda r: r.preference):
print(mx.preference, mx.exchange)
Programmatic lookups are the right choice when you need to audit many domains at once or feed the answer into another step in a pipeline. If your script reports “no MX”, check A and AAAA records separately before deciding whether mail is completely unreachable.
How to read the results
Four patterns cover almost every real domain.
A single MX record is common with modern hosted-mail setups. Google Workspace, for example, now documents smtp.google.com with priority 1 for new configurations. Older Google Workspace domains may still use the legacy aspmx hostnames, and working legacy records do not need to be changed.
When a domain has multiple MX records at different priority values, SMTP clients try the lowest numeric value first. Numerically higher values are fallbacks, used only when the preferred servers are unreachable. A typical pattern is 10 primary.example.net. and 20 backup.example.net..
When several MX records share the same priority, sending servers spread delivery attempts across them. This is normal for providers that publish several equivalent inbound hosts.
When the lookup returns no MX records, the domain has no explicit inbound-mail route. Standards-compliant SMTP senders will fall back to the domain’s A or AAAA address. In practice, if the domain is supposed to receive business mail, no MX is usually a configuration problem.
If an MX hostname returns no IP addresses, that MX target is unusable. Mail may still be delivered through another usable MX target, but if all targets are unusable, mail will queue and eventually bounce.
Common issues
No MX records found
Either the domain was never configured to receive email, or it lost its MX records during a DNS change. SMTP’s implicit A/AAAA fallback may still cause delivery attempts to the web host, but you should not rely on that for production mail. If the domain is supposed to receive mail, check the DNS provider for the apex zone and republish the provider’s documented MX records.
Null MX (priority 0, host .)
This is intentional. The domain owner published a null MX to declare that the domain does not accept mail. Sending servers can reject delivery immediately rather than retrying for days. You see this on parked domains, brand-protection domains, and web-only domains.
Do not publish null MX on a domain you use in visible From: addresses or envelope sender addresses. Some receiving systems treat that as a sign that bounce handling cannot work and may reject the outbound mail.
Too many backup MX records
Backup MX records were a useful pattern when many organizations operated their own mail servers. They are usually unnecessary with modern hosted mail because the provider’s documented MX hostnames already represent redundant infrastructure. Long backup lists often include forgotten hostnames pointing at servers no one operates anymore. Spammers have historically targeted weaker backup MX paths to bypass primary filtering. Trim the list to the hosts your provider actually documents and filters.
MX hostname has no A or AAAA record
An MX target must be a hostname that resolves to at least one address record. It should not be an IP address, and it should not point at a CNAME. If the hostname does not resolve, remove the stale MX record or fix the target hostname at the provider that owns it.
Look up your domain’s MX records
The fastest path is usually the web tool. Open the free MX records lookup, enter your domain, and read the answer.
If your MX records look right but mail is still failing authentication, you probably have an SPF or DKIM alignment problem. Run a full check with our domain checker to see DMARC, SPF, BIMI, and TLS-RPT alongside MX.
