MX Record: What It Means and Why the Textbook Definition Misleads

An MX record is a DNS entry that names the mail server responsible for receiving email addressed to a domain, together with a preference number that sets the order servers should be tried in. When a sending server has a message for someone@example.com, it queries DNS for the MX records of example.com, sorts the answers by preference with the lowest number first, and attempts delivery to that host. The behaviour is specified in RFC 5321.

That is the definition every reference gives, and it is accurate. It is also the reason people misread MX records constantly, because it describes what happens when mail arrives and says nothing about the thing outbound teams actually use MX records for, which is finding out who is going to judge their message before they send it.

How the lookup actually behaves

A domain can publish several MX records. The preference value is a priority, not a weight: 10 mail1.example.com is tried before 20 mail2.example.com, and equal values may be balanced across. Sending servers walk the list in order until one accepts the message or all of them refuse it.

The record points at a hostname, never at an IP address, and that hostname must itself resolve to an address. An MX record pointing at an IP is invalid, which is a surprisingly common misconfiguration in small self-hosted setups.

If a domain publishes no MX record at all, RFC 5321 says senders fall back to the domain's address record and attempt delivery there. That fallback is why a domain with a website and no mail configuration can still receive some mail, and why "no MX record" does not mean "cannot receive email".

The deliberate way to say a domain accepts no mail is a null MX, defined in RFC 7505: a single MX record with preference 0 and a target of ., the root. It tells senders to stop immediately and fail the message rather than retry for days. Publishing one on domains you never receive mail at is good hygiene, and reading one on a prospect's domain is unambiguous information.

1. Step 1Query

   Ask DNS for the MX records of the recipient's domain.

2. Step 2Sort

   Order the answers by preference, lowest number first.

3. Step 3Resolve

   Resolve each MX hostname to an address, in that order.

4. Step 4Deliver or fail

   Try each host until one accepts. A null MX stops the attempt straight away.

Where the textbook definition misleads

The textbook framing treats MX as a routing detail. For anyone sending outbound, it is a targeting signal, and reading it that way changes what you do with it.

The MX record tells you which filter you are about to meet. A domain whose MX points at outlook.com hosts is Microsoft 365. One pointing at google.com hosts is Workspace. One pointing at a security vendor is running a gateway in front of the mailbox, so the message will be scanned by that product before the mailbox provider ever sees it. Same recipient, three very different sets of rules about what gets through.

It is the cheapest recipient-side check that exists. An MX lookup is a DNS query. It requires no credit, no vendor, and no permission, and it is the only pre-send signal that tells you something about the receiving infrastructure rather than about the address string. Any list of a few thousand addresses can be resolved in minutes.

A valid MX does not mean a valid mailbox. The record describes the domain, not the person. Every address at a domain shares one MX answer, so a resolvable MX record is entirely compatible with an address that does not exist. Verification of the mailbox itself is a separate job, done by an email verification tool, and neither check substitutes for the other.

A missing MX is a stronger signal than a strange one. Unusual MX targets are usually a small provider nobody has heard of. A domain with no MX and no null MX is often parked, expired, or a typo, and addresses at it will bounce. That is a list-quality finding, available before you spend anything on verification.

Changes take as long as the TTL says they will. MX answers are cached by every resolver that asked for them, for the time-to-live the record specifies. Move a domain's mail from one provider to another and some senders keep delivering to the old host until the cache expires, which is why a migration produces a tail of mail arriving in the wrong place rather than a clean cutover. Lowering the TTL a day before a planned change, and raising it afterwards, is the whole trick.

A catch-all is a mailbox policy, not an MX property. People conflate the two because both are "the domain accepts anything". The MX record says where mail goes; whether the receiving server accepts every local part or rejects unknown ones is a setting on that server, invisible in DNS. This is why verification returns an inconclusive result on accept-all domains: the server answers yes to every address, so the check cannot separate a real mailbox from an invented one. The MX record cannot tell you that either, and reading it as though it could is a genuine source of bad list decisions.

As a routing detailThe textbook reading

• Names the host that accepts mail for the domain
• Preference sets the order to try
• Relevant when you are configuring receiving
• Nothing to act on before a send

As a pre-send signalThe operational reading

• Identifies the provider and any security gateway in front of it
• Groups a list by receiving environment before anything is sent
• Flags parked and expired domains at zero cost
• Explains a cluster of rejections that share one recipient platform

What this means for a live campaign

The moment MX records become urgent is when a campaign starts bouncing and the bounces are not random. If the rejections concentrate on domains behind one security gateway, that is a recipient-side pattern, and the fix is different from the fix for a reputation problem. Comparing bounce behaviour across campaigns that share the same sending inventory is the check that separates those two cases: a sending-side problem hits every campaign on that inventory, and a recipient-side one does not.

Reading the MX before the send makes the same information available earlier. Grouping a list by receiving platform tells you what proportion sits behind gateways with strict rules on unfamiliar senders, and it lets you hold a cohort back rather than discover it in the bounce data afterwards. It also catches the parked and dead domains, which are pure cost in any list you have already paid to enrich.

Grouping by provider also changes what a rejection message means to you. A refusal from a Microsoft 365 tenant, a refusal from a Workspace tenant and a refusal from a security gateway use different wording, cite different policies, and call for different responses. Read in aggregate without knowing which platform produced them, they blur into an undifferentiated bounce rate. Read with the MX answer attached, they separate into groups, and usually one group is doing almost all of the damage.

The practical shape of that is unglamorous. Resolve the MX for every recipient domain in the list, keep the answer as a column, and carry it through to the reporting. It costs nothing per row and it is the difference between "the campaign is bouncing" and "the campaign is bouncing at thirteen domains that all sit behind the same gateway", which is a sentence you can act on.

None of this is a substitute for the sending-side work. Correct authentication, a domain with a real history, and volume that matches that history decide most outcomes. MX reading tells you who is applying the rules, which is worth knowing when the rules differ by an order of magnitude across the same list.

Reading MX records before a send

• ✓Yes: Every recipient domain resolves to at least one MX host
• ✓Yes: Domains with no MX and no address record are dropped as dead
• ✓Yes: A null MX (preference 0, target .) is treated as a hard stop
• ✓Yes: The list is grouped by receiving provider and gateway
• ✓Yes: Mailbox-level verification is run separately, not inferred from MX
• ✕No: Reading a healthy MX as evidence the address exists

The short version

One last habit is worth building, because it costs a single query and prevents an embarrassing class of mistake: read your own MX records too. A sending domain that receives no mail, because nobody configured a mailbox for the replies, silently loses every response to the campaign, and the campaign reports as a total failure rather than as a broken inbox. Confirming that your own domains resolve to a mailbox you actually monitor is the least interesting item on any pre-launch list and one of the few that can cost you the entire result.

An MX record answers "where does mail for this domain go", and the answer is a hostname and a priority. The useful consequence for anyone sending outbound is the second-order one: the hostname names the organisation whose filtering rules your message is about to meet, and it is available for the cost of a DNS query.

It is also, for the price of one query per domain, the earliest honest read you can get on a purchased or inherited list. A file where a meaningful share of domains resolve to nothing is a file somebody assembled a long time ago, whatever the seller says about freshness, and that finding arrives before a single credit has been spent on verification.

Use it to group a list, to drop dead domains before paying to verify them, and to explain rejection patterns that cluster by recipient platform rather than by anything you did. Then verify the mailboxes separately, because the two checks answer different questions. If your bounces are not clustering by recipient platform, the cause is usually on your side, and the deliverability audit checklist and MXToolbox reading guide are the faster routes to it.

RevenueFlow builds and runs cold email and LinkedIn campaigns for B2B teams, including the list and infrastructure work underneath them. See how a campaign is put together.

Behaviour verified as of August 2026 against RFC 5321 and RFC 7505. Verify current specifications with the source before relying on them.