Provider Detection
Provider detection
When a tech opens Cathedra on a new client domain, the first question is usually “who hosts their mail?” The answer is rarely in IT Glue’s first page, and asking the client is slow. The DNS already tells you, if you know what to read.
ProviderDetectionCheck does that reading automatically. It looks at the MX targets and the SPF record, matches both against a list of known patterns, and reports which providers it recognizes.
What Cathedra checks
The check maintains two parallel lookup tables — one for MX hostname patterns, one for SPF include patterns. Both tables cover the same seven providers:
| Provider | MX hostname signal | SPF include signal |
|---|---|---|
| Microsoft 365 | mail.protection.outlook.com |
spf.protection.outlook.com, outlook.com |
| Google Workspace | aspmx.l.google.com, googlemail.com, google.com, smtp.google.com |
_spf.google.com |
| Proofpoint | pphosted.com, proofpoint.com |
pphosted.com |
| Mimecast | mimecast.com |
spf.mimecast.com |
| Barracuda | barracudanetworks.com, bsn.io |
spf.barracuda.com |
| Sophos | sophos.com, sophosmx.com, reflexion.net |
spf.sophos.com |
| AppRiver / Zix | appriver.com, zixmail.com, zixsmtp.net |
appriver.com, zixsmtp.net |
The match is a substring check. If any MX target contains any provider pattern, that provider is flagged as detected “via MX.” Otherwise, if the SPF record contains a provider pattern, it’s detected “via SPF.”
The check then emits a single finding:
status: info / severity: null
“Detected provider(s): {Provider} (via MX), {Provider} (via SPF)”
When no patterns match anywhere:
status: info / severity: null
“Could not identify a known inbound mail security vendor from MX or SPF records.”
The status is info in both cases — provider detection is reporting, not grading. It never returns an error or warning, regardless of the result.
Why MX wins over SPF
The check checks MX first. If a provider matches via MX, it’s marked detected and the SPF table isn’t consulted for that provider. The reason: the MX target is the current inbound mail path. The SPF record describes which servers are authorized to send mail for the domain — which can include former providers, transactional senders, and historical artifacts.
Practically: a client mid-migration from Mimecast to M365 might still have include:spf.mimecast.com in their SPF (so existing relay traffic doesn’t break) but their MX already points to mail.protection.outlook.com. Cathedra correctly reports Microsoft 365 as the primary provider — that’s where mail is actually going right now. The Mimecast SPF include shows up under SPF detection but doesn’t override the MX result.
If both MX and SPF flag the same provider, the MX detection wins and SPF is ignored for that provider. You only see “(via SPF)” when a provider was matched in SPF but not in MX.
Reading the chain on a real domain
Walk through isidoregroup.com:
dig isidoregroup.com MX +short
0 isidoregroup-com.mail.protection.outlook.com.
Cathedra: matches mail.protection.outlook.com → Microsoft 365 (via MX).
dig isidoregroup.com TXT +short | grep spf
"v=spf1 include:spf.protection.outlook.com -all"
Cathedra: would have matched spf.protection.outlook.com → Microsoft 365 (via SPF), but Microsoft 365 already detected via MX. Result: single detection, “Microsoft 365 (via MX).”
A more complex chain — a client routing inbound through Proofpoint to an M365 backend:
dig acme.com MX +short
10 acme-com.pphosted.com.
dig acme.com TXT +short | grep spf
"v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Cathedra:
– MX matches pphosted.com → Proofpoint (via MX).
– SPF matches spf.protection.outlook.com → Microsoft 365 (via SPF), not in MX → flagged.
– SPF matches _spf.google.com → Google Workspace (via SPF), not in MX → flagged.
Finding: “Detected provider(s): Proofpoint (via MX), Microsoft 365 (via SPF), Google Workspace (via SPF)”
Interpretation: inbound mail flows through Proofpoint as the front door. Outbound mail is authorized to come from both M365 and Google Workspace tenants — suggesting either an in-progress migration or two business units on different cloud platforms. The primary provider Cathedra reports for downstream checks is Proofpoint (first in the MX-detection order), and that’s the “current inbound mail security vendor.”
When nothing matches
If Cathedra returns “Could not identify a known inbound mail security vendor from MX or SPF records,” one of three situations is in play:
- Self-hosted mail. A client running their own server with no recognizable third-party in the chain. Less common every year, still occasional.
- An unlisted provider. Smaller mail security vendors and regional ISPs aren’t in Cathedra’s table. The setup may be perfectly valid; Cathedra just doesn’t recognize the signature. Document what you find in IT Glue.
- A new provider. If a major vendor we should know about isn’t being detected, surface it for the Codex team — the pattern table can be expanded.
In all three cases, the audit report needs a human-written note identifying the provider. Don’t leave a finding that reads “unknown” on a client report.
Why this matters for downstream Cathedra checks
The MailDiagnosticsService calls primaryProvider() after the main check runs and stores the result on the diagnostics output. That value influences how the report is presented and what the AI summary highlights. A domain detected as Microsoft 365 gets M365-specific guidance. An undetected domain gets generic guidance.
For the tech reading the report, the detection result is also the fastest way to confirm what platform you’re working with before you start changing records. If Cathedra says M365 and the client says Google, one of you is wrong — and the DNS doesn’t lie.
Cheat sheet — the MX signals
| MX target contains | Provider |
|---|---|
mail.protection.outlook.com |
Microsoft 365 |
aspmx.l.google.com (any *.google.com or googlemail.com) |
Google Workspace |
pphosted.com |
Proofpoint |
mimecast.com |
Mimecast |
barracudanetworks.com, bsn.io |
Barracuda |
sophos.com, sophosmx.com, reflexion.net |
Sophos |
appriver.com, zixmail.com, zixsmtp.net |
AppRiver / Zix |
What you should remember
- Cathedra emits one info finding with the detected provider list: “Detected provider(s): {provider} (via MX), {provider} (via SPF).”
- MX detection wins over SPF detection. If both flag the same provider, only the MX result is reported.
- The primary provider — used downstream for report context — is the first match in MX order.
- An MX-detected provider is the current inbound mail host. SPF-only detection often indicates legacy senders or migration artifacts.
- “Could not identify a known inbound mail security vendor” doesn’t mean the setup is wrong — just that Cathedra’s pattern table doesn’t recognize it. Investigate and document manually.
Next lesson covers the Autodiscover DNS check — the small record that makes Outlook setup either silent or painful.
Cathedra alignment: ProviderDetectionCheck — Inbound Security Provider