How TrustSek works
You give us a domain. We collect public evidence about it, explain every finding, and turn them into a risk score you can check line by line.
Last reviewed
Check a domain
You give us a domain.
That is the only input. TrustSek scores an organisation's cyber risk from the outside in, so there are no agents to install, no integrations to set up and no credentials to hand over. The domain can be your own, a supplier's, a client's or a company you are about to insure.
A scan takes about 30 seconds, and you can watch each source report in as it finishes.
We collect the evidence from outside.
Most of the evidence is already public. A scan reads the domain's DNS records: mail, SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, nameservers and DNSSEC. It finds subdomains in certificate transparency logs and resolves them to see which are live.
To read your certificate and web configuration, it also touches your website, the way a browser would:
- DNS
- MX SPF DMARC DKIM MTA-STS TLS-RPT CAA NS DNSSEC
- TLS
- :443 · one handshake
- HTTPS
- GET / · one request
- HTTP
- GET / :80 · one request
- MTA-STS
- policy file, if published
- UA
- TrustSek/1.0
No port scans · no exploits · no crawling · no logins
That is one TLS handshake on port 443 and two requests for the home page, one over HTTPS and one over HTTP. It fetches your MTA-STS policy file if you publish one. It does not scan ports, crawl the site, submit forms or try to break in. Security lists exactly what reaches your servers and what does not.
The rest comes from third-party sources: threat-intelligence and blocklist services, two independent trackers of ransomware leak sites, vulnerability databases, internet-scanner data on open ports, and WHOIS for the domain's age. The methodology names every source and what it reads.
Evidence becomes explained findings.
Once the sources have answered, the evidence is turned into findings. A missing DMARC policy, a certificate close to expiry or an advertised software version with a known-exploited vulnerability each becomes one finding, in one of six modules.
| Module | Weight | What it looks at |
|---|---|---|
| Email securitySPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DNSSEC and nameserver redundancy. | 20% | SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DNSSEC and nameserver redundancy. |
| TLS and web hygieneWhether HTTPS is served, certificates, protocol versions and ciphers, redirects, security headers and cookie flags. | 20% | Whether HTTPS is served, certificates, protocol versions and ciphers, redirects, security headers and cookie flags. |
| Ransomware exposureClaims naming the organisation on ransomware leak sites, from two independent trackers. | 20% | Claims naming the organisation on ransomware leak sites, from two independent trackers. |
| ReputationThe domain and its addresses on threat-intel, malware, phishing and botnet lists. | 15% | The domain and its addresses on threat-intel, malware, phishing and botnet lists. |
| VulnerabilitiesAdvertised software versions matched against known-exploited and published vulnerabilities. | 15% | Advertised software versions matched against known-exploited and published vulnerabilities. |
| Attack surfaceSubdomains, high-risk hostnames, open non-web ports, domain age and lookalike domains. | 10% | Subdomains, high-risk hostnames, open non-web ports, domain age and lookalike domains. |
Every finding has a severity (Critical, High, Medium or Low) and the same four parts: what was tested, why it matters, the impact, and the steps to fix it. The person who fixes it and the person who signs it off read the same thing.
Email security · Medium severity
DMARC policy is set to none
- What was tested
- The DMARC record published at
_dmarc.example.com. - Why it matters
- Without an enforcing policy, anyone can send mail that appears to come from your domain.
- Impact
- Phishing and invoice fraud in your name, aimed at your customers and staff.
- How to fix it
- Monitor DMARC reports, then move the policy from
p=nonetop=quarantineand on top=reject.
Each module page lists the findings it can raise, most serious first. Start with email security or TLS and web hygiene, where the quickest fixes usually are.
The score is a multiplier on a baseline.
There is no mark out of 100 and no letter grade. The scoring policy starts from a 2% chance that an average organisation has a cyber incident in a year. The score multiplies that baseline: 1.0× is the baseline, where a domain with no findings lands, and 3.0× means roughly three times as likely.
Findings add to the score according to their severity, their confidence and their module's weight. A serious, well-evidenced finding, such as a recent ransomware claim, also sets a minimum score, so it cannot be averaged away by a clean record elsewhere. Every score records the policy version that produced it, so a change in the method is never mistaken for a change in the domain. The methodology has the full calculation.
Coverage shows what was not checked.
Every source ends a scan in one of four states. Found means it returned evidence. No match means it was asked and had nothing on this domain, the only state that counts as clean. Failed means it errored or timed out, and Not checked means it was never asked, for example because a licence key is not set up.
A failed or unchecked source adds nothing to the score and is never treated as a clean result. It shows up as coverage, next to the number, so you can see which evidence is missing before you rely on the score.
Confidence shows how sure the evidence is.
Some evidence is certain and some is inferred. A ransomware claim confirmed by both trackers is about as sure as outside-in evidence gets. A vulnerability matched only on an advertised version is less sure, because the server may have a backported fix.
So each finding carries a confidence, and it scales how much that finding adds to the score. The scan shows an overall confidence, High, Medium or Low, built from the confidence of its findings.
Then you put it to work.
A scan is a starting point for a conversation, a fix or a decision:
- Reports. Export a branded PDF with the score, the findings and the fixes, for a board, a client or an underwriter.
- Suppliers. Keep the vendors you depend on as scored companies, each with its own findings.
- Portfolios. See many domains side by side, to find where risk concentrates.
- API. Add companies and start scans over the public
/v1API with an API key. See developers.
When you have fixed something, start a new scan and compare. Findings also map to controls in NIS2, ISO 27001, CIS Controls and SOC 2.
example.com
3.4×Medium
- Email security2 findings
- TLS and web hygiene1 finding
- Ransomware exposureNone found
- ReputationNot checked
- Vulnerabilities3 findings
- Attack surfaceNone found
How this fits your work depends on what you own: companies scoring themselves and their suppliers, IT partners assessing clients, and insurers and brokers scoring domains at quote time.
What it does not do.
- It does not see inside. No agents, no logins, no view of your network, endpoints, MFA or backups.
- It is not a penetration test. Vulnerability findings match advertised versions against published advisories. Nothing is exploited.
- It is a scan you run, not monitoring. Domains are not watched between scans and no alerts are sent.
- It does not include breach or leaked-credential data.
- It is not an audit. Mapped controls support your compliance work; they do not prove compliance.
A scan with no findings means nothing was found in the evidence that could be seen. It does not mean the domain is secure.
See how your domain scores
Free, from public evidence. A supplier's domain works too.