MX Redundancy

MX redundancy

Most of our clients have exactly one MX record. Cathedra flags this with a low-severity warning every time. Most of the time the warning is informational and we wave it through. Sometimes it’s a real finding. This lesson is about telling the two apart.

What Cathedra checks

MxRecordCheck counts the MX records returned by DNS. If there’s exactly one, after the main MX presence pass, a second check emits:

status: warning / severity: low
“Only one MX record configured. If it goes down, mail delivery will fail.”
Recommendation: “Consider adding a secondary MX record for redundancy.”

That’s the entire check: count MX records, warn if there’s only one. The check has no awareness of which mail host the single MX points to. It treats every domain identically.

Why “only one MX” is usually fine

For cloud mail providers, redundancy is handled at the host the MX points to. When DNS resolves isidoregroup-com.mail.protection.outlook.com., the result is a set of multiple IP addresses across multiple Microsoft data centers:

dig isidoregroup-com.mail.protection.outlook.com +short
52.101.40.16
52.101.42.30
52.101.68.30
52.101.68.16

A sender connecting to that MX host gets one of those IPs. If it’s unreachable, the sender tries the next IP. The redundancy lives below the DNS layer, in Microsoft’s routing infrastructure. The same is true for Google Workspace, which uses five MX hostnames (aspmx.l.google.com. plus four alt*.aspmx.l.google.com. targets) — but even the single-target case resolves to a redundant fleet.

So for any client on M365 or Google Workspace, the Cathedra “only one MX” warning is misleading on its face. Adding a second MX record wouldn’t improve resilience — there’s nothing meaningful to point a second MX at. The warning is noise, and you note it on the audit report with a one-line “single MX is expected for cloud mail” and move on.

When MX redundancy genuinely matters

Three categories of client where the warning deserves action:

  1. Self-hosted or on-prem mail. If a client runs their own mail server on a single IP, that server is a single point of failure. A secondary MX — pointing to a third-party mail-spool service — accepts mail while the primary is down and forwards it when the primary returns. This is the classic spool-and-forward pattern. Rare in our portfolio but it still exists.

  2. Two cloud providers running in parallel. Some clients in mid-migration or running redundant cloud tenants will publish MX records for both. The two providers handle mail independently; the failover is real. This is a deliberate configuration, not a Cathedra-driven recommendation.

  3. Inbound mail security providers with explicit backup MX. Some Proofpoint, Mimecast, and Barracuda setups publish multiple MX records pointing to different ingress regions. Cathedra sees those as redundancy; the customer sees them as the provider’s normal architecture.

In every other case — meaning the bulk of our work — the single-MX warning is an artifact of using cloud mail, and your audit-report response is “expected, no action.”

How to handle the warning in the audit report

The Isidore audit report convention:

  • If the MX target matches a known cloud provider (M365, Google Workspace), note the warning as informational and write one sentence: “Single MX is expected for cloud-hosted mail; redundancy is handled at the provider level.”
  • If the MX target is the client’s own infrastructure or an unknown host, treat it as a real finding and recommend either (a) provider-level redundancy you can verify, or (b) a secondary MX with a third-party spool service.

The provider-detection check (lesson 2.3) tells you which category you’re in. If Cathedra detects Microsoft 365 or Google Workspace via the MX target, you’re in the cloud case. If it detects nothing, you have an unknown setup to investigate.

Why you don’t add a “decoy” secondary MX

A temptation: clear the Cathedra warning by adding a second MX record pointing to something — anything — at a higher priority. Don’t do this. The secondary MX becomes a delivery target. If you point it at a host that doesn’t accept mail for the domain, senders will deliver there, the host will reject the message, and mail will queue and eventually bounce. You’ve created a real failure mode to clear a cosmetic warning.

If a second MX exists, it must accept mail for the domain. There is no fake-redundancy pattern that’s safer than the warning.

A real configuration walkthrough

Single-MX, M365 (most of our portfolio):

isidoregroup.com.   3600   IN   MX   0   isidoregroup-com.mail.protection.outlook.com.

Cathedra returns:
– “1 MX record(s) found: isidoregroup-com.mail.protection.outlook.com.” — pass
– “Only one MX record configured. If it goes down, mail delivery will fail.” — warning / low

Action: note “expected for M365” on the report, move on.

Two-MX, Google Workspace with explicit alts:

acme.com.   3600   IN   MX   1    aspmx.l.google.com.
acme.com.   3600   IN   MX   5    alt1.aspmx.l.google.com.
acme.com.   3600   IN   MX   5    alt2.aspmx.l.google.com.
acme.com.   3600   IN   MX   10   alt3.aspmx.l.google.com.
acme.com.   3600   IN   MX   10   alt4.aspmx.l.google.com.

Cathedra returns:
– “5 MX record(s) found: aspmx.l.google.com., alt1.aspmx.l.google.com., …” — pass
– No redundancy warning (count > 1).

Action: nothing. Google’s published MX set is well-known.

Cheat sheet

MX count Cathedra finding Field interpretation
0 error / critical Hard fail — see lesson 2.1
1 pass + warning / low (redundancy) Expected for cloud mail; informational
2+ pass Either deliberate redundancy or provider-published set

What you should remember

  • Cathedra warns when only one MX record exists: “Only one MX record configured. If it goes down, mail delivery will fail.” — warning / low.
  • For M365 and Google Workspace clients, this warning is expected. Redundancy lives below the DNS layer at the provider.
  • Real redundancy matters for self-hosted mail, parallel cloud setups, and some inbound security providers — not for typical cloud-mail SMB.
  • Never add a “decoy” secondary MX. A second MX must accept mail for the domain or it creates a real delivery failure.
  • The audit-report convention: if the single MX points to a known cloud provider, write “single MX expected for cloud-hosted mail” and move on.

Next lesson covers how Cathedra detects which mail provider a domain uses by inspecting the MX targets and SPF includes.

Cathedra alignment: MxRecordCheck — MX Redundancy

Previous Topic
Back to Lesson
Next Topic