What is MX Record?

An MX record, short for mail exchange record, is a type of DNS entry that tells the rest of the internet which mail servers are responsible for receiving email for a domain. Without an MX record, a domain cannot reliably accept mail, which makes the MX record one of the first things any email verification tool checks.

Definition

An MX record is a DNS record that directs email to a domain's mail servers. DNS, the Domain Name System, is the internet's directory, and it holds different record types for different purposes. An A record maps a domain to an IPv4 address, an AAAA record maps it to an IPv6 address, and an MX record specifically answers the question of where email for a domain should be delivered, in line with SMTP, the standard protocol for sending mail across the internet.

Each MX record carries two pieces of information. The first is a preference value, commonly called the priority, which is a number that ranks the record against the domain's other MX records. The second is the hostname of a mail server that can receive mail for the domain. A domain can publish several MX records at once, each pointing to a different mail server with its own priority.

A typical MX record looks like this: example.com points to a mail server with the entry MX 10 mail.example.com. The 10 is the priority and mail.example.com is the receiving mail server. A domain using Google Workspace, for instance, publishes MX records pointing to Google's mail servers, while a domain on Microsoft 365 publishes records pointing to Microsoft's. The MX record is how a domain's owner tells everyone else, send our email here.

How It Works

MX records do their job during delivery. When a sending mail server has a message for an address such as user@example.com, it does not already know where example.com receives mail, so it asks DNS. It performs an MX lookup for the domain and gets back the list of MX records the domain has published, each with a priority and a mail server hostname.

The priority decides the order of attempts, and the rule is that lower numbers are preferred. The sending server tries the mail server with the lowest priority value first. If two or more MX records share the same priority, the sender picks among them at random, which is how administrators spread incoming mail evenly across multiple equivalent servers for load balancing. If the preferred server cannot be reached because it is offline or the connection times out, the sender moves to the next priority level and tries again, continuing down the list until a server accepts the connection or the list is exhausted. This is why higher-priority-number records serve as backup mail servers.

The priority value is technically an unsigned 16-bit number, so it can range from 0 to 65,535, and administrators usually space their values, such as 10, 20, and 30, to leave room for future changes. One important rule governs the hostname: the mail server name in an MX record must resolve directly to an A or AAAA address record and must not point to a CNAME alias, because the email standards forbid it and strict mail servers can fail delivery if the rule is broken. There is also a special case, the null MX record defined in RFC 7505, which a domain publishes to state explicitly that it accepts no email at all. If a domain has no MX record, sending servers may fall back to its A or AAAA record, but that fallback is fragile and should not be relied on.

Why It Matters for Email Deliverability

The MX record is the foundation of whether a domain can receive email. If a domain has no MX record, and no usable A or AAAA fallback, mail simply has nowhere to go and delivery fails. A misconfigured MX record, such as one pointing to a hostname that no longer exists or to a CNAME, produces the same outcome in practice: messages bounce. Because the MX record sits at the very start of the delivery path, an error here breaks everything downstream.

For senders, MX records are also the cheapest and fastest signal of whether an address is worth pursuing at all. An address whose domain publishes no MX records cannot receive mail, full stop, regardless of how the address itself is spelled. Sending to such addresses generates hard bounces, and a high hard bounce rate tells mailbox providers that a sender is mailing poor-quality data, which lowers inbox placement for the rest of that sender's mail. Catching missing or broken MX records before a campaign goes out removes a whole class of guaranteed bounces.

MX records matter on the receiving side too. Properly configured priorities and backup mail servers keep mail flowing even when a primary server has an outage, because senders fail over to the next server in the list. A domain with only one MX record and no backup risks losing inbound mail entirely during downtime. For both senders and receivers, MX records are not a background detail but a core part of whether email reaches its destination.

How VeriMails Handles It

The MX record check is one of the first stages in the VeriMails verification pipeline. For every address you submit, VeriMails performs an MX lookup on the domain to confirm that the domain publishes valid MX records and that those records point to mail servers that actually exist. If a domain has no MX records, the address cannot receive email, so VeriMails marks it as undeliverable quickly without spending time on later, more expensive checks.

When valid MX records are present, the MX check is the gateway to the rest of verification. VeriMails uses the priority order to identify the preferred mail server, then connects to it to perform a live SMTP handshake that tests whether the specific mailbox accepts mail. Around this, VeriMails also validates syntax, runs broader DNS checks, performs catch-all detection, and flags disposable and role-based addresses. Checking MX records first means an address sitting on a domain that cannot receive mail at all is caught immediately, rather than after a needless connection attempt.

VeriMails returns clear deliverability results rather than a vague numeric score, and the MX check contributes to that decision. You can run verification through the REST API for real-time checks or upload a CSV for bulk verification of an entire list. Verification starts at $0.0019 per email, with 10,000 credits for $19, and subscription plans begin at $15 per month. Every new account includes 100 free credits with no credit card required, and those credits never expire.

Frequently Asked Questions

The priority, also called the preference value, is a number that tells sending servers which mail server to try first. The lowest number is the most preferred, so a server with priority 10 is tried before one with priority 20. If two records share the same priority, the sender chooses between them at random, which spreads load across servers.
In most practical cases a domain needs an MX record to receive mail reliably. If no MX record exists, sending servers may fall back to the domain's A or AAAA address record and attempt delivery there, but this fallback is fragile and many configurations depend on it not being used. A domain with no MX record and no usable fallback cannot receive email.
The email standards require the hostname in an MX record to resolve directly to an A or AAAA address record, not to a CNAME alias. Pointing an MX record at a CNAME is a misconfiguration that can cause delivery failures with strict mail servers. The MX hostname should always be a name that maps straight to an IP address.
VeriMails performs an MX lookup as an early stage of verification. It checks that the domain publishes valid MX records and that they point to reachable mail servers. A domain with no MX records cannot receive email, so the address fails fast. When MX records are present, VeriMails connects to the highest-priority server to continue with a live SMTP handshake.

Try VeriMails Free

100 free credits on signup. No credit card required. Put email verification into practice today.

Start Free
No credit card required. Credits never expire.