MX Lookup

MX Lookup

Enter a domain in Domain name and click Lookup. You get the domain’s mail servers in the order other servers try them. Each comes with every address behind it, the reverse DNS name of each address, and whether that name points back.

The tool also recognises the email provider, summarises the domain’s SPF and DMARC records in plain words, and calls out setup problems.

Example: google.com

The tool recognises the provider as Google Workspace. There’s one mail server:

Under Sending policy:

• SPF: present. Mail from servers not on the list is marked suspicious (~all).
• DMARC: present, with policy “reject”: failing mail is refused.

The notes add that there’s one mail server and no backup, and that two server addresses have no reverse DNS name.

Neither note is a problem for Google, and the reasons are worth knowing. They’re explained below.

How senders use MX records

When someone sends mail to [email protected], their server looks up the MX records for example.com and tries the servers in order of priority, lowest number first. Servers with the same priority share the load. A server with a higher number is a backup, used only if the others don’t answer.

Each server name can have several addresses, and a sender tries them in turn before moving on. That’s why one name isn’t automatically a weakness. smtp.google.com has four addresses here, all run by Google.

The “no backup” note matters most for a self-hosted server with a single address. If it goes down, senders keep the mail in a queue and retry, usually for a few days, before bouncing it. The mail isn’t lost straight away, but nothing arrives until the server is back.

Problems the tool points out

• An alias as mail server. An MX record must name a host directly, not a CNAME. Many senders tolerate it, but some refuse, so mail from those senders fails without a clear reason.
• An IP address instead of a name. MX 10 203.0.113.5 isn’t valid. MX records need a hostname, and senders treat the IP address as a name that doesn’t exist.
• A dead host. The MX record names a server that has no address. That’s usually left over from an old provider, or a typo.
• No backup server. See above.

No MX record, and null MX

A domain with no MX record can still receive mail. Senders fall back to the domain’s own address (its A or AAAA record), as the email standard specifies. The tool shows this as an implicit MX, so you can see where that mail would actually go. Often it’s the web server, which isn’t set up to accept mail.

A null MX (MX 0 .) is a deliberate statement that the domain accepts no email at all. Senders then reject mail for it at once, instead of retrying for days.

For a domain that never sends or receives email, such as a parked domain or one kept for a brand, the usual protection against spoofing is three records:

MX     0 .
TXT    v=spf1 -all
_dmarc TXT  v=DMARC1; p=reject

That says: no mail comes in, no server may send as this domain, and receivers should refuse anything that claims to.

SPF and DMARC in plain words

These records aren’t about receiving mail. They tell other servers which mail sent in the domain’s name is genuine. The tool shows the raw record and what it means.

SPF lists the servers allowed to send for the domain. The ending says what to do with mail from anywhere else:

Two rules catch people out. A domain can have only one SPF record, so when adding a provider, merge its include: into the existing record rather than adding a second one. And SPF allows at most 10 DNS lookups, which each include: uses up quickly. Past that, the whole record fails.

DMARC tells receivers what to do when mail fails the checks: p=none (just report), p=quarantine (send to spam) or p=reject (refuse). The rua= address receives daily reports of who is sending as the domain. Google and Yahoo require a DMARC record from anyone sending them large volumes, so every domain that sends mail should have one.

Google’s own setup is a good example of how the two work together. Its SPF ends in a soft ~all, but its DMARC says reject. Under DMARC, a message fails only if it passes neither SPF nor DKIM for the domain. So the strict decision comes from DMARC, and SPF doesn’t need -all.

Why isn’t DKIM shown? A DKIM key lives at a name chosen by the sender, the “selector”, such as google._domainkey.example.com. There’s no way to list the selectors a domain uses. You’ll find yours in the headers of a message you sent (DKIM-Signature: … s=selector) or in your provider’s admin panel. You can then look that name up with DNS Lookup.

Reverse DNS on mail servers

Reverse DNS only matters for mail a server sends: receivers check that the sending address has a name that points back. The tool checks it on MX servers because, on smaller setups, the same machines often receive and send.

For Google, the IPv6 addresses without names don’t matter, since those addresses receive mail and Google sends from elsewhere. On your own server, a missing name is worth fixing. IP to Hostname shows who manages reverse DNS for an address, and IP Blacklist Check checks it against blocklists.

What it’s useful for

Switching email provider

After changing your MX records, check that only the new provider’s servers are listed. A leftover record from the old provider splits incoming mail between the two. Typical values:

• Google Workspace: smtp.google.com, priority 1. Older setups using aspmx.l.google.com and its alternates still work.
• Microsoft 365: a server ending in mail.protection.outlook.com, usually your domain with dots replaced by dashes.

When adding the new provider, update the SPF record to include it. The TTL column shows how long resolvers may keep serving the old records, and DNS Propagation Check shows which public resolvers have the new ones.

Mail isn’t arriving

Work through the result from the top:

1. Is there an MX record at all, or a null MX?
2. Do the servers have addresses, or are any marked as dead hosts?
3. Is any server an alias?

If everything looks right but one sender’s mail still bounces, the problem is often on the sending side. Ask for the bounce message.

Finding out who handles a domain’s email

The provider name at the top answers that in one look. That’s useful before migrating a client’s domain, or when checking where mail for a supplier’s domain really goes.

Checking a domain’s protection against spoofing

The SPF and DMARC summaries show whether others can easily send mail pretending to be the domain. No DMARC record, or p=none with no reports set up, means nothing stops them. To check the mail servers against spam blocklists, use the Email Blacklist Check.

FAQ

What does MX stand for?

Mail exchanger. It’s the type of DNS record that names the servers accepting email for a domain.

Do MX records affect the mail I send?

No. MX records decide where mail to the domain goes. Mail from the domain can leave from completely different servers, and SPF is what lists those.

Can a subdomain have its own MX records?

Yes. support.example.com can receive mail at a different provider from example.com. Look it up separately: subdomains don’t inherit MX records from the main domain.

I changed my MX records. Why do I still see the old ones?

Resolvers keep the old answer until its TTL runs out. If the old records are still there long after that, the change was probably made at a DNS provider the domain doesn’t use. The NS records in DNS Lookup show the one that counts.

Can I do this from the command line?

Yes. On Linux or macOS, dig +short example.com MX lists the servers, and dig +short example.com TXT shows the SPF record. On Windows, use nslookup -type=mx example.com.