MX Lookup Tool
Look up MX (Mail Exchange) records for any domain. See mail server hostnames sorted by priority, resolved IP addresses, server reachability, and detected email provider — for diagnosing email delivery and verifying inbound mail routing.
MX Record Lookup
What are MX Records?
MX (Mail Exchange) records specify which mail servers are responsible for receiving email on behalf of a domain.
Each MX record has a priority value (lower numbers = higher priority). Mail servers attempt delivery starting with the lowest priority number.
Multiple MX records provide redundancy - if the primary server is down, email is delivered to backup servers.
Popular Domains
Understanding MX Priority
Highest priority mail servers. Email is delivered here first.
Backup mail servers. Used if primary servers are unavailable.
Additional backup servers or specialized routing.
Email Troubleshooting Tips
No MX Records Found
Domain is not configured to receive email, DNS records haven't propagated yet, or there's a DNS configuration error.
Server Unreachable
Mail server may be down temporarily, protected by a firewall, or the hostname doesn't resolve to a valid IP address.
Email Delivery Issues
Check that MX records point to correct servers, verify priority values are set appropriately, and ensure DNS propagation is complete (can take 24-48 hours).
Multiple Servers with Same Priority
This is normal and provides load balancing. Sending servers will randomly choose between servers with equal priority.
About MX Lookup Tool
The MX Lookup Tool fetches the Mail Exchange records for any domain — the DNS records that tell sending servers where to deliver inbound mail. Results show every MX server sorted by priority (lowest = preferred), the resolved IP addresses for each, basic reachability status, and automatic detection of common email providers (Google Workspace, Microsoft 365, Zoho, ProtonMail, etc.). Pairs with the SPF Checker, SMTP Test, and Trace Email tools for a complete email-infrastructure audit.
Why use a MX Lookup Tool?
MX records control where your inbound mail goes. A wrong priority order, missing record, or stale entry pointing at a long-decommissioned server is a common cause of 'why are emails to our domain bouncing?'. Use the tool to verify your MX is correct after a Google Workspace / Microsoft 365 migration, to identify which provider a vendor's domain uses (useful for support routing), or to diagnose why mail to a particular domain isn't being delivered.
Who is it for?
Email administrators verifying mail-server configuration, IT teams migrating between Google Workspace, Microsoft 365, and other providers, support engineers diagnosing 'we're not receiving emails' tickets, security analysts identifying who hosts a target domain's mail, and developers integrating with provider-specific email APIs (where knowing the MX provider helps choose the right SDK).
How to use the tool
Enter the domain (e.g., example.com — protocol/www/path are stripped automatically)
Click 'Lookup MX Records' to query DNS
Read the records sorted by priority — lowest number = first contacted
Check the IP column to verify the mail server is using expected infrastructure
Look at the reachability indicator (green = TCP port 25 reachable, red = unreachable)
Note the detected Email Provider banner if one matches (Google, Microsoft, etc.)
Copy individual records or export the full result as JSON for documentation
Key Features
Priority-sorted results
MX records are returned in priority order (lowest first), the order receiving servers actually use. Equal-priority records are highlighted to show round-robin / load-balancing setups.
IP resolution per server
Each MX hostname is resolved to its current A/AAAA records — useful for spotting MX servers pointing at decommissioned infrastructure.
Reachability check
Each MX server's TCP port 25 is probed to confirm the mail server is actually accepting connections. Catches the case where the MX hostname resolves but the server is firewalled or down.
Email provider detection
Recognizes 6+ major providers (Google Workspace, Microsoft 365, Zoho, ProtonMail, Amazon SES, Cloudflare) by their characteristic MX hostnames — useful for support routing and choosing provider-specific tooling.
URL normalization
Paste a URL with protocol, www, port, or path — the tool strips everything down to the bare domain before querying.
JSON export
Download the complete result as JSON to attach to runbooks, tickets, or DNS-change documentation.
Common Use Cases
Verifying a Google Workspace / Microsoft 365 migration
Scenario: You just migrated email from one provider to another and need to confirm the new MX records are live and correctly prioritized.
✓ One lookup confirms all 5 Google MX records (or 1-2 Microsoft records) are present, in the right priority order, and reachable. Catches the common 'forgot to remove old MX' mistake which causes intermittent dual-delivery.
Diagnosing 'we're not receiving emails from a vendor'
Scenario: A vendor is sending you mail that isn't arriving. You suspect MX is wrong on your side.
✓ Look up your domain — confirm MX is correct, reachable, and pointing where it should. If everything looks right, the problem is downstream (anti-spam, mailbox routing) and you can focus the investigation there.
Identifying a vendor's email provider for support routing
Scenario: You're supporting a customer whose email address is at acme.example.com and need to know if they're on Google Workspace, Microsoft 365, or self-hosted.
✓ Provider detection tells you instantly. Determines which support article to send them, which API quirks to expect, which MX-format examples are relevant.
Auditing a domain's email infrastructure as part of a security review
Scenario: Security review of a vendor or acquired domain — you want to know what mail providers they're using and whether MX records are sane.
✓ Quick visual on infrastructure ownership, plus JSON export for the audit artifact. Combine with SPF Checker results for the full email-auth picture.
Pre-cutover validation for new email setup
Scenario: You're about to flip MX from old provider to new. Want to confirm the new records are correct and reachable BEFORE making the change.
✓ Run the check against both the old and new providers. Once you cut over, re-check to confirm propagation. Avoids the panic of 'we cut over and now nothing works.'
Standard DNS MX query — matches what real sending mail servers will see when they look up your domain.
The DNS lookup runs server-side through our edge proxy. The domain is queried but not stored. No cookies, no analytics on input content.
Globally distributed edge infrastructure for low-latency queries.
Frequently Asked Questions
What does MX priority mean?
Lower number = higher preference. Sending mail servers try the lowest-priority MX first; if it's unreachable they fall back to the next. Multiple servers at the same priority distribute load. Typical setups use priorities like 10, 20, 30 for primary/secondary/tertiary, or several at priority 10 for round-robin.
Why does Google Workspace return 5 MX records?
Google publishes 5 MX servers (at priorities 1, 5, 5, 10, 10) for redundancy across their infrastructure. All are valid; the priority structure ensures Smartest mail flow under load. If you're missing any of the 5, your migration setup is incomplete.
What does 'unreachable' mean for an MX record?
The MX hostname resolves but TCP port 25 isn't accepting connections from the worker's network. Could mean: the server is down, behind a firewall, behind a strict greylist, or the IP is on a major blocklist that's hard-rejecting. Worth investigating but doesn't always mean the server is broken (some providers rate-limit aggressively).
Can I have a domain without MX records?
Yes — and it's appropriate when the domain doesn't receive mail. If you don't want anyone to be able to email `noreply.example.com`, publish a 'null MX' record (`. 0`) to explicitly say so. Receiving servers will reject mail to that domain rather than retrying. More secure than just leaving MX blank.
Why do I see two MX records that look almost identical?
Common with Google Workspace (multiple ALT MX servers at priority 5) and Microsoft 365 (geographic redundancy). Both are healthy. Worth checking that the priorities and hostnames match the provider's published MX setup exactly.
Does this tool see my email or mail content?
No. It only queries DNS for MX records and probes TCP port 25 reachability. No SMTP commands are sent, no message data is exchanged. The DNS lookup runs server-side through our edge proxy, which sees the domain you queried but doesn't store it.
Why doesn't reachability show for my server?
Some providers block port 25 inbound from arbitrary networks (anti-spam policy). Reachability failing isn't a guarantee of brokenness — it might just be that the worker's IP is on the provider's allowlist requirement. The presence of MX records and correct hostnames is the more important signal.
How does MX relate to SPF, DKIM, DMARC?
MX controls inbound mail (where mail sent TO your domain goes). SPF, DKIM, DMARC control outbound authentication (how receivers verify mail FROM your domain). They're independent — but a complete email setup needs all of them correctly configured. Use this tool plus the SPF Checker, Trace Email, and SMTP Test for the full picture.
Technical Specifications
Supported Formats
- ✓MX record lookup via DNS
- ✓A/AAAA resolution for each MX hostname
- ✓TCP port 25 reachability probe
- ✓Provider detection: Google Workspace, Microsoft 365, Zoho, ProtonMail, Amazon SES, Cloudflare
- ✓URL normalization (strips protocol, www, port, path)
- ✓JSON export
Limits & Performance
- •File Size: Single domain per check
- •Validations: Live DNS + TCP probe
- •Response Time: Typically 300-2000ms depending on number of MX servers
- •Browsers: All modern browsers
Pro Tips
- After any MX change, re-check from multiple geographic regions. DNS propagation isn't instant — different recursive resolvers may have stale records for hours.
- If migrating providers, set up the new provider's MX BEFORE removing the old one. Then lower the old MX's priority (e.g., from 10 to 30) so new mail goes to the new provider while old mail still gets accepted.
- Publish a 'null MX' (`. 0`) on subdomains that don't receive email (e.g., www, api, static). Prevents bounce-backs from spam targeting these subdomains.
- Document your MX setup in a runbook. After a year, no one remembers why MX 5 points where it does.
- When investigating delivery problems, run MX Lookup → SPF Checker → Trace Email in that order. MX confirms inbound is right; SPF confirms outbound is authorized; Trace Email confirms a specific message's path.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.