The strongest MSP lists combine several weakly related clues into a transparent targeting hypothesis, while keeping unknown values visible.
Three dimensions that complement one another
Workspace identifies a likely collaboration and mailbox ecosystem. Email-gateway detection describes part of the visible inbound mail path. DMARC describes a public domain-authentication policy. These dimensions answer different questions and should stay separate in the data model.
A gateway can hide the underlying workspace. An SPF reference to Microsoft does not establish Microsoft-hosted mail. And DMARC enforcement says nothing on its own about a company's full security program.
Segment A: M365 operations and authentication
Criteria: strong Microsoft 365 evidence, monitoring-only DMARC, and a business that fits your service region. Offer hypothesis: reporting, sender inventory and controlled movement toward DMARC enforcement. Caveat: p=none may be an intentional transition stage. No record from external DNS tells you whether the internal project is already underway.
Segment B: gateway administration
Criteria: recognized Proofpoint, Mimecast or Hornetsecurity MX, and a customer profile suited to managed email-security services. Offer hypothesis: policy operation, integration, incident response process or migration support. Caveat: the published gateway is not proof of a contract renewal date or an operational issue.
Segment C: Microsoft 365 behind a third-party gateway
Criteria: gateway MX plus independent Microsoft signals such as Autodiscover, Entra ID and Microsoft-associated DKIM. Offer hypothesis: M365 gateway integration, authentication and migration expertise. Caveat: identity records alone are not enough, and old DNS can survive a migration.
Export the segment as a sales brief
| Column | Why it belongs |
|---|---|
| Domain and account identifier | Links the record back to CRM |
| Workspace / confidence | Distinguishes confirmed routing from inference |
| Email gateway / evidence | Shows the incumbent platform and proof |
| DMARC policy / record | Gives the precise public state |
| Observed date | Lets the rep assess freshness |
| Suggested question | Turns data into an action without claiming a vulnerability |
Execute the workflow in SecuTest
Use Find Leads when you need to discover companies from SecuTest's independently collected infrastructure data. Use Scan Prospects when you already have the domains. Filter availability depends on the product and its current dataset; verify the matching count before purchasing an export.
Test segmentation by business outcome
For each segment, track positive replies, booked discovery calls and opportunities. If one segment generates low engagement, look separately at data quality, audience fit and the proposition. Do not automatically expand the targeting condition to hide a poor conversion rate.
Segment quality check before exporting
Review a handful of accounts from each proposed segment. Are Microsoft and Google workspace assignments based on direct MX or merely on secondary identity clues? Does a secure email gateway hide the backend? Has a DMARC policy been parsed correctly, including the possibility of a subdomain rule? A segmentation rule that silently treats ambiguous signals as confirmed can produce an apparently attractive but commercially weak list.
Record both segment size and verified sample accuracy. If a particular cohort is small, that can be an advantage: a tailored offer to a few dozen genuinely relevant companies may be more valuable than a generic campaign to thousands. Conversely, if nearly every company in the market qualifies, the filter may not differentiate your offer at all.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.