MX lookup

What an MX record is

When someone sends mail to name@example.com, the sending server asks DNS a single question: which hosts accept mail for example.com? The answer is the domain's MX (mail exchanger) records. Each one names a host and a priority number; the lowest number is tried first, and the others are backups used when the primary does not answer. A domain with no MX records but an A record is still technically able to receive mail at that address (RFC 5321 calls this an implicit MX), but in practice almost no such host runs a mail server, so verification treats it as a weak signal.

What this tool shows

Enter a domain, or an email address and the domain is taken from it. The tool resolves the MX records with a bounded DNS lookup so a slow resolver cannot hang the page, sorts them by priority, and marks the primary. It also checks for an A or AAAA record so it can tell you the difference between a domain with no mail at all and one with an implicit MX. Finally it identifies the provider from the MX host names: smtp.google.com means Google Workspace, mail.protection.outlook.com means Microsoft 365, and gateways such as Proofpoint, Mimecast and Barracuda are recognised too. Anything unfamiliar is labelled self-hosted.

Why it matters for deliverability

MX records are the first thing Verifyre checks after syntax, because a domain without mail servers cannot receive anything, however plausible the address looks. They also tell you a lot about a list. Many addresses routed through a security gateway usually means a corporate B2B list; a long tail of self-hosted domains often means older data and more dead mailboxes. If you are the domain owner, check that your MX records point where you expect, that backup exchangers actually accept mail, and that you have not left an old provider's host in place after a migration. A wrong or stale MX record is one of the most common reasons a company silently stops receiving email.