MX record checker: see where a domain's mail goes, and how safely it gets there

An MX (Mail Exchanger) record is a DNS record that names the mail server responsible for accepting email for a domain, along with a priority number. It is defined in RFC 1035, and its role in mail routing in RFC 5321. When you send mail to [email protected], the sending server looks up the MX records for example.com and connects to the host with the lowest priority value first.

The priority, also called preference, sets the order senders try the listed hosts. Lower numbers are tried first, so MX 10 is preferred over MX 20. Records sharing the same value are used in randomised order, spreading load across servers. Higher-numbered hosts act as backups when the preferred servers do not answer.

Under RFC 5321 a sender that finds no MX record may fall back to the domain's A or AAAA address record, known as the implicit MX rule. In practice this is unreliable: many providers do not attempt the fallback, so mail is likely to be delayed or rejected. A domain publishing neither MX nor A records cannot receive email at all and messages will hard-bounce.

No. An MX record only proves the domain has somewhere to deliver mail. It says nothing about whether a specific mailbox exists. Confirming a mailbox requires an SMTP handshake with the receiving server, and even then catch-all domains accept every address, so the answer can be inconclusive.

The tool is free and needs no account. It runs in your browser: the domain you enter is sent to a public DNS-over-HTTPS resolver: Cloudflare, with Google as a fallback: to get the answer, and nothing is logged on our side. Your last five lookups are kept in your browser's local storage only, on your own device.

The MX hostnames reveal it. Hosts ending in aspmx.l.google.com indicate Google Workspace, mail.protection.outlook.com indicates Microsoft 365, mx.zoho.com indicates Zoho, and gateway vendors such as Mimecast, Proofpoint or Barracuda sit in front of the real mailbox provider. This checker matches the returned hostnames against a list of known providers and names the match.

MX controls inbound mail: it tells the world where to deliver messages addressed to your domain. SPF, DKIM and DMARC govern outbound authentication. SPF (RFC 7208) lists which servers may send on your behalf, DKIM (RFC 6376) signs messages cryptographically, and DMARC (RFC 7489) tells receivers what to do when those checks fail and where to send reports.

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain declare that senders must use TLS with a valid certificate when delivering mail to it, and must not fall back to plaintext. It has two parts: a TXT record at _mta-sts.<domain> containing v=STSv1 and a policy id, and a policy file served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. Without it, an attacker able to interfere with the connection can strip STARTTLS and read mail in transit. This checker reports the DNS half, which is what determines whether senders look for a policy at all.

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a TXT record at _smtp._tls.<domain> containing v=TLSRPTv1 and a rua address. It asks sending providers to send daily aggregate reports about TLS delivery to your domain, including failures such as expired certificates or stripped STARTTLS. It is how you learn that MTA-STS or DANE is breaking mail before your senders tell you.

DANE (RFC 6698, applied to SMTP in RFC 7672) publishes a TLSA record at _25._tcp.<mail-host> that pins the mail server's certificate or key through DNS. It requires a DNSSEC-signed zone, because the pin is only trustworthy if the DNS answer is signed. DANE is widely deployed in the Netherlands, Germany and parts of the public sector, and rare elsewhere; MTA-STS is the more common way to enforce TLS. Publishing either beats publishing neither.

A PTR record maps an IP address back to a hostname, published in the in-addr.arpa zone by whoever controls the address block. Receiving servers check that a sending IP has a PTR record and, ideally, that the name it returns resolves back to the same address: forward-confirmed reverse DNS. Missing or generic reverse DNS is a long-standing spam signal and a common cause of rejection for self-hosted senders. This checker resolves the primary MX host to its IPv4 address and reports the PTR for that address.

DNSSEC signs DNS answers so a resolver can detect tampering. Without it, an attacker who can forge DNS responses can point your MX lookup at their own server, and spoof SPF, DKIM and DMARC records along with it. DNSSEC is also a hard prerequisite for DANE. This checker reports whether the resolver returned the authenticated-data (AD) flag for the MX answer; an unsigned answer is common and not an error on its own.

DNS answers are cached for the length of each record's TTL, shown in seconds beside the MX host. Until that time elapses, resolvers may keep serving the previous answer. Lowering the TTL before a planned migration and raising it afterwards keeps cutovers fast.