How to Build a Targeted MSP Prospect List Using DNS and Email Security Data

The fastest way to make a lead list more useful is to connect each domain to a specific, defensible service hypothesis.

Define the exact list you need

Suppose your MSP manages Microsoft 365 email and supports DMARC deployments. Your first targeting brief could be: business domains in your service region, with Microsoft 365 evidence, a DMARC policy of p=none, and no publicly recognized secure email gateway. This is a candidate segment, not a list of insecure companies. Native Microsoft protection and API-based controls may not be visible in MX.

Put the hypothesis in writing before you use any filter. Without an explicit hypothesis, adding more technology columns produces a busy spreadsheet rather than a sales list.

Collect domains separately from their infrastructure signals

Company domains are identifiers. Workspace, SPF, DMARC and MX are observations that can change. Keep both dimensions separate. A good working file includes domain, company, country, source, observed_at, workspace, workspace_confidence, email_gateway, dmarc_policy and next_action.

If you start from your own CRM export, preserve the original account ID and do not silently deduplicate separate company records into one contact. Deduplicate the scan input by normalized domain, but keep the account-to-domain relationship in your CRM.

Verify detection with DNS evidence

A direct Microsoft MX, for example, often ends in mail.protection.outlook.com. A third-party MX points to the gateway, not necessarily to the mailbox platform behind it. Check supporting Autodiscover and DKIM evidence before classifying Microsoft 365 behind a gateway.

dig +short MX example.com
dig +short TXT _dmarc.example.com
dig +short TXT example.com

These are illustrative commands. A response can contain unrelated TXT records; SPF must be identified by its v=spf1 prefix. DNS failures are not the same as a verified absence of a record.

Build an export a salesperson can use

Move beyond a bare list of URLs. Include technology observations, classification confidence, source records, collection date and one suggested discovery question. A simple Sell Next column is a sales hypothesis, not a promise that the buyer needs the service.

Pick the right SecuTest workflow

Use Scan Prospects when you already possess the target domains. Use Find Leads when you want a one-shot list built from the infrastructure data SecuTest has independently collected. Available filters and matching counts must be confirmed in the product before promising a segment to a client.

Validate a sample before scaling

Manually audit a small random sample and several ambiguous cases. Track the percentage of records with a usable signal, incorrect classifications and unknown backends. Then test one concise outreach angle. Improve the filter only after you have feedback from real conversations. Data accuracy and offer relevance both affect conversion.

Example: from an anonymous record to a reviewable account

Imagine sample-company.example publishes a third-party gateway MX and a DMARC policy of p=none. A raw enrichment export might display a guessed Microsoft workspace, an email-security vendor and a generic "DMARC gap". A better record retains the actual gateway MX, the parsed DMARC record, the date and a workspace state of unknown until independent evidence is confirmed. The account receives a note: "Potential DMARC reporting / enforcement discussion, subject to validation."

This distinction matters when the file is handed to a salesperson. They should see exactly what is observable and what is inferred. If the MX changes before the first outreach, the record should be refreshed. The exercise is not to maximize filled cells: it is to avoid presenting uncertainty as fact.