There is a version of your security programme that you do not control the distribution of. It is the version a stranger can assemble in about two minutes, using nothing but your domain name and publicly available records. No login, no permission, no notification to you that it happened.
This is your external security posture. It is not the whole picture - it is not even most of it - but it is the part that gets looked at first, and often the part that forms an impression before anyone reads a word of your documentation.
This piece maps that surface: what it consists of, what each signal actually tells someone, and where the boundary sits between what is observable and what is not.
What "externally observable" actually means
A signal is externally observable if someone can retrieve it without authenticating as you or to you. In practice that means three sources:
- DNS. Your public records: mail routing, email authentication policy, certificate issuance policy, and every hostname that has ever been published. DNS is a public directory by design.
- The TLS handshake. Before a single byte of your page loads, your server presents a certificate stating who issued it, what names it covers, and when it expires. It also negotiates which protocol versions and ciphers it is willing to accept.
- The HTTP response. Your headers, your cookies, and the HTML and JavaScript you serve to anyone who asks - including whatever is accidentally in them.
Everything else - who has access to production, whether backups restore, how you handle an incident, which vendors touch customer data - lives behind a login or inside a document. No external scan reaches it. That distinction matters more than any individual finding, and we will come back to it.
The six signals worth understanding
1. TLS configuration
Your certificate answers three questions immediately: is it valid, who vouched for it, and when does it expire. A lapsed certificate does not degrade gracefully - browsers present a full-page interstitial warning, and API clients simply refuse to connect. Login stops. Checkout stops. Integrations stop.
Beyond validity, the handshake reveals which protocol versions you still accept. TLS 1.0 and 1.1 are deprecated and should be off. Whether HTTP redirects to HTTPS is equally visible, and equally telling.
We wrote about the specifics in expiring and weak TLS.
2. Email authentication
SPF, DKIM and DMARC are DNS records that tell receiving mail servers which systems are allowed to send as your domain, and what to do with messages that fail the test. Their absence is publicly checkable in seconds, and it is one of the few external findings with a direct, well-understood attack attached to it: without a DMARC policy, someone spoofing your domain is materially easier to pull off and harder to stop.
This is the single highest-value item on most external reports, because the fix is a DNS change rather than an engineering project. See SPF, DKIM and DMARC explained.
3. HTTP security headers
Headers are instructions your server sends to the visitor's browser about how to treat your site: whether to allow framing, whether to guess at content types, how much referrer information to leak, which sources may execute scripts. They are browser-side protections, which means they cost nothing at runtime and are trivially easy to omit entirely.
Their absence is not itself a breach. It is a missing layer, and a visible signal about whether anyone has done a structured pass over the basics. Covered in the security headers that actually matter.
4. Subdomain exposure
Every publicly trusted TLS certificate is logged to Certificate Transparency, an append-only public record designed to catch mis-issuance. A useful side effect: anyone can enumerate the hostnames you have ever requested certificates for, including internal-sounding ones you assumed nobody knew about.
The risk is not the list itself. It is the entries pointing at services you decommissioned, where the DNS record outlived the thing it pointed to. See subdomain takeover and dangling DNS.
5. Exposed assets and secrets
Your public HTML and JavaScript are readable by everyone, which makes them a poor place for API keys - and yet keys end up there regularly, usually through a build process that bundles a server-side environment variable into a client-side file. The same category covers files that should not be web-reachable at all, like a deployed .git directory or a stray .env.
More on this in exposed secrets in public code.
6. Cookies, CORS and technology fingerprint
Smaller signals that still say something. Cookie flags - Secure, HttpOnly, SameSite - determine whether a session cookie can be read by page scripts or sent over plain HTTP. A permissive Access-Control-Allow-Origin header tells the browser which other sites may read your responses. And version numbers in your Server or X-Powered-By headers make it easier to match your stack against a list of known vulnerabilities.
None of these is dramatic alone. Together they indicate whether someone has been through the configuration deliberately.
How the signals relate to each other
Read individually, each finding is a small technical fact. Read together, they answer a different question: has anyone been through this deliberately?
That is why a report with six passes and four warnings often tells you more than the individual items suggest. Headers, cookie flags and a CAA record are all one-line changes. A domain where all three are missing is rarely a domain where someone decided against them - it is usually a domain nobody has audited. Conversely, a site with a carefully scoped Content-Security-Policy almost certainly has someone who thinks about this.
The corollary matters for how you read your own report: the individual fixes are quick, but the useful outcome is the habit of checking, because the surface changes underneath you. A new subdomain, a new third-party script, a certificate renewed by a different mechanism - each one moves the picture without anyone intending it to.
Where external scanning gets it wrong
Since this piece is partly about how to read a scan, it is worth being direct about how scans fail - including ours, before we fixed it.
A blocked scan can look like a clean one. If a scanner requests your homepage and gets a 403 from a WAF, the response still has a body. A naive implementation reads that body, finds no third-party scripts and no exposed keys in it, and reports both as passes. They are not passes. They are a page that was never yours being audited as though it were. Any check that reads page content needs to treat a non-2xx response as "no evidence", not as "nothing found".
Thin coverage can produce a flattering grade. If eight checks fail to complete and the two that ran happened to pass, a grade computed only over completed checks reports a perfect score. The site that blocked the most checks gets the best result. Grading needs a coverage floor, below which the honest output is no grade at all.
Records get looked up in the wrong place. SPF, DMARC and CAA are published on the registrable domain, not on each hostname. A scanner that queries www.yourdomain.com for them finds nothing and reports your email authentication as absent, when it is published correctly one level up.
Self-scanning is unreliable. When a server requests its own domain, the request often loops back internally and lands somewhere other than the public site. Whatever tool you use, the most trustworthy check of your domain is one run from somewhere else entirely.
The practical advice: when a report says "undetermined", read it as information rather than noise. It usually means something about your infrastructure - a bot rule, a blocked lookup, a redirect - that is worth understanding in its own right.
What none of it tells you
This is why we are careful about what a report claims. An external scan covers roughly a fifth of what a SOC 2 audit examines, and the interesting fifth is not the one that gets audited hardest. The other four fifths - access reviews, backup testing, incident response, change management, vendor due diligence - require evidence from inside your systems.
We wrote about that split in the 80% a domain scan can't see, and about why we refuse to dress a scan up as a certificate in why we'll never call this a SOC 2 certificate.
How to check yours
You can do all of this by hand. dig will show your DNS records. openssl s_client will show your certificate and negotiated protocol. curl -I will show your response headers. A Certificate Transparency search will list your subdomains. Reading your own page source will reveal what is bundled into it.
The reason to use a tool instead is consistency: running the same checks the same way every time, so you notice when something changes. The reason to be sceptical of tools is that a scanner which cannot reach your site will sometimes report that as good news rather than as no news.
Whatever you use, the sequence that produces results is the same:
- Fix what is failing outright before anything else. A missing DMARC record or an exposed key is a live problem.
- Work the warnings - a missing CAA record, a cookie without
SameSite- which are usually minutes of work each. - Re-check after every infrastructure change. The findings that hurt are almost always the ones introduced after the last clean report.
- Treat the result as a floor. A clean external surface is table stakes, not evidence of a mature programme.
The goal is not the grade. It is knowing what your domain says about you before someone else reads it out loud.