MX Lookup
MX Lookup helps you check mail exchange records for a domain, for authoritative DNS validation, resolver checks, and faster troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
MX Lookup queries the Mail Exchange (MX) records for a domain to find which mail servers are responsible for receiving emails. These DNS records specify the mail servers and their priority order.
Why It Matters
- →Email Delivery: Ensures emails reach the correct mail servers for your domain
- →Redundancy: Multiple MX records provide backup if the primary server fails
- →Security: Helps identify unauthorized or misconfigured mail servers
- →Troubleshooting: Essential for diagnosing email delivery problems
How to Read Results
- Priority: Lower numbers = higher priority (10 is processed before 20)
- Exchange: The hostname of the mail server that receives emails
- Multiple Records: Having 2-3 MX records provides redundancy and reliability
- TTL: Time To Live - how long DNS servers cache this information
Technical Background
Mail Exchange (MX) records are defined in RFC 5321 and RFC 1035 as DNS resource records that specify the mail servers responsible for accepting email messages for a domain. Each MX record contains two fields: a priority value (16-bit unsigned integer, lower = higher priority) and a mail server hostname. When a sending mail server needs to deliver email, it performs a DNS MX lookup for the recipient domain, sorts results by priority, and attempts SMTP connection (TCP port 25) to each server in order. Multiple MX records provide redundancy: if the primary server (priority 10) is unreachable, delivery falls back to the secondary (priority 20). MX records must point to A/AAAA records — never directly to IP addresses or CNAME chains.
Properly configured MX records are a prerequisite for DKIM signing, SPF validation, and DMARC policy enforcement. The SMTP protocol (RFC 5321) defines the full delivery handshake: EHLO/HELO, MAIL FROM, RCPT TO, DATA, and QUIT. Mail servers may support STARTTLS (opportunistic TLS upgrade, RFC 3207) or use port 465 (SMTPS) for implicit TLS. Modern email security requires that MX records point to hosts with valid PTR (reverse DNS) records, properly configured TLS certificates, and SMTP banner hostnames that match the reverse DNS — violations can trigger spam filters.
Common MX configuration patterns include: Google Workspace (aspmx.l.google.com with priorities 1, 5, 10, 10, 10), Microsoft 365 (domain-com.mail.protection.outlook.com at priority 0), and self-hosted Postfix/Exim/Sendmail. Misconfigured MX records are one of the top causes of email delivery failures — organizations may accidentally point to decommissioned servers, have missing or expired PTR records, or have firewall rules blocking port 25 inbound. Regular MX health checks help proactively catch these issues before they result in bounced or undelivered email.
When diagnosing email delivery issues, MX record verification is always the first step. Administrators should confirm: (1) all MX hostnames resolve to valid A/AAAA records, (2) SMTP port 25 is reachable on each MX host, (3) reverse DNS (PTR records) match the forward hostname, (4) TLS certificates on MX hosts are valid and not expired. Tools like mxtoolbox.com, dmarcanalyzer.com, and this tool provide automated verification. Email providers like Gmail and Outlook increasingly reject mail from senders with DNS misconfigurations, making regular MX audits essential for maintaining email deliverability.
Common Errors and How to Fix Them
- ProblemThe MX record points directly at an IP address (for example '10 203.0.113.25').
- FixRFC 5321 requires the exchange field to be a hostname. Create an A/AAAA record such as mail.example.com -> 203.0.113.25 and set the MX to '10 mail.example.com.'.
- ProblemThe MX target is a CNAME alias (mail.example.com CNAME ghs.provider.net).
- FixRFC 2181 section 10.3 forbids MX targets that are aliases; some senders tolerate it, others defer mail. Point the MX at the canonical hostname that owns the A/AAAA records.
- ProblemAfter moving to a new mailbox provider, the old provider's MX records were left in the zone, so part of the inbound mail lands in the abandoned system.
- FixDelete every MX that does not belong to the new provider. A day before the cutover, drop the MX TTL to 300 seconds so the switch is picked up quickly.
- ProblemA secondary MX with a higher preference number accepts everything without spam filtering or recipient validation, and spammers deliberately target it.
- FixRemove the backup MX unless it runs the same filtering and rejects unknown recipients. Modern senders queue and retry for days, so a backup MX is rarely needed.
- ProblemA parked or web-only domain has no MX, so senders fall back to the A record and try to deliver mail to the web server.
- FixPublish a null MX ('example.com. MX 0 .') as defined in RFC 7505 to declare that the domain accepts no mail, and pair it with 'v=spf1 -all'.
- ProblemIn a BIND-style zone file the MX target was written without a trailing dot, producing mail.example.com.example.com.
- FixAlways write fully qualified targets with a trailing dot (mail.example.com.) or use the relative label (mail) intentionally, then re-run the lookup to confirm the expanded name.
Frequently Asked Questions
What happens if a domain has no MX record at all?
Sending servers apply the implicit MX rule from RFC 5321 section 5.1: they look up the domain's A or AAAA record and try to deliver there. If that host is a web server without SMTP, messages sit in queues and eventually bounce. Domains that should never receive mail ought to publish a null MX (priority 0, target '.') so senders fail immediately instead of retrying for days.
Can two MX records have the same priority?
Yes. When several MX records share the lowest preference value, RFC 5321 tells senders to pick among them randomly, which spreads inbound load across servers. Large mailbox providers use this pattern, publishing four or five hosts with identical or closely spaced priorities. Only the relative order matters, so 10/20 behaves exactly like 1/2.
How long does an MX change take to work?
Resolvers keep the previous answer until its TTL runs out, so a record that had a TTL of 3600 can keep routing some mail to the old server for up to an hour, and longer if the TTL was a day. Mail that a sender has already queued is retried against fresh DNS. Keep the old server accepting mail for 48 hours after the switch to catch stragglers.
Do MX records control outgoing email?
No. MX records only tell the world where to deliver mail addressed to your domain. Which servers send on your behalf is declared through SPF, signed with DKIM and enforced by DMARC. A company can receive mail on one platform and send newsletters from three others; each sender must be authorized in SPF or sign with an aligned DKIM key.
Does the MX hostname need its own TLS certificate?
Opportunistic STARTTLS works without a matching certificate, but if you publish MTA-STS (RFC 8461) or DANE, senders validate the certificate against the MX hostname and refuse delivery on mismatch. For that reason the certificate on the receiving server should list the exact name used in the MX record, not only the bare domain.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/mx-lookup
curl -X POST https://epcybertools.com/api/tools/mx-lookup \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Query MX records with dig (macOS)
dig MX example.com
# Short output only
dig MX example.com +short
# Query specific DNS server
dig @8.8.8.8 MX example.com +short