Your first SSLBoard scan

Type a domain, wait about a minute, and get an inventory of every public host SSLBoard could find and what each one is serving. No agent, no credentials.

Your main site almost certainly works. You would have noticed if it did not. The interesting question is what the other twenty names on your domain are doing: the staging box someone set up in 2021, the IPv6 address that never got the new certificate, the mail server nobody has logged into since the migration.

SSLBoard answers that question in about a minute, from the outside, with no access to your servers.

Run a scan

Go to sslboard.com and type the domain, for example example.com. Not a URL, not a hostname: the registrable domain.
Clear the browser check if you get one, then start the scan.
Watch discovery run first, then inspection. Discovery collects names to try; inspection connects to them.
Open the report and read the priority findings from the top.

That is the whole setup. You do not install an agent, upload a private key, or open a firewall rule.

What you get back

The report covers	Which answers
Deployed certificates, expiry, issuers	What is actually being served, right now, on each address
TLS versions and cipher suites	Whether a 2014-era protocol is still reachable
Forward secrecy and key profiles	Whether recorded traffic stays safe if a key leaks later
HTTP redirects, HSTS, security headers	What a browser is told to do before it trusts you
DNSSEC, CAA	Whether DNS answers and certificate issuance are constrained
Mail routing, STARTTLS, SPF, DMARC, MTA-STS, DANE	Whether mail to and from you is protected in transit and hard to spoof
Connection failures	Where the scan could not establish anything, and why

That last row matters more than it looks. A check that could not run is not a check that passed. Missing, failed, and inconclusive results explains how to tell them apart.

Fix one thing, not everything

The most common mistake is treating the report as a scorecard to grind upward. It is more useful as a to-do list sorted by blast radius.

Say the report shows an expired certificate on old.example.com while www.example.com is clean. The useful sequence is: decide whether old is still needed, find where its TLS connection actually terminates (often not where you think), then either replace the certificate there or retire the service. Retest and confirm the endpoint now serves what you intended.

One finding closed end to end beats five categories nudged upward.

What a scan is not

It is a point-in-time observation of your public surface. It does not test your application for vulnerabilities, it does not log in to anything, and it does not certify you against a compliance framework. If a check has no usable evidence, the report says so rather than guessing.

Next: how SSLBoard gets its data, or skip ahead to reading your report.

Questions people ask

Do I need to install anything or give SSLBoard server access?

No. You give SSLBoard a domain name. Everything it reports comes from public certificate records, public DNS, and connections to services you already expose to the internet. There is no agent, no API key, and no access to your private keys.

How long does a scan take?

Most domains finish in about a minute. Domains with hundreds of discovered hostnames take longer, because every hostname is resolved and connected to individually.

Is the free scan enough to fix something?

Often yes for a small domain. The free summary gives you the score, the findings, the counts, and example evidence. The full report adds the complete affected-host list, which is what you need when a finding covers more than the one endpoint shown in the example.