MX Record Lookup
Check MX records to verify email routing for any domain.
MX Record Lookup
Find mail exchanger records and verify email routing for any domain.
About MX Record Lookup
MX Record Lookup Tool for Email DNS Routing
Mail delivery depends on DNS. When a sender tries to deliver email to a domain, it first asks the Domain Name System which mail servers should receive the message. Those servers are listed in MX (Mail Exchanger) records, and a single mistake—an outdated host, the wrong priority, or a missing record—can cause bounces, delays, or silent delivery failures.
This MX Record Lookup tool helps you inspect and validate MX records for one or many domains in seconds. Use it to confirm that your domain’s mail routing matches your provider’s instructions, to troubleshoot “MX lookup failed” errors, or to verify changes after you update DNS at your registrar. It is equally useful for a quick one-off check and for ongoing audits where you periodically confirm that every domain still points to the intended inbound mail platform.
How It Works
Enter one or more domains, then run the lookup. The tool queries DNS for MX records and returns each mail server target along with its priority (lower numbers are preferred). If TTL (time to live) is available from the resolver, you can include it to understand how quickly changes should propagate and how long cached results may persist across the internet.
Behind the scenes, the lookup requests the MX record set for each domain and organizes the response into a consistent structure. This makes it easier to compare domains, spot missing records, and share results with teammates. If a domain is entered with extra characters (such as a URL scheme or path), the input is normalized to a hostname before the DNS query is performed.
Step-by-step
- 1) Provide domains: Paste one domain per line (for example, example.com). You can include internationalized domains; they will be normalized for lookup.
- 2) Choose an output format: Get a readable report for quick review or JSON for audits, documentation, and change tickets.
- 3) Run the lookup: The tool requests MX data from DNS and normalizes the output into a stable, comparable layout.
- 4) Review priority and targets: Check that targets match your email provider, that priorities are set as intended, and that there are no unexpected legacy servers.
- 5) Export results: Copy the report to your clipboard or download it for sharing with your IT team, a client, or your registrar support.
Because DNS is distributed, it is normal to re-check after changes. If you recently updated MX records and still see the old set, the result may be cached. TTL and propagation planning are covered later in the optimization section.
Key Features
Multi-domain lookups
Audit multiple domains in one run. This is handy for agencies, MSPs, and organizations managing many brands, subprojects, or regional domains. Instead of checking records one by one, paste a list and compare the results quickly. You can also keep a standard “audit list” and run it whenever you complete a migration or onboarding.
Bulk checks are especially helpful after a nameserver change. It is easy to accidentally omit a record when copying zone data, and MX is one of the records that can break critical business workflows if it is missing. A quick multi-domain run can reveal gaps before users notice mail delivery issues.
Priority-aware presentation
MX records are ordered by priority, where a lower number indicates a higher preference. The report makes it easy to confirm that your primary mail servers appear at the right priority and that backup servers are listed as expected. This matters for resilience: if the preferred target is down, senders will attempt the next-best option.
Priority is also a common source of subtle misconfiguration. For example, if a “backup” gateway is assigned a lower number than your primary provider, inbound traffic may go to the wrong place. The tool surfaces the order clearly so you can correct priorities and avoid unexpected routing.
Optional TTL visibility
TTL values influence how long resolvers cache DNS responses. When you are migrating email providers or correcting records, TTL helps you estimate how quickly the world will see the update. The tool can include TTL when available so you can plan change windows more confidently.
TTL is also useful in incident response. If you need to fail over inbound mail to a temporary service, knowing the effective caching period helps you set expectations with stakeholders. In practice, some resolvers may retain records longer than TTL, but TTL remains the most actionable signal for planning.
Readable report and JSON export
Different workflows require different formats. A readable report is perfect for quick troubleshooting, while JSON is useful for change management tickets, internal documentation, or automated checks where you store snapshots of DNS states.
JSON export also makes it easier to integrate results into your internal playbooks. For example, you might keep a baseline of expected MX targets and compare it against a new snapshot during an email provider migration or security review.
Safe, focused interface
The tool uses server-side DNS functions to retrieve records and then renders the output in a clean, copyable format. No external scripts, trackers, or third-party widgets are required in the interface, keeping the experience fast and focused. The output can be shared without exposing sensitive content, since MX records are public by design.
For additional clarity, the interface separates a human-readable summary from the structured per-domain breakdown. This helps you quickly identify which domains are correctly configured and which need attention, without losing the details needed for remediation.
Use Cases
- Verify email provider setup: Confirm MX targets after configuring Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, or a hosted mail gateway.
- Check inbound security gateways: Validate that domains route through Proofpoint, Mimecast, Barracuda, or similar filtering services before reaching the mailbox provider.
- Troubleshoot bounces and delivery errors: Identify missing or mis-typed MX records when mail is rejected with DNS-related messages, or when senders report intermittent failures.
- Audit after registrar or DNS provider changes: When moving nameservers, ensure MX records were copied correctly and no legacy records remain.
- Validate multi-tenant hosting environments: If you operate a mail platform for customers, verify that each customer domain points to the correct cluster and priority layout.
- Confirm cutover readiness: Before flipping traffic during a migration, confirm the new MX set is published and consistent across your domains.
- Investigate suspicious routing: Detect unexpected MX targets that could indicate outdated services, shadow IT, or a misconfiguration introduced by a compromised DNS account.
- Document configurations: Capture a JSON snapshot for tickets, compliance, runbooks, or handover documentation.
Whether you are running a single domain or managing a portfolio, an MX lookup is often the first diagnostic step when email “just stops working.” A quick check can save hours of guesswork. It is also a valuable companion to deliverability reviews: while authentication records like SPF and DMARC matter for outbound mail, inbound routing starts with MX.
For teams with change management processes, it is common to attach DNS evidence to a ticket. A clear MX report helps reviewers confirm that the change matches the plan, and it makes it easier to roll back if a provider cutover needs to be postponed.
Optimization Tips
Match MX targets to your provider’s documentation
Mail providers publish exact MX targets to use. Compare the returned targets to your provider’s recommended list and check for typos, missing dots, or deprecated hosts. If you see unexpected domains or legacy servers, remove or update them to prevent routing issues.
Be cautious when mixing providers. Having MX records for multiple mail systems can cause unpredictable routing, especially if priorities overlap or if one provider treats certain responses differently. Unless you intentionally run a staged migration, keep MX targets aligned to a single inbound routing design.
Use priorities intentionally
Set priorities so that your preferred, healthiest servers are tried first. A common pattern is multiple equal-priority records for load distribution plus a higher-number backup. If you have only one MX record, consider whether a secondary is needed for redundancy.
Also confirm that your “backup” target is actually reachable and configured to accept mail for the domain. A backup MX that rejects mail or lacks the correct recipient configuration may cause senders to queue mail for hours and then bounce it. A good backup strategy includes monitoring, testing, and clear ownership.
Plan changes around TTL and propagation
Before a migration, lower the TTL ahead of time (for example, 24–48 hours) so caches expire faster during the switchover. After the migration is stable, you can raise TTL again to reduce resolver load. This reduces the “split brain” period where some senders see old records and others see new ones.
When you are troubleshooting, remember that different networks may cache differently. If you suspect caching, check from multiple environments (office, mobile, VPN) or wait for TTL to expire before concluding that a record change did not apply. Keeping a short-lived TTL temporarily is a standard technique for safer change windows.
FAQ
An MX record tells other mail servers where to deliver email for your domain. It lists one or more mail exchanger hostnames plus a priority value. If MX records are missing or wrong, senders may not be able to find your mail servers, leading to bounces or failed delivery attempts.
MX records control inbound routing only. They do not directly authenticate email or improve sender reputation, but they are foundational: if inbound routing is wrong, mail will never reach your mailbox provider to be processed. That is why MX is typically the first record type you confirm during troubleshooting.
Lower numbers indicate higher priority. A sender will try the lowest-priority MX first. If it cannot deliver, it will attempt the next one. Multiple records can share the same priority, which allows senders to spread delivery attempts across them.
Because delivery behavior can vary by sending system, you should keep priorities simple and intentional. If you want a true backup, assign it a higher number than all primary targets. If you want equal preference, use the same number across those targets.
If no MX records exist, many senders fall back to the domain’s A/AAAA record for delivery, but that is not always desirable and may fail depending on your setup. For hosted email services, you typically must publish the correct MX records. If you recently changed DNS, the issue may also be propagation or caching.
Some domains intentionally omit MX if they do not accept email. In that case, removing MX can be a valid signal, but only if your organization truly does not need inbound mail. Otherwise, ensure you publish the MX set your provider requires and that the mail servers are reachable on the relevant ports.
Propagation depends on caching and TTL. Some resolvers refresh quickly, while others cache until TTL expiry. In practice, you may see a transition period where different senders observe different results. Lowering TTL before a planned change can reduce this window.
Keep in mind that email systems may retry delivery over time if a destination is unreachable. Even after DNS propagates, queued messages may continue attempting old routes until they retry and fetch new DNS answers. Patience and monitoring are often required during major cutovers.
MX records only route mail. For modern deliverability, also verify SPF, DKIM, and DMARC records, ensure reverse DNS and TLS are configured for your sending infrastructure, and monitor provider dashboards for authentication and reputation signals.
If you run inbound gateways, review acceptance rules, spam filtering policies, and mailbox quotas. Many “delivery” problems are actually policy blocks, full mailboxes, or filtering changes—so pairing an MX check with provider logs gives the fastest diagnosis.
Why Choose This Tool
Email is one of the most business-critical systems, yet DNS misconfigurations are common—especially during migrations, rebrands, and registrar changes. A fast MX lookup gives you immediate clarity about where mail should be delivered and whether the published configuration matches your expectations. It also helps you catch configuration drift over time, such as leftover records from a past provider or experimental routing changes that were never cleaned up.
This tool is designed to be practical: it supports multiple domains, provides a copyable report, and includes export options for tickets and audits. Use it as your first step when diagnosing mail flow issues, validating new setups, and keeping DNS documentation accurate over time. When combined with checks for SPF, DKIM, and DMARC, it becomes part of a reliable routine for maintaining healthy email infrastructure.