Is it legal or ethical to check a prospect's domain before they're a client?

A passive check only reads records the business has published publicly, like DNS and certificate logs, plus one ordinary homepage visit. It doesn't test or probe their systems. Keep it to public data, and be open with the prospect about what you looked at and how.

How long does a passive assessment take?

With a tool, the lookups take seconds. Most of the time goes into sorting the findings and picking the one or two worth raising. Doing it by hand with DNS lookup tools takes longer, especially for SPF lookup counts.

What can't a passive assessment tell me?

Anything inside the network or behind a login: multi-factor authentication, endpoint protection, backups, patching, and staff training. Those need a conversation or an internal assessment once the prospect agrees.

Should I send the findings before the first call?

It depends on the relationship. For a warm introduction, a short summary before the call can work well. For a cold prospect, it's often better to mention one finding on the call and offer to send the summary afterward.

How to run a passive security assessment on a prospect before the first call

Published November 12, 2026

Most first calls with a prospect start the same way. You ask how things are going with IT, they say "fine," and the conversation stalls. A short look at their public setup before the call gives you something specific to talk about, and it shows you did your homework.

This post covers what a passive assessment is, which public signals are worth reading, how to sort what you find, and how to bring it up without sounding like you're selling fear.

What "passive" means, and why it matters

A passive assessment reads only information the business has already published to the internet. In practice that means four sources:

DNS records, such as SPF, DKIM, DMARC, MTA-STS, TLS reporting, MX, DNSSEC, and CAA
Certificate transparency logs, the public logs that certificate authorities write to when they issue a certificate (RFC 6962)
Domain registration data, available through RDAP, including the expiry date
One normal visit to the homepage, the same request any visitor's browser makes

There's no port scanning, no login attempts, and no vulnerability probing. That's what makes it reasonable to do before someone is a client. You're reading the same public records any mail server or browser reads every day.

It's also worth being clear about what a passive check isn't. It isn't a penetration test, a vulnerability scan, or a compliance assessment. It can't see endpoints, backups, or whether staff use multi-factor authentication. Say that up front, and prospects tend to trust the rest of what you tell them.

The signals worth reading

You don't need to cover everything. These are the areas that are easy to explain and tend to matter to a small business owner.

Email authentication

Email is usually the best place to start, because the problems are visible from outside and the business impact is easy to explain: someone can send a fake invoice that looks like it came from them.

SPF (RFC 7208): Is there exactly one SPF record? Does it stay under the 10 DNS lookup limit? Does it end in ~all or -all?
DKIM (RFC 6376): Can you find a published key for the services that send their mail? Keep in mind that DKIM selectors can't be listed from DNS, so a miss on common selectors means "unknown," not "missing."
DMARC (RFC 9989): Is there a record at all? Is the policy p=none (monitoring only), quarantine, or reject? Is there an rua address, so someone actually receives the reports?

Encrypted mail delivery

MTA-STS (RFC 8461) and TLS reporting (RFC 8460) tell sending servers to require encryption when delivering to the domain, and send reports when that fails. Most small businesses don't have them. That's a useful finding to have, but it isn't something to lead with.

Website and certificate basics

From the single homepage visit you can see whether the certificate is valid and not close to expiring, whether http:// redirects to https://, which security headers are set, and whether the server announces software versions in its headers.

Domain hygiene

The registration expiry date, whether DNSSEC is signed, and whether CAA records limit which certificate authorities can issue certificates for the domain. An expiring domain is one of the few findings that's both urgent and easy for anyone to understand.

Hostnames in certificate logs

Certificate transparency logs show hostnames the business has requested certificates for, such as vpn., staging., or old.. That's a good prompt for a question ("Is the staging site still in use?"), not proof of a problem.

Sort what you find before you call

A raw list of findings isn't useful to the prospect. Before the call, sort everything into three groups:

Verified gaps. Things the public data clearly shows, like no DMARC record, an SPF record over the lookup limit, or a certificate that expires in two weeks.
Unknowns. Things you couldn't confirm from outside, like DKIM on a selector you didn't guess, or whether there's an email filter that doesn't show in MX records. Don't present these as failures.
What's already working. Lead with one or two of these. It shows you're being fair, and it makes the gaps easier to hear.

Then pick the one or two verified gaps that are easiest to explain and that the business would care about. For most small businesses, that's email spoofing or an expiring domain or certificate.

How to bring it up on the call

Keep it short and factual. Something like this works:

"Before we talked, I looked at your domain's public records, the same ones any mail server checks. A couple of things stood out. Your email is set up so that mailbox providers are told to only monitor fake messages using your name, not block them. That's a fairly common setup and it's fixable. Want me to send you a one-page summary?"

A few things to avoid:

Don't claim a breach or attack. A missing record means the door isn't locked, not that anyone walked through it.
Don't oversell unknowns. If you couldn't confirm something, say so.
Don't read the whole list. One or two findings start a conversation. Twenty end it.

After the call

If the prospect is interested, follow up the same day with a short written summary: what's working, what isn't, and how you'd fix it. The sample Security Brief shows one format for that. Keep the technical detail in an appendix for whoever handles their IT.

If you're building a whole list of prospects rather than preparing for one call, weeks 3 and 4 of our free MSP playbook cover building a prospect list and sending short briefs and following up fast.

FAQ

Is it legal or ethical to check a prospect's domain before they're a client?: A passive check only reads records the business has published publicly, like DNS and certificate logs, plus one ordinary homepage visit. It doesn't test or probe their systems. Keep it to public data, and be open with the prospect about what you looked at and how.
How long does a passive assessment take?: With a tool, the lookups take seconds. Most of the time goes into sorting the findings and picking the one or two worth raising. Doing it by hand with DNS lookup tools takes longer, especially for SPF lookup counts.
What can't a passive assessment tell me?: Anything inside the network or behind a login: multi-factor authentication, endpoint protection, backups, patching, and staff training. Those need a conversation or an internal assessment once the prospect agrees.
Should I send the findings before the first call?: It depends on the relationship. For a warm introduction, a short summary before the call can work well. For a cold prospect, it's often better to mention one finding on the call and offer to send the summary afterward.

Try it on a domain

You can run a free passive check of a domain's email setup with the email security grade tool, or run a full free scan from the Client Posture homepage to see every check described above in one report.