MX records and SMTP routing

The MX record is the only DNS record that exists specifically for mail. Every other record we use for email — SPF, DKIM, DMARC, MTA-STS — lives in TXT and is a layer on top. The MX is the actual routing instruction: “to deliver mail for this domain, go talk to this host.”

Module 1 covered DNS structure. This module covers what happens to a message after a sender’s mail server has looked up the recipient’s domain.

How a sender uses MX

A mail server delivering a message to someone@isidoregroup.com runs this sequence:

Look up MX records for isidoregroup.com.
Sort the returned records by priority (lower number first).
Attempt SMTP delivery to the lowest-priority MX host on port 25.
If that fails (connection refused, timeout, 4xx response), try the next MX in priority order.
If all MX hosts fail, queue the message and retry later.

The priority field — sometimes called preference — is the second number in an MX record:

dig isidoregroup.com MX
;; ANSWER SECTION:
isidoregroup.com.   3600   IN   MX   0   isidoregroup-com.mail.protection.outlook.com.

The 0 is the priority. Lower is preferred. For an M365 tenant, the priority is almost always 0 because there’s only one MX host and the value doesn’t matter.

When multiple MX records exist

If a domain publishes multiple MX records with different priorities, the priority field controls failover, not load balancing:

acme.com.   3600   IN   MX   10   mx1.acme.com.
acme.com.   3600   IN   MX   20   mx2.acme.com.

A sender always tries mx1 first. If mx1 is unreachable, it tries mx2. If multiple records share the same priority, the sender chooses among them at random — that’s the load-balancing case, and it’s rare in modern setups.

You’ll see the failover pattern in two contexts:
– Legacy on-prem Exchange with a secondary MX hosted by a third party for spool-and-forward.
– Self-hosted mail with redundant MX infrastructure at separate sites.

For cloud-hosted mail (M365, Google Workspace), the provider’s single MX hostname resolves to multiple IPs server-side. Redundancy is handled there; you only need one MX record. Lesson 2.2 covers this in more detail.

What Cathedra checks

MxRecordCheck calls dns_get_record($domain, DNS_MX). If the result is empty:

status: error / severity: critical
“No MX records found. Mail cannot be delivered to this domain.”
Recommendation: “Add MX records pointing to your mail provider.”

This is the most consequential finding in the whole Cathedra report. No MX = no mail. If you see this on a domain that’s actively in use for email, something has gone badly wrong — the records were deleted, the wrong zone was edited, or DNS resolution is broken upstream.

When MX records do exist, Cathedra returns:

status: pass
“{N} MX record(s) found: {comma-separated target list}”

For isidoregroup.com, the pass line reads roughly: “1 MX record(s) found: isidoregroup-com.mail.protection.outlook.com.”

If only one MX record is found, a second check fires for redundancy. Lesson 2.2 covers that finding in detail.

The no-MX fallback (and why it’s almost always wrong)

There’s a behavior in SMTP that catches techs by surprise: when a domain has no MX record, senders fall back to the A record of the bare domain. The spec calls this implicit MX and it dates from the early days of the internet when most domains served both web and mail from the same machine.

That assumption is wrong now. A domain’s A record almost always points to a web server, not a mail server. If a domain has no MX, mail will be delivered to that web server, which will refuse the SMTP connection — and the sender will eventually give up.

So in practice, “no MX record” looks identical to “broken delivery.” But the underlying behavior matters for debugging: if you query A and see a record pointing to (say) the client’s WordPress host, and the client is asking why email isn’t reaching their domain, the answer is the missing MX, not the A.

What happens during a fresh tenant setup

A common scenario: a new client signs up for M365, gets their tenant provisioned, and adds the M365-published MX record to their DNS. Before that DNS change publishes, mail is rejected. After the change publishes, mail flows. Cathedra during the gap returns:

“No MX records found. Mail cannot be delivered to this domain.”

After the change publishes:

“1 MX record(s) found: {tenant}-com.mail.protection.outlook.com.”

That single transition — error to pass on the MX check — is the most common visible state change you’ll see during a tenant migration.

A note on priority numbers in the wild

There’s no rule about what priority numbers to use. You’ll see all of these in client zones:

0 — common for single-MX cloud setups (M365 publishes 0).
10, 20, 30 — common when administrators want room to insert records between priorities later.
1, 5, 10 — legacy convention from on-prem days.
100, 200 — same idea, more room.

None of these are wrong. The only thing that matters is the relative order. A priority-0 MX is preferred over a priority-10 MX. Whether the numbers are 0 and 10, or 10 and 20, makes no difference to delivery.

Cheat sheet

Condition	Cathedra status
No MX records	error / critical — “Mail cannot be delivered to this domain.”
One or more MX records	pass — lists the target(s)
One MX record only	additional `warning / low` from the redundancy check (see 2.2)

Quick command reference

dig isidoregroup.com MX +short
0 isidoregroup-com.mail.protection.outlook.com.

+short strips everything except the priority and target. For full output with TTL:

dig isidoregroup.com MX

What you should remember

The MX record routes mail. Cathedra returns error / critical if it’s missing — “No MX records found. Mail cannot be delivered to this domain.”
Lower priority number = preferred. Priority controls failover order, not load balancing.
Without an MX record, senders fall back to the A record. That fallback almost always fails because the A record points to a web server.
Cloud mail providers (M365, Google Workspace) handle redundancy at their end. A single MX record per domain is fine for cloud-hosted mail.
Cathedra’s pass finding lists the target hostnames: “{N} MX record(s) found: {targets}.”

Next lesson: when MX redundancy actually matters, and why most cloud-mail clients don’t need to think about it.

Cathedra alignment: MxRecordCheck — MX Records presence and target list

Previous Lesson

Back to Lesson

Next Topic

MX Records and SMTP Routing