What the check runs
The all-in-one check takes a domain name and runs nine lookups at the same time from DechoNet’s servers, not from your browser. Each one is the same lookup as the separate tool, and each panel links to that tool for detail.
| Area | What it looks at | What it reports as a problem |
|---|---|---|
| RDAP | Registration record: registrar, status, expiry date | Expiry within 30 days or client hold (warning); pending delete (critical) |
| DNS | A/AAAA, MX, SPF, DMARC, DNSSEC; compares answers across resolvers | No A/AAAA record (critical); no MX, SPF or DMARC, or resolvers disagreeing on the A record (warning) |
| SSL | The certificate on port 443 of the name you entered | Expired, untrusted chain, or TLS 1.0/1.1 (critical); expiring within 30 days, name not covered, no HSTS (warning) |
| HTTP | https:// plus the name, following up to 10 redirects | Connection failure, redirect loop, 502 or 503 (critical); 3+ redirects, 403, 404, missing or weak CSP, missing HSTS, a Server or X-Powered-By header (warning) |
| MX, SPF syntax and lookup count, DMARC policy, DKIM at common selectors, blocklists for the mail servers | No MX or a listed mail server (critical); missing SPF/DKIM/DMARC, DMARC p=none, too many SPF lookups (warning) | |
| Propagation | The A record at six public resolvers | No records anywhere (critical); inconsistent answers (warning) |
| Ports | 15 common TCP ports | FTP 21, SMTP 25, MySQL 3306, PostgreSQL 5432 or RDP 3389 open (warning) |
| Reverse DNS | PTR record of the first IP address | No PTR, or PTR that doesn’t resolve back (warning) |
| ASN | Network and announced prefixes of the first IP | Network not found (critical); no announced prefixes (warning) |
A lot of other things appear in the panels as notes (no DNSSEC, slow first response, no compression, no MTA-STS or BIMI, a cloud hosting network). Those are information and don’t change the score.
How the score is calculated
Every area has a weight, and the weights add up to 100:
| DNS | SSL | HTTP | RDAP | Propagation | Ports | Reverse DNS | ASN | |
|---|---|---|---|---|---|---|---|---|
| 18 | 18 | 14 | 14 | 10 | 8 | 8 | 5 | 5 |
Within an area, each critical issue takes away 40% of the area’s weight and each warning 15%. Information notes take away nothing. The total loss for the area is rounded and capped at the area’s weight, so one area can never cost more than its own share. If an area returned only partial data, a further 10% of its weight comes off. If an area’s lookup failed completely, the whole weight is lost and the score is labelled incomplete. An area that cannot apply to the domain at all is shown as N/A and left out: the remaining weights are rescaled to 100, so a domain is neither punished nor rewarded for something it can’t have.
Some worked numbers:
- A missing HSTS header is found twice: by the SSL check (18 × 15% = 2.7, rounded to 3) and by the HTTP check (14 × 15% = 2.1, rounded to 2). Total: 5 points.
- A missing DMARC record costs 3 in DNS and 2 in Email, another 5.
- An HTTP response with no CSP, no HSTS and a
Serverheader has three warnings: 14 × 45% = 6.3, so 6 points. - An expired certificate is one critical issue in SSL: 18 × 40% = 7.2, so 7 points.
The score maps to a grade: A+ from 90, A from 80, B from 70, C from 50, D from 40, F below that. The page itself labels the score Excellent (90+), Good (70+), Fair (50+) or Poor, and the grade letter appears in the share text. The Score Breakdown table under the score shows each area’s weight, what it kept and what it lost.
The remote MCP server’s security_scan tool uses the same weights and cut-offs, so an AI agent reporting a grade and the web page give the same number.
Reading the result honestly
One problem, two deductions
Because the areas overlap, a single gap can show up twice: HSTS in SSL and HTTP, SPF and DMARC in DNS and Email. That’s not a bug in your setup. Fix the one thing and both deductions go away.
Domains that don’t handle mail
The scoring assumes a domain both serves a website and sends or receives mail. A domain with no MX record gets a warning in DNS and a critical issue in Email, plus the SPF and DMARC findings in both. A web-only domain will not reach the top grade, and that’s fine as long as you know why.
What a domain that never sends mail should publish is a defensive SPF record (v=spf1 -all) and a DMARC record with p=reject, so nobody can send convincing mail in its name. A null MX record (MX 0 ., RFC 7505) additionally says the domain accepts no mail. Do those for the protection, not for the score.
Incomplete and partial results
When a panel shows an error instead of a result, that area counts as fully lost. The usual reason is a temporary failure or rate limit: nine lookups at once can trip a limit or catch an upstream service having a bad minute. Run the check again a minute later.
Two situations are not failures and are marked N/A instead (left out of the score, as described above):
- The registry offers no RDAP service. Several country-code TLDs (.de and .jp, for example) don’t run RDAP, so there is nothing to look up for any domain under them.
- No A or AAAA record. Reverse DNS and ASN need an IP address. Without one they can’t run; the missing record is already counted once, as a DNS critical issue.
Some sites, many Korean public-sector sites among them, drop connections from foreign IP addresses. DechoNet’s main servers are outside Korea, so for SSL and HTTP it retries from a server in Seoul and says so in the result.
Cached answers
Recent results are reused for a while to keep the service fast: ports for 2 minutes, HTTP and propagation for 5, DNS, email and reverse DNS for 10, RDAP and ASN for an hour, and SSL for up to 24 hours. A panel served from cache shows when it was taken. After renewing a certificate, the SSL panel can show the old one until its cached entry expires; the change itself has worked if openssl s_client -connect example.com:443 -servername example.com shows the new dates.
What it can’t see
- Other names. It checks the name you type.
example.comandwww.example.comcan have different certificates, servers and records; run both. Other subdomains aren’t checked at all; subdomain discovery lists the ones visible in certificate logs. - Other servers. Reverse DNS and ASN use the first address in DNS only. If you have several origins or a load balancer pool, the rest go unchecked, and one broken server can hide behind a healthy first address.
- Anything inside your network. Lookups come from DechoNet’s servers through public resolvers. Split-horizon DNS, your office resolver, a VPN or a corporate proxy are invisible to it.
- The application. It doesn’t look for vulnerable CMS plugins, injection bugs, weak logins or exposed admin pages. For the last one, use the exposed admin page check.
- Certificate revocation. A revoked certificate that is otherwise valid passes.
- DKIM selectors it didn’t guess. DKIM keys live at names only the sender knows. “No DKIM found” can mean your provider uses a selector the check didn’t try; confirm against a real message’s
DKIM-Signatureheader. - Header quality. The header part of the HTTP grade checks presence and a few obvious weaknesses. A CSP that allows everything still counts as present. The security headers guide explains what a useful policy looks like.
- Speed. Response time and compression appear in the HTTP panel as notes but don’t affect the score.
When the site is down
During an outage the score is the least useful number on the page. Read the panels in layer order instead, because the first layer that fails usually explains every failure after it:
- RDAP. Expired, on hold, or pending delete? Nothing else will work until the registration is fixed. See domain expiry, hold and pending delete.
- DNS and Propagation. No A/AAAA record, or resolvers disagreeing? Browsers will show a name resolution error. See ERR_NAME_NOT_RESOLVED and DNS propagation delay.
- SSL. Connection failed, expired, or untrusted chain? Browsers will show a certificate warning. See the SSL expiry checklist and ERR_CERT_AUTHORITY_INVALID.
- HTTP. Connection failed, a redirect loop, or a 5xx code? The server or the proxy in front of it is the problem. See redirect loops and 502 Bad Gateway.
If everything is green and some users still can’t reach the site, the problem is probably on their side or regional: a stale resolver cache, an ISP, a VPN or a security product. Compare resolvers with the propagation check and ask for the exact error message and the time it happened.
Acting on the result
The Priority Actions list under the score shows up to five items from areas with critical or warning issues, criticals first. A sensible order:
- Today: anything critical. An expiring domain or certificate, a broken chain, a missing A record, 5xx responses. These affect visitors now or soon.
- This week: cheap warnings with real protective value. HSTS, an SPF record, a DMARC record at
p=nonewith reporting so you can move to enforcement later (see DMARC policies). - Planned work: CSP, which needs testing in Report-Only first, and risky open ports, which need someone to confirm what the service is for (see risky open ports). An open port 25 on a host that is your mail server is expected; the check flags it so you confirm it, not because it’s wrong.
- Optional: information notes.
After fixing something, run the check again, keeping the cache times above in mind. Copy Markdown puts the score, area statuses and priority actions in a form you can paste into a ticket.
Check your own domain now
Free, no sign-up. Runs the exact check this guide describes and shows what to fix.