Why MX is the first place to look
MX records tell the internet where to deliver email for a domain. When a secure email gateway sits in front of the mailbox platform, its infrastructure often becomes the public mail-routing endpoint. That makes MX one of the most commercially useful signals for detecting an existing email-security vendor.
The pphosted pattern
Proofpoint-hosted routing commonly exposes hostnames under pphosted.com. A hostname such as mx1.example.pphosted.com in the authoritative MX set is therefore strong evidence that Proofpoint participates in the inbound mail path.
The conclusion should be “Proofpoint detected in the public mail-routing path,” not “we know every email-security control the company uses.” API-based controls and internal layers may not appear in MX at all.
MX priority matters less than the provider pattern
MX preference numbers define delivery order among the published endpoints. For provider identification, the key question is whether the active records resolve to a recognized Proofpoint routing pattern. Multiple records with different preferences often represent redundancy rather than different products.
SPF can reinforce the finding
SPF includes can reveal outbound services that are not visible in MX. A Proofpoint-related SPF include can strengthen the provider classification or show that Proofpoint participates in outbound authorization even when inbound routing looks different. The two records answer different questions, so SecuTest keeps the evidence source attached instead of merging everything into an unexplained label.
What a gateway hides
If Proofpoint is the MX destination, MX no longer tells you whether the backend mailbox platform is Microsoft 365, Google Workspace or something else. That is where secondary signals such as Entra ID, Autodiscover and DKIM become valuable. The result may be “Proofpoint + Microsoft 365” with separate evidence for each layer.
Use the signal commercially without sounding invasive
An MSP should not lead with “we scanned you and found a weakness.” A provider detection is often more useful as qualification context: the account already buys email security, the current stack is identifiable, and your service may compete with, manage or complement that platform.
| Signal | What it supports | What it does not prove |
|---|---|---|
| Proofpoint MX | Proofpoint in inbound mail path | Backend Workspace |
| Proofpoint SPF include | Proofpoint-related sender authorization | Inbound gateway usage by itself |
| Microsoft secondary signals | Possible Microsoft 365 backend | That every user/mailbox is on M365 |
Turn the signal into a prospecting workflow.
SecuTest attaches public infrastructure evidence to each prospect so your team can qualify the account without turning an inference into a claim.