Security Header and DNS Checker

How to use this checker

1. Decide which part you need. Part A answers "how well does this page protect its visitors?" and needs a full page address. Part B answers "can other people forge email from my domain, and will my real mail be trusted?" and needs only the domain. Fill in either or both; one submission runs whatever you have entered.
2. Run the check and read the summary of each part first. For Part A, confirm the final address and status are what you expected and see how long the redirect chain is. For Part B, look at the record summary to confirm the domain resolves and accepts mail the way you think it does.
3. Work through the header table. Every header is listed as Present, Missing or Weak, with its actual value and a plain-language note saying what it does and how to fix it. A header shown as Present because the Content Security Policy carries frame-ancestors is genuinely covered — that is the modern mechanism, not a loophole in the report.
4. Read the SPF lookup count, not just the record. An SPF record can look correct and still fail everywhere because evaluating it needs more than the ten DNS lookups the specification allows. The report counts lookups the way receivers do, including the ones hidden inside included records, and tells you the total.
5. Fix in priority order, then check again. The issue list is ordered high, medium, low across both parts. After publishing a fix, wait for DNS changes to propagate (for Part B) and run the same check again; export the report as JSON or CSV first if you want a before-and-after record.

Worked example: checking example.com

The fastest way to understand the report is to run it on a domain whose published records are stable and deliberately simple. The button below fills in https://example.com for Part A and example.com for Part B and submits the form, exactly as if you had typed them yourself.

Read the result structurally rather than memorising its values, because DNS records and certificates change over time and the report prints whatever it finds on the day. In Part A, expect a short chain — the address you enter is already the final address, so there are no redirects to follow — and read down the header table row by row: each header is marked Present, Missing or Weak with its actual value, so a minimal demonstration page like this one will honestly show a mixture. Where the page was fetched over HTTPS, the TLS panel underneath shows the certificate's issuer, its validity dates and how many days it has left. In Part B, start with the record summary, then read the three email sections in order: the SPF section prints the full record examined and the lookup count calculated for it, the DMARC section prints its record together with what its policy value means in practice, and the DKIM section reports which selectors were probed and what, if anything, answered — remembering, as the guidance box explains, that "none found" is a statement about the selectors tried, not proof that no key exists. Compare each conclusion against the record printed beside it: the report always shows what it examined, so you can verify its conclusions yourself.

Load sample

Two larger, real-world examples are one click each — their records are public and change over time, so read them the same structural way: github.com wikipedia.org

What this tool cannot do, stated plainly: it is a records-and-headers audit, not a sent-email test. Part A makes one fetch of the address you give; Part B reads DNS records. The tool never sends an email, so it cannot tell you whether messages from a domain actually reach inboxes or pass a specific provider's filters — it verifies the public declarations those providers will check, and its email conclusions are about those records only.

What this checker is, and why it matters

Two different kinds of trust meet on a domain, and this tool inspects both. The first is the trust a browser places in a page: whether the connection is encrypted and stays encrypted, whether the page can be framed by a stranger for clickjacking, whether scripts injected into it would run, and whether the cookies it sets can be stolen or sent over an unencrypted connection. Browsers learn all of that from a handful of response headers. Those headers are cheap to send and easy to forget, and nothing visibly breaks when they are absent — the page looks identical — so they are exactly the sort of configuration that drifts unnoticed until someone checks. Part A checks, grading the headers of the final response after redirects, because that is the response the browser actually obeys.

The second kind of trust is the trust a mail server places in a message. Email was designed without sender authentication, so three DNS-based systems were layered on top. SPF publishes the list of servers allowed to send for a domain. DKIM lets a sender sign messages with a key whose public half lives in DNS. DMARC ties the two together, telling receivers what to do when a message fails — monitor, quarantine or reject — and where to send reports about it. When these records are missing or wrong, anyone can send convincing mail that claims to come from the domain, and the domain's own legitimate mail becomes more likely to land in spam. Part B reads the records the way a receiver would, including the arithmetic receivers must do: it follows SPF includes recursively and counts every lookup, because a record exceeding the ten-lookup limit is treated as broken however reasonable it looks.

Both halves share one principle: the report shows its evidence. The actual header value, the actual DNS record examined, the actual lookup count — each conclusion sits next to the fact it rests on, so you can check the checker. There is deliberately no single grade or score. A missing HSTS header and an SPF record that permits the entire internet are not fractions of one number; they are different problems with different owners and different fixes, and a combined figure would only hide which one you have. Instead you get per-item findings and a prioritised list of issues in plain language, ordered so the problems that expose visitors or let forgers in come first.

Used after every meaningful change — a new server, a new email provider, a moved website, a renewed certificate — this becomes a quick regression test for the parts of your setup that fail silently. It will not scan for malware, test your application logic, or verify that the servers listed in an SPF record are configured correctly at their end. What it does is confirm from the outside that the public declarations your domain makes about itself are present, consistent and within specification limits.

Common problems, errors and limitations

Certain findings recur constantly. An SPF record ending in +all is usually a placeholder someone meant to replace: it authorises every server in the world and turns the record into an invitation. SPF lookup counts creep past ten one marketing tool at a time, each new include added without removing the service it replaced. DMARC records stall at p=none for years because monitoring feels safe, while offering no protection at all. On the header side, the common pattern is a strong policy set on the homepage but missing on error pages or API responses, which is why this checker grades the exact response to the exact address you enter.

The tool has honest limits, and the report respects them. Only public addresses on the standard web ports can be fetched; private, loopback and reserved addresses are refused for safety, requests are timed, and large responses are capped. The cookie check can only grade cookies visible in the final response's headers, and a page that sets cookies later through scripts will show none. The TLS probe reads the certificate presented to a standard verified connection; servers that demand unusual connection behaviour may decline the probe, in which case the report says the certificate could not be read rather than guessing. DKIM can only be checked under selectors that are probed, for the reason the guidance box explains. DNS answers are also a moving target: records propagate at different speeds to different resolvers, and results are cached briefly, so a record you published a minute ago may not appear yet — the report stamps every DNS section with the time it was queried.

Usage is metered with fair-use rate limits, stated here and on the Tool Limitations page: up to 10 checks per IP address per hour, plus a site-wide cap shared across all visitors, the same arrangement as our SEO Checker. If you reach the limit, the error message says so and names the wait; scripted or bulk checking is what the cap exists to prevent.

• Blocked address: the URL resolves to a private, loopback or reserved address, so the fetch is refused for safety.
• No DKIM found: no key answered under the probed selectors. Find the real selector (guidance box above) and re-check before concluding anything.
• SPF permerror risk: the lookup count is over ten, or an include loops — receivers will treat the record as broken even though it exists.
• Rate limited: the hourly allowance for checks has been reached; wait for the period named in the message, then try again.

Frequently asked questions