An audit reads what anyone on the internet can already read about your domain, the way an attacker would start: DNS, certificate logs, the answers your servers give to every visitor, public data sets. It takes one to two minutes, attacks nothing, and every check is open source.
Six areas start together on the domain itself; the rest build on what they found. The bars show each step's usual share of the time.
Phase 1 · in parallel
Name servers, DNSSEC (missing or broken), CAA, wildcard records.
SPF counted through every include, DKIM on 54 common selectors, DMARC, MTA-STS, TLS reporting.
Names found in Certificate Transparency logs, then resolved one by one.
Up to 300 typosquatting variants: which are registered, with mail or a website, and how recently.
Buckets named after the domain on S3, Google Cloud Storage and Azure.
Expiry date and registrar, from the registry.
Phase 2 · one after the other
Certificates issued recently, and whether each issuer is allowed by your CAA record.
For each MX host: STARTTLS, the TLS handshake, the certificate, DANE.
The apex, www and every live subdomain, resolved to their addresses.
CNAMEs pointing at deleted resources on 26 providers, or at unregistered domains; dangling delegations.
HTTPS and HSTS, security headers and the quality of the CSP, cookies, outdated libraries, WordPress plugins.
Open ports and known vulnerabilities from Shodan’s existing data, ranked with CISA KEV and EPSS.
The domain and its mail and web addresses on Spamhaus blocklists.
Then every finding is compared with the previous audit: new problems, fixed ones, new subdomains, new certificates, new look-alikes. That comparison is what your alerts are made of.
Nothing an audit does would look unusual in your logs: a few DNS queries, a home page fetched, a mail server greeted. That is also why it can run on a schedule without anyone's permission being stretched.
Two things wait for the proof that a domain is yours (a TXT record): the details of the findings that would help an attacker, and the optional search for exposed sensitive files (.git, .env, backups), which you switch on per domain.
Every source is public, and here is what each one sees of an audit. No customer data is ever sent to them.
| Source | Receives | Used for |
|---|---|---|
| Public DNS resolvers (Cloudflare, Google) | Domain, subdomain and look-alike names | Every DNS check |
| crt.sh, Cert Spotter | The domain name | Subdomains, certificate monitoring |
| rdap.org and the registry | The domain name | Registration expiry, age of look-alikes |
| Shodan InternetDB | Public IP addresses | Open ports and known vulnerabilities, without scanning |
| CISA, FIRST, Wordfence | Nothing about you: public catalogues are downloaded | Ranking vulnerabilities |
| Spamhaus | The domain and its IP addresses | Blocklists |
| Amazon, Google, Microsoft storage | Bucket names derived from the domain | Cloud storage |
| Your own servers | Ordinary HTTPS requests, an SMTP greeting | Web, TLS and mail transport checks |
It starts at 100 and each finding takes off points by severity. The same issue on several hosts counts fully once, then a quarter for each repetition, so ten hosts missing one header do not sink a domain. Findings you have accepted, with a reason, do not count.
Grades: A from 90, B from 75, C from 60, D from 40, F below.
Example
No DMARC record (high, −12), two weak headers (medium, −5 each), no CAA record (low, −1): 100 − 12 − 10 − 1 = 77, grade B.
The score tracks progress over time. It is not a certification, and a perfect score does not mean nothing can go wrong.
| Severity | Points | Meaning |
|---|---|---|
| Critical | −30 | Exploitable now, serious impact: fix today |
| High | −12 | Real risk or a broken security control: fix this week |
| Medium | −5 | A weakness worth fixing soon |
| Low | −1 | Hardening and good practice |
| Info | −0 | Context, nothing to fix |
A finding that turns out to be wrong costs trust. These four cases each come from a real report we got wrong once, and fixed in the scanner for everyone.
Some networks remove STARTTLS from the conversation with every mail server. Before saying your server lacks it, we ask a reference server that always offers it; if that one looks unencrypted too, the network is the cause and you are not blamed.
Static sites often put their Content-Security-Policy in a <meta> tag. Browsers apply both the header and the tag, so we read both before calling a policy weak.
Cloudflare answers on a dozen ports for every site it serves. Those are not held against you; what is reported instead is any host that bypasses it and could reveal your origin server.
A similar name registered years ago is a neighbour, not an attacker. Severity follows the registration date and whether the domain can send mail, not mere existence.
Perimetry looks at your domain from the outside. That is where most incidents start, but not everything is visible from there.
If you handle sensitive data or must meet a security standard, pair the continuous watch with a yearly penetration test by a qualified firm.