An MX record (mail exchanger record) is a DNS entry that tells sending servers which mail server accepts email for a domain. When you send to [email protected], your server looks up example.com's MX records to find the destination. No MX record, and mail has nowhere to go, so the address is undeliverable.
How do MX records route mail?
Mail routing starts with a DNS lookup. The sending server queries the recipient domain for its MX records, gets back one or more mail server hostnames with priority numbers, then connects to the host with the lowest priority number first. That server accepts the message and passes it toward the recipient's mailbox.
Every domain's DNS zone can hold multiple MX records, and each one pairs a mail server hostname with a priority value. Lower numbers win, so a record at priority 10 is tried before priority 20. If the highest-priority server refuses the connection or times out, the sender falls back to the next host in line. This is why large providers publish several MX hosts. It spreads load across servers and keeps mail flowing when one node fails. Google Workspace and Microsoft 365 both work this way, listing multiple mail exchangers for redundancy. The whole handoff happens in milliseconds, invisible to the person clicking send, but it is the reason your message reaches the right server instead of vanishing.
What does an MX record contain?
An MX record has two core parts: a priority number and the hostname of a mail server that accepts mail for the domain. The hostname must resolve to an IP address through its own A or AAAA record. DNS wraps both parts with a record type and a TTL that controls caching.
| Field | What it means | Example |
|---|---|---|
| Record type | Always MX for mail exchanger records | MX |
| Priority | Preference value, lower number is tried first | 10 |
| Mail server host | Hostname of the server that accepts mail | aspmx.l.google.com |
| TTL | How long resolvers cache the record, in seconds | 3600 |
Two details trip people up. First, the MX host must be a hostname, not an IP address. Pointing an MX record straight at an IP breaks the spec, and many receiving servers will reject mail routed that way. Second, the priority only matters relative to other MX records in the same zone. A lone record at priority 10 behaves exactly like one at priority 5, because there is nothing to compare it against. The TTL matters too. A long TTL means resolvers cache the record for hours, so DNS changes to your mail routing take time to spread across the internet.
Why does a missing MX record make a domain undeliverable?
If a domain publishes no MX record, sending servers have no mail host to connect to. Some will fall back to the domain's A record as a last resort, but many do not, and modern providers often skip that fallback. In practice, no MX usually means the domain cannot receive email, so every address on it bounces.
This is why MX lookup is the first real filter in email verification. A syntactically perfect address like [email protected] is worthless if brokendomain.com publishes no MX record. The mailbox cannot exist because there is no mail server behind the domain to hold it. Catching this before you send protects your sender reputation and your bounce rate. Keep hard bounces under 2% and mailbox providers keep trusting your sending domain. Cross 5% and you invite throttling, spam foldering, or outright blocks. A single import of stale addresses on dead domains can push a healthy list past that line in one send, which is why the MX check earns its place at the front of the pipeline.
How do you check a domain's MX records?
You can read a domain's MX records in under a minute with a DNS query. Command-line tools like dig and nslookup return the raw records, and browser-based lookup pages do the same without any install. The steps below show the fastest path on any operating system.
- Open a terminal, or load an online DNS lookup tool in your browser.
- Run dig example.com MX on macOS or Linux, or nslookup -type=mx example.com on Windows.
- Read each returned line: it shows a priority number followed by a mail server hostname.
- Confirm at least one hostname resolves to an IP address with its own A or AAAA record.
- Treat an empty answer as a red flag: the domain has no MX record and cannot accept mail.
If the lookup returns records but mail still bounces, the problem is usually downstream: a full mailbox, a server that rejects unknown users, or a catch-all that hides which addresses are real. That is the boundary where a DNS check stops and mailbox-level verification begins.
Check your list right now, free
10 checks a day with no signup. 100 a day with just your email.
How does email verification use MX records?
Email verification uses the MX record as a gate. The engine first checks address syntax, then queries the domain for MX records. If none exist, the address is marked invalid without wasting a mailbox probe. If MX records are present, the verifier connects to the listed mail server and runs an SMTP-level check to test whether that mailbox accepts mail.
This ordering saves both time and quota. MX lookups are cheap DNS queries that return in milliseconds. SMTP checks are heavier, since they open a real connection to the destination server, so you only want to run them on domains that can actually receive mail. Our verification engine also flags catch-all domains, where the server accepts every address and cannot confirm any single mailbox. Those land in the Risky bucket rather than Deliverable, so you know to treat them with care instead of trusting them blindly. Role addresses like info@ and support@, and disposable domains, get their own flags for the same reason: they route mail, but sending to them carries extra risk.
Do MX records guarantee an inbox exists?
No. An MX record only proves the domain can receive mail somewhere. It says nothing about a specific address. A domain can have valid MX records while [email protected] does not exist. That gap is why MX checks alone are not enough, and why SMTP-level mailbox verification runs on top of the MX result.
Treat MX records as the foundation of deliverability, not the whole building. They tell you a domain is capable of receiving mail. Authentication records like SPF, DKIM, and DMARC tell inbox providers your mail is legitimate. Verification ties both together, confirming the domain routes mail and the mailbox is real before you hit send. Get the MX check right first, and every layer you stack on top has something solid to stand on.