Ready to Analyze
Enter a domain to perform a deep recursive DNS lookup and RFC compliance check.
MX Record Lookup
Enterprise-grade DNS diagnostic tool. Deep analysis of Mail Exchange records, RFC compliance validation, provider fingerprinting, and deliverability scoring.
Notification
About
In the architecture of the modern internet, the Mail Exchange (MX) record is the cornerstone of email delivery. It serves as the bridge between the Domain Name System (DNS) and the Simple Mail Transfer Protocol (SMTP). Without a correctly configured MX record, an organization ceases to exist in the context of digital communication.
This is not a simple lookup tool; it is a diagnostic engine. While standard tools merely echo the DNS response, this utility performs a Deep Heuristic Analysis. It validates configurations against RFC 5321 and RFC 2181 standards, checks for critical security gaps, and identifies the underlying infrastructure provider (e.g., Google Workspace, Microsoft Exchange, Proofpoint).
Core diagnostic capabilities include:
- Priority Logic Verification: Ensures failover mechanisms are mathematically sound.
- CNAME Chaining Detection: Identifies illegal alias pointers that cause delivery loops.
- TTL Optimization Analysis: Evaluates Time-To-Live values for caching efficiency.
- Provider Fingerprinting: Instantly recognizes over 50+ email hosting and security providers.
Designed for Network Engineers, DevOps Professionals, and Email Marketers who demand absolute precision in their infrastructure data.
dns
mx records
smtp
email deliverability
sysadmin
network tools
rfc compliance
Formulas
The reliability of email delivery D can be modeled as a function of record availability and configuration validity. The selection of the target server T follows the strict comparison of 16-bit priority integers P:
Tselected = argminr ∈ R ( r.P )
Where R is the set of all returned MX records. If multiple records share the minimum priority, the Traffic Probability prob for a specific server S in a subset of size N is:
prob(S) = 1N
RFC 2181 strictly forbids an MX record from pointing to a CNAME. The resolution chain must be:
Domain → MX Record → A / AAAA Record → IP Address
Reference Data
| Infrastructure Type | Provider Signature | Priority Strategy (P) | RFC Compliance Note |
|---|---|---|---|
| Cloud Productivity | Google Workspace | 1, 5, 10 | Strict tiering. 1 is master, others are varying failovers. |
| Enterprise Exchange | Microsoft 365 | 0 (Single) | Uses a single high-priority endpoint; load balancing is internal. |
| Security Gateway | Mimecast | 10, 10 | Often uses equal priority for Round-Robin load balancing. |
| Security Gateway | Barracuda | Region Dependent | Acts as a filter before reaching the destination server. |
| Transactional | SendGrid | 10 | Typically handles inbound parsing for apps. |
| Encrypted Mail | ProtonMail | 10, 20 | Requires specific DNSSEC configuration for full security. |
| Hosting Provider | GoDaddy / cPanel | 0 | Often points to mail.domain.com (self-hosted). |
| Hybrid / Legacy | Exchange On-Prem | Custom | Managed manually by SysAdmins. Prone to config errors. |
Frequently Asked Questions
A "Null MX" record is a specific configuration defined in RFC 7505. It contains a single MX record with priority 0 and a target of . (dot). This explicitly signals to the world that "this domain sends no email and accepts no email". It is a powerful security measure for defensive domains to prevent spoofing.
It doesn't "failover" arbitrarily. The sending MTA will only attempt priority 10 if the connection to priority 0 fails (e.g., TCP timeout, Connection Refused, or 5xx Server Error). If priority 0 accepts the connection but rejects the specific user (e.g., 'User unknown'), the sender will not try priority 10. Failover is for network/server availability, not user validity.
Yes, it is a standard high-availability strategy. By assigning the same priority number (e.g., 10) to multiple different servers, you instruct sending MTAs to distribute the load across them. This increases throughput and redundancy without needing a hardware load balancer.
FALSE. While some lenient mail servers might accept it, RFC 1035 and RFC 2181 explicitly state that MX records must point to a domain name, which then resolves to an IP. Pointing directly to an IP is a violation and will cause delivery failures with strict providers.
TTL controls how long other servers cache your mail server location. A high TTL (e.g., 86400 seconds = 24h) is efficient for stable systems. A low TTL (e.g., 300 seconds = 5m) is critical during migrations. If you plan to change mail providers, lower your TTL 48 hours in advance to prevent downtime.