Look up and validate MX records for any domain. Shows all mail exchange servers with priority order, and checks for common misconfigurations that cause email delivery failures or security vulnerabilities.
This tool checks one area. The full scan covers SSL, open ports, HTTP headers, breach exposure, subdomain enumeration, compliance mapping, and more — free, no login required.
MX (Mail Exchange) records are DNS records that tell the internet which servers handle email for your domain. When someone sends an email to user@yourdomain.com, the sending mail server queries DNS for your domain's MX records to determine where to deliver the message. Without correct MX records, you cannot receive email — messages will either bounce back to the sender or be silently lost.
MX records are one of the most critical DNS configurations for any organization that relies on email communication. A misconfigured MX record can disrupt business operations, cause missed invoices and client communications, and undermine trust with partners and customers. Despite this, MX records are frequently misconfigured, especially during domain migrations or email provider changes.
Each MX record contains two key pieces of information: a priority value (also called preference) and a mail server hostname. When a sending server needs to deliver email to your domain, it queries your DNS for MX records and sorts them by priority. The server with the lowest priority number is tried first. If that server is unavailable, the sender moves to the next server in priority order.
For example, a typical Google Workspace configuration includes five MX records with priorities ranging from 1 to 10, all pointing to different smtp.google.com endpoints. This ensures that even if one server is under maintenance, email delivery continues uninterrupted through the backup servers.
MX records also have a TTL (Time to Live) value that controls how long DNS resolvers cache the record before refreshing. A lower TTL means changes propagate faster but increase DNS query volume. During migrations, temporarily reducing TTL to 300 seconds (5 minutes) allows faster cutover. Under normal operations, a TTL of 3600 seconds (1 hour) or higher is standard.
Always configure at least two MX records pointing to different mail servers. If your primary server experiences downtime, the secondary server will accept and queue messages until the primary recovers. Enterprise environments typically maintain three or more MX records across geographically distributed data centers.
Use distinct priority values and leave gaps between them (e.g., 10, 20, 30 rather than 1, 2, 3). This makes it easy to insert additional servers later without renumbering. Ensure your primary server has the lowest priority number and backup servers have progressively higher values.
Each mail server listed in your MX records should have a corresponding PTR record that resolves the server's IP address back to its hostname. Many receiving mail servers check reverse DNS as part of spam filtering. A missing PTR record can cause your outbound email to be flagged as spam or rejected entirely.
MX records must point to hostnames, not IP addresses. An MX record containing an IP address violates RFC 5321 and will be rejected by most mail servers. Always use a fully qualified domain name like mail.yourdomain.com rather than an IP address.
The most frequently encountered MX configuration problems include:
If no MX records exist for your domain, sending servers may fall back to delivering to your A record, but many modern mail systems will simply reject delivery. This is the most critical MX issue and results in immediate email loss.
An MX record that points to a CNAME record is an RFC violation (RFC 2181). While some mail servers tolerate this, others will reject the delivery. Always ensure your MX records point directly to A or AAAA records, not to CNAME aliases.
MX records that point to servers which are not accepting connections on port 25 cause delayed delivery at best and bounced email at worst. This commonly occurs after infrastructure changes when firewall rules are not updated or old servers are decommissioned without updating DNS.
Mail servers without reverse DNS (PTR records) are frequently blacklisted or penalized by receiving servers. Many major email providers, including Gmail and Microsoft, explicitly check for valid reverse DNS and may reject messages from servers that lack it.
MX records are just one component of a broader email security architecture. They work alongside several other DNS-based mechanisms to authenticate and protect email in transit.
SPF (Sender Policy Framework) records specify which IP addresses are authorized to send email on behalf of your domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies tell receiving servers how to handle messages that fail SPF or DKIM checks. Together, these records prevent attackers from spoofing your domain in phishing campaigns.
On the transport security side, STARTTLS enables opportunistic encryption of SMTP connections, while MTA-STS (Mail Transfer Agent Strict Transport Security) enforces TLS encryption and prevents downgrade attacks. MTA-STS requires publishing a policy file and a corresponding DNS TXT record, adding another layer of protection for email in transit between mail servers.
For a comprehensive view of your domain's email security posture, combine MX record validation with DNS security checks and a full domain security scan.
When you enter a domain, this MX Record Checker queries authoritative DNS servers for all MX records associated with your domain. The tool displays each mail server with its priority value, validates that each server hostname resolves to a valid IP address, checks for common misconfigurations like CNAME targets and RFC violations, and verifies that the mail servers are reachable on standard SMTP ports.
Results are presented with clear pass/warn/fail indicators and specific remediation guidance for any issues found. The check runs in seconds and requires no authentication or installation.
You should have at least two MX records pointing to different mail servers for redundancy. If your primary mail server goes down, the sending server will attempt delivery to the secondary server based on priority values. Most email providers like Google Workspace and Microsoft 365 automatically provide multiple MX records. Having only a single MX record creates a single point of failure where any downtime means lost email.
MX priority (also called preference) is a numeric value that determines the order in which mail servers are tried. Lower numbers have higher priority. For example, a server with priority 10 will be tried before a server with priority 20. If the highest-priority server is unavailable, the sending server falls back to the next-lowest priority value. Common conventions use values like 10, 20, 30 to leave room for inserting additional servers later.
Yes. If your MX records point to servers that do not exist or are not configured to accept mail for your domain, incoming email will bounce back to the sender. If MX records are missing entirely, sending servers may attempt delivery to the A record as a fallback, but most modern mail systems will simply reject the delivery. During DNS propagation after changing MX records, some email may be temporarily delayed, so plan MX changes carefully.
MX records are managed through your DNS provider or domain registrar. Log in to your DNS management panel, navigate to the DNS records section, and add or modify MX record entries. You will need to specify the mail server hostname and a priority value. Changes typically propagate within 1 to 48 hours depending on your TTL settings. Before making changes, note your existing MX records so you can revert if needed. Never delete old MX records before confirming the new ones are working.