How to interpret your website check
Last updated 2026-09-07
Start with the failing service, not the score
WebsiteInfo reads public DNS records, connects to TLS and HTTP services, and inspects selected public files. It is an outside view of a domain at the time shown in the report. It does not log into your server, inspect application source, or prove that a business is trustworthy. A high score cannot establish that a site is safe to buy from.
If visitors cannot open the site, check DNS, the certificate and the redirect destination first. If outgoing mail fails, inspect SPF, DKIM and DMARC together. If the site works and only a header is missing, review what that header would change before deploying it. These are different problems and should not be treated as equally urgent.
Worked example: DMARC exists, but mail still fails
Suppose the DNS record says v=DMARC1; p=reject and a newsletter service still sends mail to spam. Finding that record establishes a published policy; it does not prove that the newsletter passes authentication. In a delivered test message, open the original headers and inspect Authentication-Results, the visible From domain, and the DKIM signing domain.
DMARC requires a passing SPF or DKIM result aligned with the visible From domain. An SPF pass for a different return-path domain alone is insufficient. Before tightening policy, inventory every legitimate sender, including contact forms, billing systems and newsletters. Confirm alignment for each sender and review aggregate reports. This example is hypothetical, not a test of your domain.
DKIM: not found is not the same as absent
This checker looks for eight selector names: google, default, selector1, selector2, k1, mail, dkim and s1. Providers can choose other names. No result means none of those names yielded a TXT answer; it does not establish that DKIM is disabled. Likewise, a DNS key does not prove that outgoing messages are being signed correctly.
Find s= and d= in the DKIM-Signature header of a real message. With dig installed, query dig +short TXT SELECTOR._domainkey.DOMAIN, replacing both placeholders with those values. Compare the receiver’s Authentication-Results with the provider’s setup instructions. Never paste a private signing key into a public tool.
DNS differences and cache age
The propagation check compares A-record answers from Google, Cloudflare, Quad9 and KT. That is a sample of four resolvers, not a worldwide survey. A CDN can deliberately return different addresses by location. Compare the addresses with your intended hosting configuration before declaring that propagation failed.
Reports less than one hour old are normally reused. Check the report timestamp after changing DNS and use the refresh control when you need a new query. Even a fresh WebsiteInfo query may encounter a resolver’s cached answer until its DNS TTL expires. Under a global request limit, an older stored report can be shown; its timestamp matters more than when you opened the page.
The DNSSEC row detects a DS record. That is an indication of configuration, not a full validation of the chain of trust or every signed answer. Investigate DNSSEC errors with your DNS operator instead of repeatedly switching signing off and on.
TLS and redirects: which server did we see?
A CDN can terminate HTTPS before a request reaches your origin. The public certificate then belongs to the connection visitors make to the CDN. It does not tell you whether the separate CDN-to-origin certificate is valid. Check both sides in the hosting control panel if the CDN reports an origin TLS error.
When the report names a redirect destination, compare it with your intended canonical host. Test both the bare domain and www if you use both. A successful handshake from this server does not prove compatibility with every client or every TLS version.
Headers: presence is only the first check
The header rows primarily check whether selected headers exist on the inspected HTTPS response. A permissive Content-Security-Policy can be present without meaningfully restricting scripts. A policy can also break payments, embeds or analytics if copied without checking the application.
Inspect the actual response in browser developer tools. Trial CSP with Content-Security-Policy-Report-Only and review violations while exercising real page flows before enforcing it. Plan an HSTS change only after HTTPS works reliably; includeSubDomains affects subdomains too. Recheck the final response after redirects, then verify representative application pages, not just the homepage.
Keep a useful before-and-after record
Record the domain, check timestamp, affected row and the configuration you intend to change. Change one setting, verify the user-facing behavior, then run the check again. For email, send a real test message; for a web change, open the affected page. Keep the previous configuration so you can restore it if the change breaks the service.
If an interpretation appears wrong, use the Contact page and include the public report URL, check time, affected item and expected result. Remove passwords, cookies, private keys and personal message contents from any evidence you send.