--- title: Why isn't our email arriving? How to check MX records with the MX Lookup description: Mail to your domain bounces, or part of it still lands at the old provider after a switch. To check MX records, look up the domain's MX set and confirm every host belongs to the provider you use now, with sensible priorities. Here's how to do it with the free MX Lookup, how to read priorities, and the dig commands that show TTLs. canonical: https://watchfor.io/blog/how-to-check-mx-records --- # Why isn't our email arriving? How to check MX records with the MX Lookup 2026-10-04 · WatchFor Team · Guides · guides, email, dns Mail to your domain bounces, or part of it still lands at the old provider after a switch. To check MX records, look up the domain's MX set and confirm every host belongs to the provider you use now, with sensible priorities. Here's how to do it with the free MX Lookup, how to read priorities, and the dig commands that show TTLs. To check MX records, look up the domain's MX set and read two things: which hosts are listed, and the priority number next to each. Every host should belong to the mail provider you use today, and the lowest number is the server senders try first. A leftover host from your old provider, or no MX record at all, explains most "mail isn't arriving" reports after a switch. The free [MX Lookup](/mx-lookup) shows every MX record of a domain as a sending mail server sees it, from a real WatchFor location, in about a second. No signup. ## What this tool answers *Where does mail for this domain go?* Reach for it right after you move mail to Google Workspace or Microsoft 365, when messages bounce with "no mail server" errors, or when part of your mail keeps landing in the old mailbox. Sending servers look up exactly these records before delivering, so if the MX set is wrong here, it's wrong for every sender. ## A real example ### Checking MX records after a move to Google Workspace The classic report after a migration: most mail arrives in the new Google mailboxes, but some messages still show up at the old host, or bounce. The first question is whether the domain still publishes an MX that points at the old provider. We checked a public domain that runs its mail on Google Workspace to show what a clean result looks like. In the [MX Lookup](/mx-lookup) we typed `mozilla.org`, kept the resolver on **Auto** and pressed **Run lookup**: ![The MX Lookup for mozilla.org run from Vilnius with the location's own resolver: NOERROR, 4 records in 183 ms, aspmx.l.google.com with priority 1, alt2.aspmx.l.google.com and alt1.aspmx.l.google.com with priority 5, and aspmx3.googlemail.com with priority 10](/blog/how-to-check-mx-records-result.webp) The lookup ran from Vilnius and came back `NOERROR` with **4 records** in 183 ms: | Priority | Host | Owner | | --- | --- | --- | | 1 | aspmx.l.google.com | Google | | 5 | alt1.aspmx.l.google.com | Google | | 5 | alt2.aspmx.l.google.com | Google | | 10 | aspmx3.googlemail.com | Google | How to read it: senders try priority **1** first. If it doesn't answer, they move to the two hosts at **5** (picking one at random, since they share a number), then to **10**. Every host is a Google name, so there is no stray record that could send mail anywhere else. These are Google's older `aspmx` values. Google's current setup guide gives a single MX, `smtp.google.com`, for new domains, and says the legacy values are still supported. Both are correct. **The answer:** the MX set is clean, with one provider and sensible fallbacks. On your own domain, look for the opposite: a host from the old provider (say, `mx1.oldhost.net` at priority 20) is a live fallback. Whenever Google is slow or unreachable, senders deliver there instead, and mail turns up in the old mailbox. Delete the leftover record at your DNS host. ## How to read the results | What you see | What it means | | --- | --- | | **Resolve time** | How long the resolver took to answer. Green under 50 ms, amber under 200 ms, red above. It measures DNS speed, not whether your mail flows. | | **MX** | The record type that was asked for. The record-type menu can switch to A, TXT, NS and others without leaving the page. | | **NOERROR** (green) | The name exists and the resolver answered. Any other code (amber) is a problem: `NXDOMAIN` means the domain doesn't exist at all, `SERVFAIL` usually a broken zone or DNSSEC. | | **N records** | How many MX records came back. `NOERROR` with **0 records** means the domain exists but publishes no MX. | | **Host** | The mail server senders connect to. It must be a host name with its own A/AAAA record, never an IP address or a CNAME. | | **Priority** | The MX preference. Lower is tried first; equal numbers share the load. Only the order matters, not the size of the gap. | | **Location and resolver** | Where the query ran (the nearest location, shown in the form) and which resolver answered. **Auto** asks that location's own resolver; you can pick Cloudflare, Google, Quad9 and others, or a **Custom IP** such as your authoritative nameserver. | ## More ways to use it - **During a cut-over.** Switch the resolver to your DNS host's nameserver (**Custom IP**) to confirm the new MX set is published at the source, then back to **Auto** to see what caches already hand out. - **Bounces saying the domain doesn't accept mail.** A lone `0 .` record is a "null MX" (RFC 7505): the owner declares that the domain receives no mail. If you see it on a domain that should receive mail, someone copied a parked-domain template. - **Checking a vendor or a customer's domain.** Before you blame your own server for a bounce, see where their mail goes. `*.mail.protection.outlook.com` is Microsoft 365, `*.google.com` is Google, and gateway names (Proofpoint, Mimecast) mean a filter sits in front. - **A new subdomain for app mail.** If `notify.example.com` sends mail, it needs its own MX only if replies or bounces should reach it there. ## Tips and gotchas - **TTL decides how long old answers linger.** The tool lists hosts and priorities; `dig` adds the TTL (below). Lower it a day before a migration, as the [DNS propagation guide](/blog/how-to-check-dns-propagation) explains. - **No MX doesn't mean no mail.** With no MX at all, RFC 5321 tells senders to fall back to the domain's A/AAAA address. If that is your web server, mail ends up knocking on a box that doesn't run a mail service. - **Two providers at the same priority split your mail.** Leaving the old host at the same number as the new one sends roughly half of inbound mail to each. - **MX only covers incoming mail.** Whether *your* outgoing mail is trusted is SPF, DKIM and DMARC; the [email authentication check](/email-policy-checker) covers that, and [SPF, DKIM and DMARC explained](/blog/spf-dkim-dmarc-explained) shows how they fit together. - **A correct MX doesn't prove the server answers.** Point the [SMTP Server Test](/smtp-test) at the first host to see that it accepts connections and offers STARTTLS. ## Check it from the command line too `dig` shows the same set, plus each record's TTL: ```bash dig +noall +answer @1.1.1.1 mozilla.org MX ``` ```text mozilla.org. 60 IN MX 5 alt2.aspmx.l.google.com. mozilla.org. 60 IN MX 10 aspmx3.googlemail.com. mozilla.org. 60 IN MX 5 alt1.aspmx.l.google.com. mozilla.org. 60 IN MX 1 aspmx.l.google.com. ``` A 60-second TTL means a change to these records reaches every cache within a minute. The order in the answer is random; the priority column is what counts. To see what the source publishes, ask an authoritative nameserver directly: ```bash dig +short NS mozilla.org dig +noall +answer @ns1-240.akam.net mozilla.org MX ``` The null MX looks like this: ```bash dig +noall +answer @1.1.1.1 example.com MX ``` ```text example.com. 300 IN MX 0 . ``` ## Keep watching it An MX record that changes without anyone planning it means mail goes somewhere you don't control. A [DNS monitor](/dns-monitoring) with record type **MX** re-checks on a schedule, and its **Expected DNS Records** rule (values like `aspmx.l.google.com` or `1 aspmx.l.google.com`) opens an incident as soon as the answer stops matching: a leftover host added back, a record deleted during a DNS move, or a domain that lapsed and got parked. ## FAQ **How do I find the MX record for a domain?** Enter the domain in an MX lookup, or run `dig MX example.com` (`nslookup -type=mx example.com` on Windows). You get each mail host with its priority; the lowest number is tried first. **What does MX priority mean?** It's the order senders try the servers in. Lower numbers come first, equal numbers share the traffic at random, and higher numbers are fallbacks. The values themselves don't matter, only their order. **How long do MX record changes take?** As long as the old record's TTL: a minute for a 60-second TTL, an hour for 3,600. Mail servers retry for days, so while caches update, mail is delayed, not lost, unless an old host still accepts it. More on records in [DNS record types explained](/blog/dns-record-types-explained). --- Canonical page: https://watchfor.io/blog/how-to-check-mx-records · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt