MX records explained: what they are and what they mean for email deliverability
Mail exchanger records are the first thing any email validator checks. A missing or misconfigured MX record means the domain cannot receive email at all — no SMTP probe needed.
Before any SMTP handshake, before any mailbox check, the first thing an email validator (and any mail server) does is look up the MX records for the domain. MX records — Mail Exchanger records — are the DNS entries that say: 'to send email to this domain, talk to this server.' No MX record means no email delivery, end of story.
How MX records work
An MX record has two components: a priority number and a hostname. Lower priority numbers are tried first. If the highest-priority server is unavailable, the sender tries the next lowest. A domain can have multiple MX records for redundancy — Gmail uses five, for example. The hostname in the MX record points to the actual mail server via an A or AAAA DNS record.
What different MX configurations signal
- Google Workspace MX records (aspmx.l.google.com) — legitimate business on Google's infrastructure
- Microsoft 365 MX records (*.mail.protection.outlook.com) — legitimate business on Microsoft infrastructure
- No MX record — domain cannot receive email; INVALID immediately
- MX record pointing to localhost or 127.0.0.1 — misconfigured or deliberately invalid
- Single MX record on a shared hosting server — legitimate but less infrastructure investment
The catch-all MX problem
Some mail servers are configured to accept mail for any address at the domain — the catch-all configuration described in a previous article. From a DNS perspective, these look identical to normal MX records. The catch-all behavior is only detectable during the SMTP handshake when the server responds 250 to every RCPT TO command. This is why MX lookup alone isn't sufficient for reliable validation.
An MX record is necessary but not sufficient for deliverability. It tells you the domain can receive email. It doesn't tell you that the specific mailbox exists.
Common misconfiguration patterns
We see these MX misconfigurations regularly in our validation data: domains with only an A record and no MX (the mail is meant to go to the web server — sometimes works, often doesn't), domains with expired MX hostnames that no longer resolve, and domains with MX records pointing to servers that accept connections but immediately reject mail. All of these result in delivery failure even though the domain 'has' an MX record.