Inbound security providers

Most clients we onboard send mail straight to their cloud tenant. The MX points at mail.protection.outlook.com or aspmx.l.google.com, and that’s the whole chain. A growing subset, particularly in regulated verticals, routes inbound mail through a third-party security provider first — Proofpoint, Mimecast, Barracuda, Sophos, AppRiver. The MX points at the security provider; the security provider scans, filters, and then relays the surviving messages to the tenant.

That two-hop chain changes what you see in Cathedra, and changes which records you trust as the source of truth for “where does mail actually land.”

The two-hop pattern

For a client routing through Proofpoint to an M365 backend, the inbound path is:

1. Sender’s mail server looks up MX for acme.com.
2. MX returns acme-com.pphosted.com (or similar, depending on the Proofpoint tenant).
3. Sender delivers the message to Proofpoint.
4. Proofpoint scans, filters, applies policy, and either rejects or relays the message onward.
5. Proofpoint relays the surviving message to M365 at acme-com.mail.protection.outlook.com. — using a configured relay route that the customer set up inside the M365 tenant’s mail connector.
6. M365 places the message in the recipient mailbox.

The sender only sees step 2. The DNS knows nothing about step 5 — that’s a configuration inside both Proofpoint and M365, invisible from the outside. So a tech reading the DNS sees an MX pointing at Proofpoint and may not realize the delivery target is actually an M365 tenant.

What Cathedra reveals

The combination of MX inspection and SPF inspection is what gives you the full picture. From lesson 2.3, recall that ProviderDetectionCheck matches both MX targets and SPF includes against known providers, with MX winning over SPF for any provider matched in both places.

For a typical Proofpoint-fronted M365 client:

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:pphosted.com -all"

Cathedra’s detection finding:

“Detected provider(s): Proofpoint (via MX), Microsoft 365 (via SPF)”

Read this carefully. Proofpoint via MX means inbound mail enters through Proofpoint. Microsoft 365 via SPF means outbound mail from this domain is authorized to come from M365. Together, that’s the signature of a Proofpoint-fronted M365 tenant: inbound through Proofpoint, outbound direct from M365.

The same pattern applies to Mimecast in front of M365, or any other security-vendor-in-front-of-cloud-tenant setup. The MX tells you the front door. The SPF tells you who can sign for outbound mail.

Why the SPF includes are both there

When a client routes inbound through Proofpoint, the relay step from Proofpoint to M365 doesn’t strictly require the M365 SPF include — Proofpoint’s connector to M365 uses its own credentials and connection. But the M365 include almost always stays, for two reasons:

1. Outbound mail still goes through M365. Users sending mail from Outlook on the desktop or via webmail send through M365 directly. Those messages have an envelope sender of @acme.com and must pass SPF check at the receiving end. Without the M365 include, every outbound message from M365 fails SPF.

2. Proofpoint may not be the only inbound path. Some configurations leave the M365 endpoint reachable as a fallback or for journaling. The SPF includes reflect “who is authorized to send for this domain,” which includes legitimate paths the MX doesn’t show.

If a client has Proofpoint in MX but only the Proofpoint SPF include — no spf.protection.outlook.com — that’s a configuration to investigate. Outbound from the M365 tenant will fail SPF at any recipient that checks.

Reading the full inbound chain manually

To trace the inbound path beyond what Cathedra shows:

dig acme.com MX +short
10 acme-com.pphosted.com.

Step 1: who is the front door? pphosted.com — Proofpoint.

dig acme-com.pphosted.com +short
67.231.156.123
67.231.157.45
...

Step 2: where does Proofpoint receive mail? Multiple IPs at Proofpoint’s hosting infrastructure. This is what senders see.

dig _spf.protection.outlook.com TXT +short

Step 3: confirm the SPF chain. Microsoft’s SPF include resolves to a large set of ip4 and ip6 ranges — too many to read, but they all belong to Microsoft.

What you can’t see from DNS:
– The Proofpoint-to-M365 relay route inside the Proofpoint admin console.
– The M365 mail connector that accepts mail only from Proofpoint’s outbound IPs (if the customer has properly locked it down).
– Whether the M365 endpoint is also exposed directly to the internet (it usually is, unless the customer has added connector rules to restrict it).

For audit work, the DNS reveals the front door. The relay configuration requires admin access to Proofpoint and M365 to confirm.

When the chain is broken or half-finished

Several patterns of “broken or in-transition” inbound chains:

MX points to Proofpoint, but the SPF doesn’t include Proofpoint. Outbound from Proofpoint relays (bounce notifications, internal forwards) will fail SPF. Indicates the SPF was set up before Proofpoint was added.

MX points to M365, but the SPF includes Proofpoint. A migration leftover — Proofpoint was removed from MX, but the SPF includes weren’t cleaned up. Not harmful, but a hygiene issue worth fixing during quarterly review.

Two MX targets at different providers. Some configurations split inbound between providers deliberately (rare, mostly seen with regional or compliance-driven setups). Cathedra reports both via MX. Confirm with the client which is the intended primary; the priority field tells you which one senders try first.

MX at Proofpoint, no M365 SPF include, and no pphosted.com SPF include either. Suggests outbound mail is going somewhere else entirely. Investigate before changing anything.

The audit-report convention

When Cathedra detects multiple providers, the audit report should call out the chain explicitly:

• “Inbound mail is routed through Proofpoint, which relays to a Microsoft 365 tenant.”
• “Outbound mail originates from the Microsoft 365 tenant. SPF authorizes both Microsoft 365 and Proofpoint as sending sources.”

These two sentences tell the client’s IT lead exactly what the topology is. The rest of the Cathedra report — SPF, DKIM, DMARC — then makes sense in context.

Cheat sheet — signature patterns

MX provider	SPF provider(s)	Likely topology
Microsoft 365	Microsoft 365 only	M365 direct, no front-end vendor
Google Workspace	Google Workspace only	Workspace direct, no front-end vendor
Proofpoint	M365 + Proofpoint	Proofpoint front, M365 backend
Mimecast	M365 + Mimecast	Mimecast front, M365 backend
Proofpoint	Workspace + Proofpoint	Proofpoint front, Workspace backend
(no detection)	(no detection)	Self-hosted or unknown vendor — investigate

What you should remember

• An inbound security provider in front of a cloud tenant produces a two-hop chain: sender → vendor → tenant. The DNS only reveals the first hop.
• Cathedra’s provider detection shows the chain by combining MX (front door) and SPF (authorized senders). The output reads like “Proofpoint (via MX), Microsoft 365 (via SPF).”
• The MX tells you where mail enters. The SPF tells you who can sign for outbound. Both matter.
• An MX-fronted vendor with no SPF include for the cloud backend is a configuration hole — outbound from the tenant will fail SPF at recipients.
• The audit-report convention: when the chain is multi-hop, write two sentences naming both the inbound vendor and the backend tenant.

Next lesson is the remediation walkthrough: fixing an MX record in GoDaddy when a finding requires action.

---

Cathedra alignment: ProviderDetectionCheck + MxRecordCheck — reading multi-hop inbound chains