📧 Mail Servers · Priority · Email Provider · DNS · Deliverability

MX Record Lookup

Free MX record lookup. Instantly query any domain's mail exchange records. See all mail servers sorted by priority and identify the email provider. Powered by Cloudflare and Google DNS.

✓ Live DNS query✓ Priority sorted✓ Provider detection✓ Instant results✓ No signup

📧

Enter a domain to look up its MX records

What this tool does

Free MX record lookup: check mail exchange DNS records, verify delivery configuration, and identify email providers

How MX records work, why they matter for email deliverability, and how to diagnose missing or incorrect mail server entries

MX (Mail Exchanger) records are the DNS entries that tell the internet which servers are authorised to receive email for a domain. Defined in RFC 1035, they are one of the most fundamental DNS record types. Without them, email cannot be reliably delivered to a domain. This tool performs a live DNS query via Cloudflare DoH (with Google DNS as fallback) and returns every MX record for any domain, sorted by priority, with automatic identification of the email service provider.

Priority numbers control delivery order: lower values mean higher priority. The sending mail server always attempts the lowest-priority-number server first. If it is unreachable, it falls back to higher-priority-number servers. This is why major providers publish multiple MX records, Google Workspace uses five servers across three priority tiers, Microsoft 365 uses a single record, providing redundancy so inbound email continues to deliver even during partial infrastructure outages.

The most common use cases for this tool are: verifying MX records propagated correctly after migrating to a new email provider; confirming which platform a domain uses for email (Google Workspace, Microsoft 365, Zoho, Proton Mail, and others are detected automatically); diagnosing inbound delivery failures by checking whether the correct mail servers are configured; and auditing acquired or legacy domains to understand their current email setup. Pair this with the Email Health Checker for a full authentication and deliverability audit including SPF, DMARC, and DKIM.

What this tool checks

Live DNS Query

Uses Cloudflare DoH for accurate real-time results with Google DNS as automatic fallback for high availability.

Priority Sorted

All MX records returned and sorted by priority number. Lowest number is the primary server tried first by senders.

Provider Detection

Automatically identifies Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, SendGrid, Mailgun, Amazon SES, and MXroute from exchange hostnames.

All Records

Every MX record is returned. Not just the primary. Multiple records at the same priority indicate load-balanced servers.

No-MX Detection

Clearly flags domains with no MX records and explains the null MX best practice for non-sending domains.

No Software

Runs entirely in the browser. No dig, nslookup, or command-line tools needed. Works on any device.

Why it matters

Why checking MX records matters for email delivery, migrations, and security

MX records are the foundation of inbound email delivery. A misconfigured, missing, or stale MX record is a hard delivery failure. Messages bounce with a permanent error and never reach the intended recipient. Unlike spam filtering (which is probabilistic), MX configuration is binary: either the records are correct and email can be delivered, or they are not and it cannot. This makes verifying MX records the correct first step whenever diagnosing inbound delivery problems.

Email provider migrations are the most common source of MX record errors. When moving from one platform to another, say, from Google Workspace to Microsoft 365, the process requires publishing new MX records and removing old ones simultaneously while managing DNS propagation delays. A common mistake is adding the new records without removing the old ones, creating a split-delivery situation where some senders reach the old provider and some reach the new one. Checking this tool immediately after a migration confirms which records are live globally and whether any old entries are still present.

For security, MX records are also relevant to spam and phishing prevention. Parked domains, legacy domains, and subdomains with no MX records (or no null MX record) are ambiguous targets. Some sending servers will still attempt delivery to the A record. Attackers sometimes exploit this to register look-alike domains and accept email intended for the legitimate domain. Publishing a null MX record on every non-sending domain closes this gap. Combine it with SPF v=spf1 -all and DMARC p=reject to fully lock down non-sending domains against both inbound delivery and outbound spoofing.

IT administrators and security teams also use MX lookups to audit domains acquired through mergers and acquisitions, verify that contractor or vendor domains are using expected mail infrastructure, and check whether a domain belongs to the provider claimed in an email before trusting its contents. Because MX records are public DNS data, this information is available without any authentication or permission.

Troubleshooting

Common MX record problems: causes and fixes

Most MX record issues fall into a small number of recognisable patterns. Here is what each means and how to resolve it.

No MX records found. Inbound email will fail

Why it happens: No MX DNS records exist for the domain. This can mean: the domain was recently registered and MX records have not yet been published, records were accidentally deleted during a DNS migration, or the domain is intentionally set up only for web use.

Fix: Log into your DNS provider and add the MX records required by your email platform. For Google Workspace: five records at priorities 1, 5, 5, 10, 10 pointing to ASPMX.L.GOOGLE.COM and the four ALT servers. For Microsoft 365: one record at priority 0 pointing to yourdomain.mail.protection.outlook.com. If the domain should never receive email, publish a null MX (priority 0, exchange '.') to prevent fallback delivery attempts.

Lookup shows old provider's MX records after migration

Why it happens: DNS propagation is still in progress. The old records are being served from cached resolvers that have not yet expired the TTL. This is expected behaviour immediately after an MX change.

Fix: Wait for the TTL of the old records to expire (check the TTL value. Common values are 300 to 3600 seconds). After expiry, re-run this lookup to confirm the new records are visible. If old records persist beyond 2× the TTL, log into your DNS provider and verify the old MX records were actually deleted, not just supplemented by new ones.

Both old and new provider MX records appear simultaneously

Why it happens: The old MX records were not deleted when the new ones were added. This causes split delivery. Some sending servers deliver to the old provider and some to the new one, depending on which MX record they receive from DNS.

Fix: Log into your DNS control panel and delete all MX records from the old provider. Leave only the new provider's MX records. During the brief propagation window after deletion, some delivery may be temporarily affected, but split delivery is worse than a short delay. After deletion, re-run this lookup to confirm only the new records appear.

MX record exists but email is not being received

Why it happens: Correct MX records do not guarantee delivery. The mail server itself must be correctly configured to accept email for the domain. Common issues: the email account has not been created at the new provider, the domain is not yet verified at the email platform, or the mail server is accepting connection but rejecting the recipient address.

Fix: Confirm the MX records are correct using this lookup. Then log into your email provider's admin console and verify: (1) the domain is verified and active, (2) the recipient's email account or alias exists, (3) there are no quota or storage issues on the receiving account. Check bounce messages for the specific SMTP error code, 550 5.1.1 means the recipient address does not exist at the server.

Lookup returns 'Custom / Unknown' for provider detection

Why it happens: The MX exchange hostname does not match any of the common provider patterns. This is expected for self-hosted mail servers, privately branded mail infrastructure, or smaller regional providers.

Fix: No fix needed. The provider detection is for convenience only. The raw MX records (hostname and priority) are still fully displayed. Look up the exchange hostname in a WHOIS tool or search it directly to identify the mail infrastructure provider.

Examples

Real MX record configurations: what common providers look like

Five common configurations showing what correct MX records look like for major email providers and use cases.

Example 1Google Workspace. Five servers, three priority tiers

Priority	Mail Server
1	ASPMX.L.GOOGLE.COM
5	ALT1.ASPMX.L.GOOGLE.COM
5	ALT2.ASPMX.L.GOOGLE.COM
10	ALT3.ASPMX.L.GOOGLE.COM
10	ALT4.ASPMX.L.GOOGLE.COM

All five records are required. Priority 1 is the primary. Two servers each at priority 5 and 10 provide load distribution and redundancy across Google's infrastructure.

Example 2Microsoft 365. Single record

Priority	Mail Server
0	yourdomain-com.mail.protection.outlook.com

Microsoft 365 uses a single MX record with priority 0. The exact hostname is generated from your domain name and shown in the Microsoft 365 admin centre. Only one record is needed. Microsoft's infrastructure handles redundancy internally.

Example 3Proton Mail. Two servers with failover

Priority	Mail Server
10	mail.protonmail.ch
20	mailsec.protonmail.ch

Proton Mail uses two MX records. The primary at priority 10 handles delivery; the secondary at priority 20 is the backup. Both exchange hostnames end in protonmail.ch.

Example 4Null MX. Non-sending parked domain

Priority	Mail Server
0	.

A single MX record with priority 0 and exchange '.' (dot) is the RFC 7505 null MX. It explicitly tells sending servers this domain accepts no email. Use on any parked, legacy, or non-email domain alongside SPF v=spf1 -all and DMARC p=reject.

Example 5Zoho Mail. Three servers

Priority	Mail Server
10	mx.zoho.com
20	mx2.zoho.com
50	mx3.zoho.com

Zoho Mail uses three MX records at priorities 10, 20, and 50. All three are required for full redundancy. The lowest-priority-number server (mx.zoho.com at 10) is the primary.

FAQ

MX record questions and answers

Answers to the most common questions about MX records, priority numbers, null MX, propagation, and provider-specific configuration.

What is an MX record?

An MX (Mail Exchanger) record is a DNS entry that specifies which mail servers are responsible for receiving email on behalf of a domain. When someone sends an email to [email protected], the sending mail server queries DNS for the MX records of example.com, then connects to the listed mail server to deliver the message. Without MX records, email cannot be reliably delivered to a domain. MX records are defined in RFC 1035 and are one of the most fundamental DNS record types for any domain that accepts email.

What does the priority number mean?

The MX priority (also called preference) is a number that controls delivery order. Lower numbers mean higher priority. A sending mail server always tries the lowest-priority-number server first. If that server is unreachable or returns a temporary error, it tries the next-lowest priority server. For example, priority 1 is attempted before priority 5, and priority 5 before priority 10. Having multiple MX records at different priorities provides redundancy. If the primary server is down, email queues and retries against the backup. Google Workspace uses priorities 1, 5, 5, 10, and 10 across five servers. Microsoft 365 typically uses a single server at priority 0.

Why does a domain have multiple MX records?

Multiple MX records provide redundancy and, in some configurations, load distribution. The lowest-priority-number record handles most incoming mail. If it is unavailable, senders fall back to higher-priority-number records. Having only a single MX record is a risk. If that server experiences downtime, sending servers queue mail and retry, but depending on their retry window and the outage duration, some email may eventually bounce. Major providers like Google Workspace and Microsoft 365 publish multiple MX records precisely to ensure no single point of failure for inbound email delivery.

How long do MX record changes take to propagate?

MX record changes propagate based on the TTL (Time to Live) value attached to the record. Most domains set MX TTLs between 300 seconds (5 minutes) and 3600 seconds (1 hour). After making a change, resolvers around the world continue using their cached copy until the TTL expires. Full global propagation typically takes 1-4 hours for short TTLs and up to 48 hours for long TTLs. Best practice when migrating email providers: lower the MX record TTL to 300 seconds 24-48 hours before making the change, complete the migration, then restore the TTL to a normal value once the new records are confirmed working.

What does it mean if a domain has no MX records?

If a domain has no MX records, most mail servers fall back to the domain's A record (its web server IP) to attempt delivery. This is called implicit MX delivery. Some stricter mail servers reject delivery entirely when no MX record exists. For domains that should never receive email, parked domains, subdomains used only for web services, legacy domains, the correct approach is to publish a null MX record (priority 0, exchange '.') which explicitly signals 'this domain accepts no email' and prevents fallback delivery attempts. This is a best-practice security measure: a domain with no MX and no null MX is an ambiguous target that some senders will still attempt to deliver to.

How do I check if my MX records are correct after migrating email providers?

Enter your domain in this tool and compare the results to the MX records your new provider told you to publish. For Google Workspace, you should see five records pointing to aspmx.l.google.com and the four ALT entries at priorities 1, 5, 5, 10, 10. For Microsoft 365, you should see a single record pointing to your-domain.mail.protection.outlook.com at priority 0. If the lookup returns your old provider's servers, DNS propagation is still in progress. Wait for the TTL to expire and check again. If it returns nothing, the MX records may not have been published correctly in your DNS provider's control panel.

What does a null MX record do and when should I use one?

A null MX record has priority 0 and an exchange value of '.' (a single dot). It explicitly tells sending mail servers that this domain does not accept email, preventing them from attempting delivery via the A record fallback. RFC 7505 formalised the null MX standard. Use it for: parked or inactive domains, domains used only for web or app services, internal-only DNS zones, and acquired or legacy domains that should no longer receive email. Publishing a null MX alongside SPF v=spf1 -all and DMARC p=reject fully locks down a non-sending domain against both inbound delivery attempts and outbound spoofing.

Can I use this tool to check MX records for any domain?

Yes. MX records are publicly queryable via DNS, which is by design. Any sending mail server in the world must be able to look up your MX records to deliver email to you. This tool queries exactly the same DNS data that any mail server would query when attempting delivery. You can use it to check your own domain, a provider's domain, a partner's domain, or any other domain on the internet. No authentication or permission is required to query public DNS records.

Why is my MX record lookup returning my old mail server after I changed providers?

DNS changes are not instantaneous. They propagate based on the TTL of the old record. If your previous MX record had a TTL of 3600 seconds (1 hour), resolvers around the world continue serving the old cached value for up to an hour after you made the change. This tool uses Cloudflare's and Google's DNS resolvers, which typically reflect changes within minutes once the TTL expires. If the lookup is still showing old records more than a few hours after your change, verify the new records are actually published in your DNS provider's control panel. Changes that were not saved, or records added at the wrong hostname, are common causes.

What is the difference between MX records and A records for email?

MX records explicitly specify which mail server handles inbound email for a domain. A records map a domain name to an IP address and are primarily for web traffic. They are separate systems. When a mail server tries to deliver email to example.com, it first looks for MX records. Only if no MX records are found does it fall back to using the A record IP. This fallback is increasingly unreliable. Many modern mail servers do not attempt A record delivery and simply reject to a domain with no MX. For any domain that receives email, explicit MX records are required. For domains that do not receive email, a null MX record explicitly signals this.

How does an MX record relate to SPF, DKIM, and DMARC?

MX records control inbound email. They tell the internet where to deliver messages sent to your domain. SPF, DKIM, and DMARC control outbound email authentication. They tell receiving servers how to verify that email claiming to come from your domain is genuine. These are complementary but separate systems. A domain needs correctly published MX records to receive email, and correctly published SPF, DKIM, and DMARC records to send authenticated email that is not filtered as spam. Checking your MX records with this tool and your authentication records with the Email Privacy Auditor or DMARC Checker together gives a complete picture of your domain's email configuration.

What are the correct MX records for Google Workspace?

Google Workspace requires five MX records published at your root domain: ASPMX.L.GOOGLE.COM at priority 1; ALT1.ASPMX.L.GOOGLE.COM and ALT2.ASPMX.L.GOOGLE.COM at priority 5 each; and ALT3.ASPMX.L.GOOGLE.COM and ALT4.ASPMX.L.GOOGLE.COM at priority 10 each. All five must be present for full redundancy. After publishing, use this tool to confirm all five are visible in DNS. Google also recommends removing any old provider's MX records simultaneously. Having both old and new records can cause split delivery during the transition period.

What are the correct MX records for Microsoft 365?

Microsoft 365 uses a single MX record per domain in the format: your-domain-com.mail.protection.outlook.com at priority 0 (where hyphens replace dots in the domain prefix). The exact record value is shown in the Microsoft 365 admin centre under Settings > Domains > your domain > DNS records. After publishing, use this tool to confirm the record is live. Microsoft 365 also uses two CNAME records for DKIM (selector1 and selector2) and recommends setting up SPF as v=spf1 include:spf.protection.outlook.com -all. None of which this MX lookup tool checks, but the DKIM Analyzer and SPF Record Checker cover those.

What causes an MX record lookup to fail or return an error?

Common causes of failed MX lookups: the domain does not exist in DNS (NXDOMAIN). Check spelling. The domain exists but has no MX records. The result will show empty rather than an error, and the domain may be intentionally configured not to receive email. A DNS propagation delay means newly published records are not yet visible globally. Try again after the TTL expires. A temporary DNS resolution error from Cloudflare or Google's resolvers. Rare but possible; retrying after a few seconds usually resolves this. If you get a persistent error for a domain you know receives email, check whether the domain is spelled correctly and whether your network has any DNS filtering that could interfere.

Does an MX record lookup reveal who hosts a domain's email?

Yes. The mail server hostnames in MX records typically identify the email provider. ASPMX.L.GOOGLE.COM indicates Google Workspace. mail.protection.outlook.com indicates Microsoft 365. mxroute.com indicates MXroute. Custom hostnames like mail.example.com indicate a self-hosted or privately branded mail server. This tool automatically identifies the most common providers from the MX exchange hostname. This information is completely public. Any mail server delivering email to your domain must look up these records, so they are inherently visible to anyone who queries DNS.

Technical background

MX records in context: how they fit with SPF, DKIM, DMARC, and the full email DNS picture

MX records are one part of a broader set of DNS records that together define a domain's email configuration. Understanding how each fits together is essential for correctly diagnosing delivery issues and configuring a new domain from scratch.

MX records (this tool) define inbound email delivery. Where to route messages sent to your domain. They are the only DNS record type specifically for receiving email. A domain without MX records cannot reliably receive email. A domain with a null MX explicitly refuses email.

SPF records define outbound sender authorisation. Which IP addresses and mail services are permitted to send email on behalf of your domain. Published as a TXT record at the root domain. Use the SPF Record Checker to validate your record and confirm the lookup count is within the RFC 7208 10-lookup limit. If the count is too high, the SPF Flattening Tool resolves all include chains to direct IP ranges.

DKIM records provide cryptographic signing of outgoing messages. Published as TXT records at selector._domainkey.yourdomain.com. They prove the message was sent by an authorised source and was not altered in transit. Use the DKIM Analyzer to look up any selector, check key strength, and detect revoked or test-mode keys.

DMARC records tie SPF and DKIM together with alignment enforcement and a reporting mechanism. Published at _dmarc.yourdomain.com. They specify the policy for authentication failures (none/quarantine/reject) and enable daily aggregate reports showing pass/fail rates from all sending sources. Use the DMARC Checker for a health summary or the DMARC Analyzer for a full tag-by-tag analysis.

For a complete one-pass audit of all five email DNS factors simultaneously, MX, SPF, DMARC, DKIM, and disposable domain status, use the Email Health Checker, which scores each check and assigns an A-F grade. For a security-focused risk score covering SPF, DMARC, DKIM, MX, and BIMI together, use the Email Privacy Auditor.

Related Email & DNS Tools

Need a disposable email address?Get a free instant throwaway email. No signup, no trace.

Get Free Temp Mail →