How to Start a Security Conversation When a Client Thinks They're Fine

Lead with a specific, verifiable finding about their own domain. Run a DNS or TLS check on their public records before the call, and open with one misconfigured SPF record, a DMARC policy stuck at p=none, or a certificate chain missing HSTS. When the first sentence names a real problem you can see, the conversation starts from evidence, not statistics.

What finding carries enough weight to start the conversation?

Only 12.8% of domains enforce DMARC at quarantine or reject (adaptivesecurity.com), which means the prospect sitting across from you is statistically running p=none or has no policy at all. Nearly 5% of SPF-enabled domains exceed the 10-lookup limit, causing every authentication check to fail with PermError. When SPF records hit the limit, receiving servers treat authentication as invalid (sendmarc.com), which means legitimate mail gets blocked while spoofed messages flow freely.

Pick one observable DNS or TLS issue before you walk in. Check the prospect's SPF record for lookup count, pull their DMARC policy to see if it enforces anything, verify their TLS certificate expiry date, and look for missing HSTS or CSP headers. Every one of these checks takes 60 seconds with the right tooling, and the free AI-visibility check (/check) runs the full audit with no signup required.

The finding has to be specific enough that they cannot dismiss it. "Your DMARC policy is set to p=none, which means it monitors spoofing attempts but takes no action" is a fact they can verify in their own DNS. "Your SPF record includes 12 DNS lookups, two over the RFC limit" is not an opinion. Nearly half of domains with DMARC records do not include a rua tag (fortra.com), so they are not receiving the aggregate reports that would tell them authentication is failing.

Why does a verifiable finding work better than breach statistics?

Clients who think they are fine have already tuned out the industry numbers. They have heard that ransomware costs millions, that phishing is up, and that SMBs are targets. None of it feels real until you show them something broken in their own infrastructure.

First-time risk assessments uncover surprises because results are not what clients expect (mspsuccess.com), such as finding unencrypted devices when the client believed everything was encrypted. Nearly half of IT businesses say clients do not completely trust their MSP's security (goodreads.com), which points to a disconnect between what MSPs are doing and what clients think is happening.

A verifiable finding closes that gap immediately. When you open with their own domain name and a specific DNS record, the conversation shifts from hypothetical risk to concrete remediation. The client cannot argue with their own TXT record.

Procurement and compliance teams already operate this way. Vendor security assessments ask for evidence of access control policies and recent reviews (wolfia.com), and questionnaires demand documented security policies and current audit reports (copla.com). If your prospect sells to regulated industries or enterprise buyers, they are answering these questions from their own customers every quarter. Showing them a gap in their own posture before their next audit surfaces it gives you a credible reason to be in the room.

How to position the finding without sounding like a sales pitch

Do not lead with a solution. Lead with the observation, let them confirm it, and then ask what happens if a customer or auditor notices the same thing.

"I ran a quick check on your domain yesterday and saw your DMARC policy is set to p=none. That means you are monitoring for spoofed email but not blocking it. Is that intentional, or is this something that has been on the list to tighten up?"

The phrasing matters. You are not diagnosing a crisis or implying negligence. You are surfacing a configuration detail and asking whether it matches their intent. Most of the time, they did not know the policy was in monitoring mode, or they set it that way years ago and never moved to enforcement. Organizations hesitate to move beyond p=none because a single misconfigured sender can break delivery, and more than half of domains publishing DMARC remain stuck at p=none years after adoption.

Once they confirm the finding is real, ask what their customers or compliance auditors would say if they pulled the same record. Weak email authentication creates downstream risk for partners, customers, and the supply chain, which makes this a vendor accountability issue as much as an internal security one.

What to check before the meeting

Pull their public DNS records and TLS certificate details. You need the SPF record, the DMARC policy, the DKIM selector if you can identify it, and the certificate chain for their main domain. Count the DNS lookups in the SPF record manually or with a validation tool. Note the DMARC policy level (none, quarantine, or reject) and whether a rua or ruf tag is present. Check the certificate expiry date and whether HSTS or CSP headers are set.

The average global enterprise spends about $15 million to recover from a certificate outage, and expired certificates cause service outages, reputational damage, and loss of customer trust. If their certificate expires in 30 days and they have no monitoring in place, that is a concrete risk with a deadline. Businesses face downtime because no one noticed a certificate was close to expiring, and manual tracking becomes difficult as organizations manage multiple domains and cloud environments.

Document what you find in a one-page summary with the exact DNS record or header value, the date you pulled it, and the specific risk or compliance implication. Bring that page to the meeting. When they ask how you know, you hand them the evidence.

Offering ActiScore's pricing (/pricing) at this stage makes sense only if they ask what tool you used to pull the data. The goal of the conversation is to establish that a verifiable problem exists and that they care enough to fix it. The tooling question comes after they agree the finding matters.

If they have already scanned their own domain and know their posture is clean, lead instead with AI visibility. Run their business name through the guide (/guide) for how Claude, ChatGPT, Gemini, and Perplexity answer "Who should I hire for [their service category] in [their geography]?" If their competitors appear in those results and they do not, that is a different but equally verifiable gap. A client who thinks their security is fine may still care that AI assistants are not recommending them.