Free MX Record Checker
Look up the live MX records for any domain. Instantly see which mail servers are configured to receive email and verify your setup is correct.
How to Use This Tool
Enter the domain
Type the domain you want to check — for example, mailtani.com. The tool queries live DNS so you always see the current records.
Review the MX records
All MX records are listed in priority order. Lower priority numbers are tried first. Verify the hosts match your email provider's expected values.
Fix any issues
Missing MX records mean the domain cannot receive email. Wrong hosts mean mail is routed to the wrong server. Update your DNS if anything looks incorrect.
What MX Records Are and How Email Routing Works
Mail Exchanger (MX) records are DNS records that specify which mail servers are responsible for accepting inbound email on behalf of a domain. When someone sends an email to [email protected], the sending mail server performs a DNS MX lookup for yourdomain.com to find out where to deliver the message. The MX record returns one or more mail server hostnames, each with a priority value. The sending server tries the lowest-priority number first; if that server is unavailable, it tries the next, enabling built-in redundancy.
Without correctly configured MX records, a domain cannot receive email at all. If no MX record exists, the sending server may fall back to looking up the domain's A record and attempting delivery there — a behaviour described in RFC 5321 but rarely reliable in modern infrastructure. In practice, a missing MX record means inbound email to that domain is lost or bounced. This is the most fundamental DNS configuration for any email-receiving domain, predating SPF, DKIM, and DMARC.
MX records are separate from the records that control outbound email authentication. SPF covers which servers can send from your domain; MX records control where inbound email is delivered. They are independent: you can configure perfect outbound authentication while having misconfigured MX records, and vice versa. When troubleshooting email flow issues, checking MX records is the first diagnostic step because they govern whether the domain can receive mail at all.
Reading MX Record Priority and Understanding Redundancy
Each MX record has a priority value — an integer that determines the order in which sending servers attempt delivery. Lower numbers represent higher priority and are tried first. A domain with a single MX record at priority 10 means all inbound mail goes to that server. A domain with records at priority 10 and priority 20 means mail goes to the first server, with the second as a fallback if the first is unavailable.
When two MX records share the same priority value, sending servers can deliver to either one in random order — this is used for load balancing across equally capable mail servers. Most modern email providers (Google Workspace, Microsoft 365, Zoho) publish multiple MX records at different priorities to ensure redundancy. Google Workspace, for example, publishes five MX records ranging from priority 1 to priority 10, all pointing to different aspmx.l.google.com hosts.
A common misconfiguration is publishing MX records that point to a hostname that itself does not exist or lacks an A record. This causes delivery failures even though the MX record exists: sending servers find the MX record but cannot resolve the mail server hostname. Another common mistake is pointing MX records directly to an IP address rather than a hostname — RFC 2181 explicitly prohibits this and compliant mail servers will refuse to use such records.
MX Records in Context: Sending vs Receiving Infrastructure
Many teams confuse MX records with the records that control outbound email sending. SPF records declare which servers can send email on your behalf. DKIM records publish cryptographic keys for signing outgoing messages. DMARC records set policy for authentication failures. None of these affect where inbound email is delivered — that is the exclusive job of MX records.
This confusion becomes practically significant when migrating email providers. If you move from Google Workspace to Microsoft 365 for receiving email, updating your MX records is how you redirect inbound mail to the new servers. Until the MX records are updated and DNS changes propagate, new email continues arriving at the old servers. During migration, many teams run both old and new MX records simultaneously at different priorities to allow the new infrastructure to receive test messages while the old system remains the primary — a practice called dual routing or soft cutover.
For domains that only send email and never receive it — such as transactional email subdomains or sending-only infrastructure domains — MX records are still worth publishing, but they can point to a null MX record (`0 .` as specified in RFC 7505). This tells sending servers not to attempt delivery to the domain, which is more explicit than having no MX record and prevents the A-record fallback behaviour.
Diagnosing Delivery Problems with MX Lookups
MX lookups are a first-response diagnostic tool when inbound email is failing or delayed. If recipients are reporting that emails sent to your domain are bouncing, the MX lookup reveals whether records exist at all. If they exist, the next question is whether the listed hostnames are correct for your current email provider and whether those hostnames are resolvable.
DNS propagation affects MX records just as it affects all other DNS records. After changing MX records, the old records remain cached in resolvers worldwide for the duration of the previous TTL value. During this window, some sending servers will deliver to the old mail servers while others deliver to the new ones — causing split delivery. Reducing the TTL of your MX records to a low value (300 seconds) before a planned migration gives you faster propagation and a shorter split-delivery window.
For shared hosting and managed email providers, MX records are often set automatically by the hosting control panel or domain registrar. These auto-configured records can be overwritten accidentally if someone edits DNS records without understanding the consequence, causing sudden inbound email failure with no obvious trigger. If email stops arriving without any deliberate change on your part, checking MX records is the right first step before investigating more complex causes.
Key Features
Live DNS Query
Queries authoritative DNS in real time to return the current published MX records, not cached data.
Priority-Sorted Results
Displays all MX records sorted by priority so you immediately see which server handles mail first.
Hostname Resolution Check
Verifies that each MX hostname resolves to an IP, catching the common misconfiguration of unresolvable mail server names.
Null MX Detection
Identifies domains publishing RFC 7505 null MX records and explains what that means for delivery.
Provider Identification
Recognises common MX hostnames from Google Workspace, Microsoft 365, and major ESPs.
Propagation Guidance
Explains TTL values and how long to expect before MX record changes take full effect globally.
Frequently Asked Questions
Related Tools
Continue your email deliverability setup with these free tools.
Tools Are Just the Start
Once your domain is set up, mailtani handles sending, warmup, sequences, and rotation.
See How mailtani Compares
Full Email Infrastructure in One Place
mailtani handles SPF, DKIM, DMARC, and deliverability monitoring so your email infrastructure stays healthy without manual DNS checks.
- DNS monitoring across all your domains
- Deliverability alerts
- Inbox warmup & rotation
- One-time price
14-day free trial · €89 lifetime access after