Passive security assessments: what you can check before a prospect says yes

Before a prospect has signed anything, you have no permission to test their systems. You can, however, read everything their domain publishes so that email and the web can work. That public information says a surprising amount about how a business looks after its technology. This post explains what a passive assessment covers, where it stops, and how to use it in sales without overstepping.

Passive, active and authorised: the three levels

The line is about intent and behaviour: are you using a service the way it is offered to everyone (looking up a DNS record, loading a homepage), or sending traffic designed to find weaknesses? Port scans, login attempts, directory brute-forcing and crawling are on the wrong side of that line for a prospect.

What a passive assessment can see

Email

• DMARC: whether the domain tells receivers to reject email that fails authentication, and whether anyone receives the reports.
• SPF: which services may send for the domain, and whether the record breaks the 10-lookup limit.
• DKIM: whether signing keys exist on the selectors the detected mail provider uses (custom selectors cannot be listed, see how to find a DKIM selector).
• Mail provider, MTA-STS and TLS reporting.

Website and certificates

• Whether HTTPS works, whether HTTP redirects to it, and whether browsers trust the certificate.
• Certificate issuer, expiry, covered names and whether it renews automatically, from public certificate transparency logs.
• Security headers on the homepage response, mixed content and cookie flags. See security headers explained.
• Software versions the site advertises publicly, such as a CMS generator tag.

Domain and DNS

• Registrar, domain age, expiry date and transfer lock, from the public registration database (RDAP).
• DNSSEC, CAA records and the DNS host. See the domain and DNS security checklist.

What it cannot see

• Whether staff use multi-factor authentication, how backups work, or whether devices are patched.
• Whether a mailbox has been compromised or a breach has happened.
• Whether an advertised software version is actually exploitable on that server.
• Anything behind a login, on internal networks or in cloud admin settings.

Say this out loud in sales conversations. "This is what your business shows the internet. The inside needs a proper review" is honest, and it naturally leads to the paid assessment.

Why the public basics are a useful signal

External settings are not the whole picture, but they are not random either. A domain with an enforced DMARC policy, automatic certificate renewal and a locked registrar usually belongs to a business where someone is paying attention. A domain with none of them often has gaps inside too. That makes a passive check a good way to prioritise a prospect list and to choose your opening.

Using it in a sales process

1. Before first contact: check the domain and pick the single clearest gap to mention.
2. In the first meeting: walk through the report, rank the findings honestly, and explain what you cannot see from outside.
3. In the proposal: turn each external gap into a scoped fix, and propose an authorised internal review as the next phase.
4. After you win: re-check every quarter, or watch the domain weekly, and show the client what has improved.

How Hookgap stays passive

Hookgap makes DNS lookups through a public resolver, reads certificate transparency logs and RDAP, and makes one request each to the homepage, security.txt and (where announced) the MTA-STS policy file. It follows at most three redirects, reads at most 100 KB and identifies itself as HookgapBot. It never scans ports, tries logins or crawls. The details are on how a check works and the HookgapBot page.