An MX (mail exchanger) record is a DNS record that tells the internet which servers accept e-mail for a domain, and in what order to try them. When you send to [email protected], your mail server looks up the MX records of example.com and delivers to the host they name. An MX check is the cheapest way to confirm that the domain part of an address can receive mail at all.
How does an MX record work?
The record type is defined in the DNS standard RFC 1035 (§3.3.9). Each MX record has two fields: a preference number and an exchange host name. Lower preference values are tried first. A domain with two records might look like this:
example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.Mail routing is specified in RFC 5321 §5.1. The sender looks up MX records for the domain, sorts them by preference, and tries each host in turn. If a domain has no MX record but has an address record (A or AAAA), the sender treats the domain itself as an implicit mail exchanger with preference 0.
What is a null MX record?
Because of that fallback, a domain without MX records can still attract delivery attempts that retry for days. RFC 7505 fixes this with a null MX: a single MX record with "preference number 0 and a zero-length label, written in master files as '.'". It declares that the domain accepts no mail, so senders should fail immediately and tell the user.
no-mail.example. 3600 IN MX 0 .For validation, a null MX is a definite "this domain can't receive e-mail".
What can an MX check tell you, and what can't it?
| Result | Meaning | Typical action |
|---|---|---|
| Domain doesn't exist (NXDOMAIN) | Almost always a typo | Ask the user to correct it |
| Null MX | Domain explicitly accepts no mail | Reject the address |
| No MX, but an A/AAAA record | Mail may still be delivered via the fallback | Accept with caution, confirm |
| Valid MX records | The domain can receive mail | Go on to further checks |
An MX lookup says nothing about the mailbox. [email protected] and [email protected] share the same MX records. A domain with good MX records may also be a catch-all that accepts everything, or a disposable e-mail service.
Why does it matter for deliverability and fraud?
Mistyped domains (gmial.com, outlok.com) are among the most common sign-up errors. Catching them at the form, while the person can still fix them, prevents undeliverable receipts and password resets, and avoids the hard bounces that hurt sender reputation. For fraud, an MX check is only a first filter: fake-account tooling uses real, working domains.
How does MobileValidate fit in?
Run syntax and MX checks yourself: they are free, fast and available in every language's DNS library. MobileValidate adds the next step for major webmail providers: our mailbox check answers whether the specific mailbox exists, without sending mail. Addresses on other domains return unknown with UNSUPPORTED_PROVIDER and are not charged. See e-mail checks in the docs.
Frequently asked questions
What does an e-mail MX record check tell me?
It tells you whether the domain after the @ publishes mail servers, so mail to it can be routed. It says nothing about whether the specific mailbox before the @ exists.
What happens if a domain has no MX record?
Senders fall back to the domain's A or AAAA address record and try to deliver there, as RFC 5321 describes. A domain that wants no mail at all can publish a null MX record, which tells senders to fail at once.
Is an MX check enough to validate e-mail at sign-up?
No. It catches mistyped and non-existent domains cheaply, but a domain with valid MX records can still reject the mailbox, accept everything as a catch-all, or be a disposable-mail service.