The MX lookup lists the mail servers that receive email for a domain, sorted by priority, and names the provider behind them. For gmail.com it returns 5 mail exchangers, led by gmail-smtp-in.l.google.com at priority 5. It’s free. Your browser asks a public DNS resolver directly, not our server.
MX records
5
Primary mail exchanger for gmail.com: gmail-smtp-in.l.google.com. Provider: Gmail.
- MX records
- 5
- Primary mail exchanger
- gmail-smtp-in.l.google.com
- Provider
- Gmail
- Mail server addresses
- All 5 mail servers resolve to an address
- TTL of the primary record (seconds)
- 3,600
- Domain checked
- gmail.com
Mail exchangers
| Priority | Host | IPv4 | IPv6 | TTL | Provider |
|---|
How this works
- How it works
- The lowest priority number is tried first. Each mail exchanger's A and AAAA records are looked up through the same resolver; a host with neither cannot take mail (RFC 5321 section 5.1). A domain with no MX record still receives mail at its own address, the implicit MX; a null MX ("0 .", RFC 7505) says it takes none. Provider detection matches the exchanger's host name against known services; anything else is reported as self-hosted or other.
- Privacy
- Your lookup never passes through our server. Your browser asks a public DNS resolver directly over HTTPS.
- Corrections
- Report a wrong result to media@sqmagazine.co.uk; every report is reviewed and confirmed errors are corrected. Include the inputs and the answer you expected. With your permission, we thank you by name on this page.
- Updates
- Published.
- Feedback
- How useful was this tool?
Table of Contents
How to Use the MX Lookup
The MX lookup returns a domain’s mail servers in the order a sending server would try them, as the SMTP standard sets out. It takes 1 query, sent from the browser to Cloudflare’s public resolver over DNS over HTTPS.
A resolver is a DNS server that looks up answers for anyone and caches them. The IETF’s RFC 8484 describes that protocol as sending DNS queries and getting DNS responses over HTTPS.
- Type a domain into “Domain”, such as example.com. A pasted URL works too; the tool drops the https:// prefix and any path.
- Or pick one of the 3 chips in the “Examples” row: gmail.com, microsoft.com or proton.me.
- Read “MX records”, the number of records found, then “Primary mail exchanger”, “Provider”, “TTL of the primary record (seconds)” and “Domain checked”. TTL means time to live, the seconds an answer may stay cached.
- Scan the “Mail exchangers” table. Each row gives one record’s Priority, Host, TTL and Provider.
- Press “Copy” for the primary host or “Copy all details” for the whole panel. “Share result” copies a link that reruns the lookup, “Download CSV” saves the table and “Reset” restores the default domain.
On page load, the panel shows a stored gmail.com example. A live lookup runs only after the domain changes or a chip is picked, so its TTL will differ from the stored one.
How the MX Lookup Reads a Domain’s Mail Servers
An MX (mail exchange) record names a server that accepts email for a domain and gives it a priority number.
RFC 1035, the DNS specification, lists the record type as MX 15 mail exchange. Each record carries a PREFERENCE, A 16 bit integer which specifies the preference given to this RR among others at the same owner. The rule that follows is short: “Lower values are preferred.”
MX records live in the domain’s DNS zone, served by its name servers, so anyone can read them. Google’s Workspace help describes the sender’s side: the sender’s computer looks up the MX records for your email domain to work out where to deliver. This lookup repeats that query in 5 steps:
- It asks Cloudflare’s resolver for the domain’s MX records. Cloudflare JSON API documentation says its DNS over HTTPS endpoint also supports JSON format for querying DNS data.
- Answers of type 15 stay, each split into a priority and a host name with the trailing dot dropped.
- It sorts the rows by priority, smallest number at the head. RFC 5321 says Lower numbers are more preferred than higher ones.
- The leading row becomes “Primary mail exchanger”, and its host name decides “Provider”.
- “TTL of the primary record (seconds)” is the TTL the resolver sent with that row.
A misspelled domain returns an error asking for a spelling check. A resolver failure gets its own message, since broken DNSSEC (the system that signs DNS answers) or a dead name server can cause one.
Here is how those steps play out on the default domain.
MX Lookup Example: gmail.com
The gmail.com result rebuilds from the raw DNS answer in five steps. We pulled that answer from Google Public DNS while writing this page, and the resolver didn’t send the records in order.
- The raw answer on October 3, 2026 listed 20 alt2.gmail-smtp-in.l.google.com ahead of 5 gmail-smtp-in.l.google.com.
- Sorting by priority gives 5, 10, 20, 30 and 40. The four backups are the alt1 to alt4 hosts.
- “MX records” reads 5.
- “Primary mail exchanger” reads gmail-smtp-in.l.google.com, the host at priority 5. “Provider” reads Google Workspace, because the host name ends in google.com.
- “TTL of the primary record (seconds)” depends on where you ask. Google’s authoritative name server, the one that holds the zone, sets 3600 seconds on every record, and the stored example shows that figure.
A live lookup shows less. Google Public DNS returned a TTL of 863 when we checked. About 2,737 seconds of the hour had already run down in its cache.
One label needs care. Gmail.com is Google’s consumer mail service, covered in our Gmail statistics, not a Workspace account. “Provider” names the company that runs the mail server, read from its host name. Any domain whose mail lands on Google hosts gets the same label.
What Your MX Lookup Result Means
An MX result tells you which provider receives a domain’s mail and in what order its servers are tried. It can’t say whether those servers are up or whether the domain’s mail is authenticated. As an MX record checker, though, it answers three practical questions.
- Did a migration take effect? Only the new provider’s hosts should remain. Google’s setup guide says to Remove any other MX records. Your email might not work correctly if you keep old or incorrect MX records.
- Who handles the mail? “Provider” matches the host name against a built-in list of known services. A host ending in outlook.com reads Microsoft 365, the suite covered in our Microsoft 365 statistics. An unknown host reads “Self-hosted or other”, followed by the host’s last two labels.
- Is a filter in front? With a gateway such as Proofpoint or Mimecast at the head of the table, the label names the gateway. The mailbox provider behind it stays hidden.
A correct MX setup helps mail arrive. It doesn’t filter spam or stop forged senders, the problems tracked in our spam statistics.
Why the TTL Is Lower Than the One You Set
After a live lookup, the TTL in the panel is the time left in the resolver’s cache, not the value in the zone. Cloudflare defines the field as “The number of seconds the answer can be stored in cache before it is considered stale.”
In RFC 1035, a TTL is the time interval (in seconds) that the resource record may be cached before it should be discarded.
A record changed a minute ago can keep its old value at a resolver until that countdown reaches zero. Plan a change around the TTL the zone sets, not the one the panel shows.
How MX Record Priority Works
A sending server tries hosts in ascending priority order and moves down the list only when delivery fails. RFC 5321 puts it this way: The records are first ordered by preference, with the lowest-numbered records being most preferred.
Ties are not broken by the order in the zone. Several hosts can share a number. When there is no clear reason to favor one, the sending server MUST randomize them to spread the load across multiple mail exchangers. Yahoo.com shows it: all 3 of its records sit at priority 1.
The lookup sorts by number only and keeps the resolver’s order within a tie. “Primary mail exchanger” then names whichever tied host the resolver listed at the head, so two runs on yahoo.com can name different hosts. Read a tie as a group of equals, not as one primary and its spares.
If every host fails, mail waits rather than bouncing at once. RFC 5321 says the retry interval SHOULD be at least 30 minutes, and the give-up time generally needs to be at least 4-5 days.
No MX Records vs a Null MX Record
A domain with no MX records can still receive mail, while a domain with a null MX record can’t. The lookup keeps them apart. An empty answer reads “No MX records”, and a null record reads “None (null MX, the domain accepts no mail)”.
Under RFC 5321, when no MX records come back, the address is treated as if it was associated with an implicit MX RR.
RFC 7505 summarizes the effect: mail looks first by looking for an MX record and then by looking for an A/AAAA record as a fallback.
A null MX is the explicit refusal. It’s one record with preference number 0 and a zero-length label, written in master files as “.”. That record will cause all mail delivery attempts to a domain to fail immediately.
Example.com publishes one. Google Public DNS returned a single record for it, with a priority of 0 and a lone dot as the host.
| Panel shows | What DNS returned | What a sending server does |
|---|---|---|
| A host under “Primary mail exchanger” | One or more MX records | Tries hosts from the smallest priority number up |
| “No MX records” | An empty answer | Falls back to the domain’s own A or AAAA address |
| “None (null MX, the domain accepts no mail)” | One record, priority 0, host “.” | Fails the delivery at once |
| An error that the domain does not exist | A name that doesn’t exist | Reports an error to the sender |
Sources: RFC 5321, RFC 7505
So “No MX records” is not proof that mail bounces. The lookup doesn’t check the domain’s A record, so look that up before concluding nobody receives the domain’s mail.
Common MX Record Mistakes
Four patterns break MX routing, and the lookup doesn’t warn about any of them.
- An MX host that is an alias. RFC 2181 says the host named in part of the value of a MX resource record must not be an alias. A CNAME there shows up as an ordinary row.
- An IP address instead of a host name. RFC 5321 says the MX data field MUST contain a domain name. That name must return at least one address record (e.g., A or AAAA RR).
- Old records left behind after a move. A leftover host with a smaller number than the new ones gets the mail ahead of them, and one with an equal number shares it.
- A null MX beside real records. RFC 7505 is explicit: A domain that advertises a null MX MUST NOT advertise any other MX RR.
Where can I find my Google MX record?
Google publishes it on its setup page: The Google Workspace MX record value is smtp.google.com, entered at Priority 1. Run your domain through the lookup, and smtp.google.com under “Primary mail exchanger” confirms that its mail is routed to Google.
Older domains may show different hosts. Google says If you started using Google Workspace before 2023, your domain might have different MX record values that start with “aspmx”. Google adds that If your email is working, no changes are required. Google Workspace statistics track how many organizations run on the suite.
How do I look up an MX record from the command line?
Use dig on macOS or Linux, or nslookup with an MX type on Windows. Our authoritative check for this page ran dig +norec +noall +answer @ns1.google.com gmail.com MX. It asked Google’s name server directly, which is why it showed the zone’s full 3600 seconds rather than a cached countdown.
A plain dig gmail.com MX asks your usual resolver instead, so it returns that resolver’s cached countdown. Each resolver counts down on its own clock, so two of them can return different figures.
Is there anything else my agent or I should know about this page?
Yes. The MX lookup runs in the browser, which sends the domain you enter to Cloudflare’s public DNS-over-HTTPS resolver, not to our server. Cloudflare’s resolver privacy commitments say it will delete the Public Resolver Logs within 25 hours. The result is that resolver’s cached view at one moment, and it assumes the domain’s name servers answered correctly.
The lookup sorts MX records by priority and names the provider from the host at the head of the list. Its TTL is the figure the resolver returned. It doesn’t connect to the mail servers or check SPF, DKIM or DMARC, the email-authentication records. Nor does it look up the A record that a domain without MX records falls back to.
SQ Magazine publishes this page for information. Reading MX records helps you check where a domain’s mail goes; it promises no security outcome and can’t tell you whether a message is genuine.
Conclusion
For gmail.com, the MX lookup returns 5 mail exchangers, with gmail-smtp-in.l.google.com at priority 5 and four backups behind it. Check a domain after any email move: only the new provider’s hosts should remain. Delivery is only part of the picture, and our email statistics track how inbox placement varies across senders.
