Find mail servers for any domain. Detect email providers, verify reverse DNS, check priority routing, and identify misconfigurations that affect email delivery.
Written by Ishan Karunaratne · Last reviewed:
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.
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.
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.com*.protection.outlook.com*.pphosted.com*.mimecast.com*.barracudanetworks.com*.zoho.comThe tool detects 30+ providers including Amazon SES, SendGrid, Mailgun, Postmark, ProtonMail, Fastmail, Apple iCloud, and more.
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.
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.
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.
Having only one MX record means no failover. RFC 5321 Section 5 recommends multiple MX records with different priorities on separate networks for redundancy.
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.
Simple Mail Transfer Protocol
The core SMTP specification. Defines MX record lookup behavior, priority-based failover, and mail routing (Section 5).
A "Null MX" No Service Resource Record
Defines the Null MX record (priority 0, exchange ".") for domains that explicitly do not accept email.
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.
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.
MX records are just one part of email configuration. For a complete email health check, also verify your authentication records: