How SignalDNS works

Enter a domain or web address and SignalDNS checks whether the site loads, its certificate, its DNS, its registration, and its email setup at the same time. The report groups the answers by the page, the website, and the domain, and says what needs attention. Slower checks, such as a page audit or a DKIM key, run when you ask. Each check also has its own tool with every detail and option, and each answer links to the part of Learn that explains it and how to fix it.

What each result means

There is no overall score. The summary counts each result and lists what to fix first, so you can see exactly why.

Evidence you can inspect

Every report shows the responses we observed, when we checked, and the region where the check ran. A failure stays a failure. An unanswered question stays unanswered.

Free for everyone

No account, ads, or subscriptions are required. We use bounded checks and fair usage limits to keep the service available. If the queue is full, we’ll ask you to try again shortly.

What a check can see

Requests come from our server. They can receive a different response from your browser or another location. We follow HTTP redirects and inspect up to 64 KiB of uncompressed HTML for meta refresh tags. We don’t execute JavaScript or render the page.

DNS

We query Cloudflare (1.1.1.1), Google (8.8.8.8), and optionally Quad9 (9.9.9.9) and OpenDNS (208.67.222.222) from our server. These are recursive, anycast resolvers, not probes in different countries. Quad9 applies security filtering. DNS differences can reflect caches, routing, or filtering; agreement is not a configuration audit.

We compare record sets without TTL or record order. Missing records, nonexistent names, and failed queries are shown separately. TTL is each resolver’s remaining cache time. When you give an expected value, we say which resolvers return it and how long the others will keep their old answer. We also ask the domain’s own name servers directly, so we can say whether each one answers, whether they agree, and whether a resolver still has an older copy. DNS checks stop after 10 seconds, with four active reports across the service.

Certificates

We inspect one address for the hostname on port 443. Hostname matching, certificate dates, and chain validation are separate checks. The report identifies the Node bundled Mozilla trust store and runtime used. Browser trust can differ. We show the negotiated protocol and cipher, and try each TLS version from 1.0 to 1.3 on its own to show which the server accepts, but not every cipher it supports.

No HTTP request, automatic issuer download, or revocation lookup is performed. Invalid certificates remain visible as evidence. TLS checks allow four active reports, at most two connections per hostname, a 10-second deadline, and 20 checks per client per minute.

Registration

We use the ICANN section of the Public Suffix List to find the registered domain, then IANA’s RDAP directory to find its registry service. Private hosting suffixes are excluded: a tenant on github.io leads to the registration for github.io. Unknown suffixes and suffixes without a supported HTTPS service are reported as unavailable.

The report shows registrar, dates, nameservers, domain status, and source information where supplied. Personal contact records and registrar referrals are not followed. Registry expiry may differ from registrar renewal dates; a 404 does not establish registration availability. DNSSEC fields are reported facts, not a live validation.

Registration checks have a 12-second deadline, four active reports, at most two outbound requests per service host, and 20 requests per client per minute. Results are cached in memory for 15 minutes with their original timestamp. A forced refresh is limited to once per domain per minute; registry retry hints still apply.

Page audit

When you ask, we fetch the page the same way the redirect tracer does, read up to 2 MB of its HTML, and read the site’s robots.txt the way Google does. The audit answers whether search engines can list the page, how its title and description look in results, whether the title, description, H1, and address agree, what a shared link shows, how the page is structured, whether its structured data parses and which search features it qualifies for, and whether its question headings have short answers.

Search cut-offs are estimates from Arial’s character widths, since Google doesn’t publish them. We don’t run JavaScript, and we name what one page can’t tell us, such as rankings or whether Google rewrites the title, instead of guessing.

Email

We look up the domain’s mail servers (MX), its SPF record, and its DMARC record, and a DKIM key when you give us a selector. SPF is followed through its includes up to the 10-lookup limit receivers enforce, and a subdomain without DMARC falls back to its parent domain’s policy, as receivers do.

A missing record is a finding; a lookup that fails is marked as not checked. We don’t send test mail, so delivery, spam filtering, and blocklists aren’t covered. Email checks have a 10-second deadline and 20 checks per client per minute.

No reports are saved

Reports aren’t stored. A share link holds the address you checked, not the results, and opening it doesn’t run the checks until you ask. In the individual tools, the full target stays with you when you switch tools, and completed summaries stay in this tab’s memory until you refresh.

Limits we keep

We limit concurrent requests, stop HTTP checks after 15 seconds in the website, and restrict requests to public HTTP/HTTPS destinations on ports 80 and 443. DNS queries go to the resolvers named above and, on port 53, to the public addresses of the domain’s own name servers. The email check also connects to its mail app names on ports 993, 465, and 995 to read their certificates. Checks don’t log in or submit forms.