What is an MX record?

An MX (Mail Exchange) record is a DNS record, defined in RFC 5321, that tells the internet which mail servers accept email for a domain. Each MX record has two parts: a priority value (a 16-bit unsigned integer) and a hostname pointing to the mail server. When someone sends email to your domain, the sending mail transfer agent (MTA) queries DNS for your MX records, sorts them by priority (lowest number = highest preference), and tries SMTP delivery to each server in order until one accepts. A domain with MX records at priorities 10 and 20 gets mail delivered primarily to the priority-10 server, with the priority-20 server as backup. This is how email redundancy works. If the primary server is offline or unreachable, delivery automatically fails over to backup servers rather than bouncing the message.

What does the MX priority number mean?

MX priority (also called preference value) determines the order in which sending servers attempt delivery, as defined in RFC 5321 Section 5. Lower numbers mean higher preference. A server at priority 10 is always tried before one at priority 20. If the highest-preference server is unreachable or returns a temporary error, the sending MTA falls back to the next level. When multiple MX records share the same priority, RFC 5321 says senders should distribute messages across them using random selection, which gives you round-robin load balancing. Common setups include 10/20 for primary and backup, 1/5/10 for three-tier failover, and 10/10 for equal load distribution between two servers. Google Workspace uses five MX records at priorities 1, 5, 5, 10, and 10 to spread load across its mail infrastructure.

What is a Null MX record?

A Null MX record, defined in RFC 7505, is a special MX record with priority 0 and a single dot (.) as the hostname. It explicitly declares that a domain does not accept email. This is the proper way to say "no email here," as opposed to just omitting MX records entirely. Without a Null MX, the fallback behavior in RFC 5321 Section 5.1 kicks in, where senders try delivering to the domain's A or AAAA address instead. Null MX is useful for domains used exclusively for web hosting, API services, CDN endpoints, or brand protection. When compliant senders encounter a Null MX, they immediately generate a bounce without attempting delivery. This cuts down on unnecessary SMTP connection attempts, queue processing, and network traffic. To set it up, add a single DNS record with MX priority 0 and the exchange hostname set to a literal dot.

Why does reverse DNS (PTR) matter for email?

Reverse DNS maps an IP address back to a hostname using PTR records in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones. RFC 5321 Section 4.1.3 says SMTP servers SHOULD verify that the hostname in the EHLO command resolves to the connecting IP. This check is called Forward-Confirmed reverse DNS (FCrDNS): the PTR record for an IP returns a hostname, and that hostname's A or AAAA record resolves back to the same IP. Gmail, Outlook, and Yahoo all perform FCrDNS checks as part of spam filtering. Mail from servers with missing PTR records, mismatched hostnames, or generic ISP-assigned reverse DNS (like pool-192-168-1-1.isp.example) frequently gets rejected or sent to spam. If your MX server results in this tool show a PTR mismatch, contact your hosting provider to set the correct reverse DNS record for your mail server's IP.

Why can't MX records point to a CNAME?

RFC 2181 Section 10.3 explicitly prohibits this, and RFC 5321 reinforces the restriction. When an MX target is a CNAME instead of a direct A or AAAA record, the DNS resolver has to chase the CNAME chain before finding the actual IP. Some modern resolvers handle this transparently, but others may fail, timeout, or return unexpected results. The outcome is intermittent, hard-to-diagnose email delivery failures. Things get worse when CNAME chains are multiple levels deep or when the target sits in a different DNS zone with its own TTL and availability characteristics. The fix is simple: always point MX records directly at hostnames that have A and/or AAAA records. Use mail.example.com as your MX target and make sure it has a direct A record rather than being a CNAME alias for another hostname.

How does this tool detect the email provider?

MX hostnames are matched against a curated database of known mail server patterns for over 30 providers. Hostnames ending in aspmx.l.google.com or alt.aspmx.l.google.com indicate Google Workspace. The pattern *.mail.protection.outlook.com identifies Microsoft 365. Records ending in .pphosted.com mean Proofpoint, while *.mimecast.com means Mimecast. Coverage includes enterprise security gateways (Barracuda, Cisco Email Security, Forcepoint), hosted email services (Zoho Mail, ProtonMail, Fastmail, Apple iCloud Mail, Rackspace), and transactional platforms (Amazon SES, SendGrid, Mailgun, Postmark, SparkPost). Knowing the provider is useful for troubleshooting delivery issues, understanding a competitor's email setup, verifying a migration went through, or figuring out which security gateway protects a domain. When a provider is detected, the name appears next to each MX record in the results.

What happens if a domain has no MX records?

RFC 5321 Section 5.1 defines a fallback: the sending server looks up the domain's A record (and AAAA for IPv6) and tries SMTP delivery directly to those IPs, treating them as implicit mail servers with equal priority. This fallback is unreliable for several reasons. The IP might host a web server with no SMTP service, causing immediate connection refusal. There is no priority-based failover between multiple addresses. The web server IP could be behind a CDN or load balancer that does not forward SMTP traffic. Anti-spam systems may also penalize mail delivered to implicit MX targets. Every domain should either have explicit MX records pointing to properly configured mail servers, or publish a Null MX record as defined in RFC 7505 (priority 0 with a dot as the hostname) to explicitly reject email. Null MX is strongly preferred over just leaving MX records absent.

Should I have multiple MX records?

Yes. Multiple MX records with different priorities give you automatic email failover. RFC 5321 Section 5 requires sending servers to try all listed MX hosts in priority order before giving up, so backup records kick in automatically when the primary is down for maintenance, hardware failure, or network issues. With only one MX record, any downtime causes senders to queue messages and retry for up to 5 days (the typical limit), potentially losing time-sensitive communications. For best results, backup MX servers should be on different physical networks, in different data centers, and ideally with different providers. This protects against network-level outages, DDoS attacks, and provider-specific incidents. A common setup is a primary at priority 10 and secondary at priority 20. Google Workspace and Microsoft 365 both use multiple MX records across geographically distributed infrastructure for exactly this reason.

MX Record Lookup

Find mail servers for any domain. Detect email providers, verify reverse DNS, check priority routing, and identify misconfigurations that affect email delivery.

“MX records are the postal address of email. If they're wrong, your mail goes nowhere.”

Written by Ishan Karunaratne · Last reviewed: March 11, 2026

What Are MX Records?

MX (Mail Exchange) records are DNS resource records defined in RFC 5321 Section 5 that direct email delivery for a domain. When someone emails [email protected], the sending server performs a DNS query for the MX records of example.com to determine which mail servers should receive the message.

Each MX record consists of two parts: a priority (preference value) and a hostname pointing to the mail server. Lower priority numbers indicate higher preference — a server with priority 10 is tried before one with priority 20. This mechanism provides built-in failover for email delivery.

If no MX records exist, RFC 5321 Section 5.1 specifies that the sending server falls back to the domain's A or AAAA records. However, this fallback is unreliable and not recommended — every domain that handles email should have explicit MX records configured. For a broader view of all DNS records, use the full DNS record lookup.

How Do MX Priority and Failover Work?

MX priority values control the order in which sending servers attempt delivery, as specified in RFC 5321 Section 5. The algorithm works as follows:

Try the lowest priority first

The sending server connects to the MX host with the lowest priority number (e.g., priority 10).

Failover on failure

If the primary server is unreachable, the sender tries the next priority level (e.g., priority 20).

Equal priorities = round-robin

When multiple MX records share the same priority, mail is distributed across them for load balancing.

How Does Email Provider Detection Work?

This tool automatically identifies the email provider behind a domain's MX records by matching hostnames against known patterns. Knowing which provider handles a domain's email is useful for troubleshooting delivery issues, understanding a competitor's email stack, or verifying a migration was successful.

Google Workspace

*.google.com

Microsoft 365

*.protection.outlook.com

Proofpoint

*.pphosted.com

Mimecast

*.mimecast.com

Barracuda

*.barracudanetworks.com

Zoho Mail

*.zoho.com

The tool detects 30+ providers including Amazon SES, SendGrid, Mailgun, Postmark, ProtonMail, Fastmail, Apple iCloud, and more.

Why Does Reverse DNS Matter for Email Deliverability?

For each MX server, this tool resolves the IP address and performs a PTR (reverse DNS) lookup. Forward-Confirmed reverse DNS (FCrDNS) — where the PTR hostname resolves back to the same IP — is a key requirement for email deliverability as outlined in RFC 5321 Section 4.1.3.

Major email providers like Gmail, Outlook, and Yahoo check PTR records as part of their spam filtering. A mismatch between the sending hostname and its reverse DNS can cause emails to be rejected or sent to spam. If you see a PTR mismatch in your results, contact your hosting provider to set the correct PTR record on your server's IP address. After fixing PTR records, test email deliverability to confirm messages reach the inbox.

What Are Common MX Misconfigurations?

CNAME on MX

RFC 2181 Section 10.3 prohibits MX records from pointing to CNAME aliases. This can cause intermittent delivery failures depending on the resolver. Always use direct A/AAAA hostnames.

Missing PTR Records

Per RFC 5321 Section 4.1.3, receiving servers should verify reverse DNS. Missing or mismatched PTR records are a leading cause of email being flagged as spam.

Single Point of Failure

Having only one MX record means no failover. RFC 5321 Section 5 recommends multiple MX records with different priorities on separate networks for redundancy.

Duplicate IPs

Multiple MX records resolving to the same IP address provides no real redundancy. Each MX should point to a distinct server, ideally on different networks.

Which RFCs Define MX Record Behavior?

RFC 5321

Simple Mail Transfer Protocol

The core SMTP specification. Defines MX record lookup behavior, priority-based failover, and mail routing (Section 5).

RFC 7505

A "Null MX" No Service Resource Record

Defines the Null MX record (priority 0, exchange ".") for domains that explicitly do not accept email.

RFC 2181

Clarifications to the DNS Specification

Section 10.3 prohibits MX records from pointing to CNAME aliases. MX targets must resolve directly to A/AAAA records.

RFC 974

Mail Routing and the Domain System

The original RFC that introduced MX records to replace the older mail routing mechanism. Superseded by RFC 5321 but historically significant.

What Other Email Tools Are Available?

MX records are just one part of email configuration. For a complete email health check, also verify your authentication records:

•SPF Checker — Validate which servers are authorized to send email for your domain (RFC 7208)
•DKIM Checker — Verify your email signing keys and BIMI brand indicators (RFC 6376)
•DMARC Checker — Analyze your email policy and reporting configuration (RFC 7489)
•SMTP Diagnostics — Test mail server connectivity, TLS support, and open relay status

Need this in code?

Every check this tool runs is also available via the MX records API with examples in cURL, JavaScript, Python, PHP, Ruby, and Java.

API docs

Built and maintained alongside this tool. Free, no signup required.

Check SPF recordValidate sender authorization for outbound email.DKIM record checkVerify cryptographic signature alignment.DMARC policy checkConfirm reject/quarantine/none enforcement.SMTP diagnosticsLive SMTP handshake test against the MX target.