Domain Health Report

Audit a whole domain in one query: DNS, SPF, DKIM, DMARC, DNSSEC, CAA, TLS certificate and security headers, with a prioritised list of what to fix.

./domain-health-report

One query that brings together DNS, email, TLS and headers, and tells you what to fix first.

The report looks at what is public: DNS records, the certificate and the front page headers. It does not enter your server or test for vulnerabilities.

What this tool does

You type a domain and one query returns what until now required opening nine separate tools and knowing what to look for in each: the state of email, DNS, the certificate and the headers, with a score per area and — the part that actually matters — a prioritised list of what to fix first.

The difference from a single checker is not the number of checks. It is that a checker tells you what is missing and this tells you what to do and in what order.

The twelve checks

All fired in parallel, because in sequence it would take longer than opening them by hand.

Email (35% of the score) : SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and MX records.

TLS (25%) : The certificate served on port 443, how many days it has left and whether it genuinely covers the queried domain.

DNS (20%) : Nameservers and their redundancy, DNSSEC and CAA.

Headers (20%) : The seven HTTP headers that harden a site, weighted by what they contribute.

Email and TLS weigh more because a failure there is exploitable today: someone can send mail pretending to be you, or your site can become unreachable when the certificate expires. Headers mitigate the damage of other failures, and DNSSEC or CAA are hardening — important, but not emergencies.

How to read the score

The overall score is the weighted average of the four areas. One deliberate detail: if an area does not apply, its weight is shared among the others rather than counted as zero. A domain that only serves a website should not fail for having no inbound mail configured.

And a word on how strict the scale is. It is calibrated not to cry wolf: having no DNSSEC or CAA is normal for the vast majority of legitimate domains, so it costs little. What does sink the score is what genuinely leaves you exposed: an SPF that authorises the whole internet, a missing DMARC, an expired certificate, or a single nameserver.

What this report is not

It deserves its own section because the confusion is easy and expensive.

It is not a vulnerability scan. It looks exclusively at what is public: DNS records, the certificate the server presents and the front page headers. It does not enter your machine, test exploits, or review your code or dependencies. An A grade means the public configuration is in good shape, not that the site is impregnable.

It does not replace an audit. A real attacker probes your application, not your TXT records.

It cannot confirm DKIM. This is the technical limitation worth understanding, because many tools paper over it. A DKIM public key lives at <selector>._domainkey.yourdomain.com, and only the signer knows the selector: there is no way to enumerate it. The report tries the most common selectors and, if none match, marks it informational rather than asserting it is missing. Large domains signing with rotating selectors trigger that false negative constantly, and saying “you have no DKIM” would simply be a lie.

Where to start if it comes back badly

The list order is already the answer, but the usual pattern is this:

  1. The critical email items. An SPF ending in +all, or no DMARC at all, lets anyone send mail in your name. It is the cheapest thing to fix and prevents the most damage.
  2. The certificate. If it expires within days, everything else is secondary: once it does, the browser covers your site with a full-page warning.
  3. Moving DMARC from p=none to p=quarantine. Almost everyone stops at monitoring and never reaches the point of blocking anything, which is where the real benefit lives.
  4. The two headers that matter: Strict-Transport-Security and Content-Security-Policy. The other five are minutes of configuration once you are already there.
  5. DNSSEC and CAA, once the rest is done.

Auditing a domain before you buy it

A use case that was not planned for and that brings in a fair number of people: vetting someone else’s domain before paying for it, usually an expired or second-hand one. The report covers what is visible from outside, and that is enough to tell whether it is live, parked or abandoned: MX records mean someone receives mail there; a valid certificate means a website is being served; signed DNS with CAA means whoever managed it knew what they were doing.

What the report does not look at, and you should check separately before buying, is the history:

  • Age and registrar, in the WHOIS lookup. A domain from 2009 and one registered three weeks ago to be flipped are not worth the same.
  • Email reputation, in the blacklist check. If the previous owner used it for spam, the lists keep the domain, not the owner.
  • Content history, in the Wayback Machine. No technical tool will tell you that in 2019 it was a supplement shop with a Google penalty.

If you prefer the detail

Every check also has its own tool in the catalogue, in case you only want to run one: email auditor, DNS lookup, SSL lookup and security headers. This report reuses exactly the same analyzers, so the results match — what it adds is gathering, ordering and explaining them on a single page.

Frequently asked questions

Can I use it to audit a domain before buying it?

For the half that is visible from outside, yes. The report tells you how the domain is configured today (whether it sends email, with which provider, whether it has a certificate, whether DNS is signed), and that alone reveals whether it is in use, abandoned or parked. What it does not look at, and is worth checking separately before paying, is its history: age and registrar in the WHOIS lookup, and whether any associated IP sits on a blacklist. An expired domain with a bad email reputation hands the problem to its new owner.

How do I run a full DNS audit of a domain?

Type the domain and run the report: in the DNS area check the nameservers, DNSSEC and CAA, and in the email area the MX, SPF, DKIM and DMARC records, which also live in DNS. If you want the raw records, type by type, with their TTL, the DNS lookup tool lists them; and if you have just changed something, the propagation tool shows which resolvers already see the change. Between the three they cover what an auditor asks for: what is published, whether it is signed and whether it is visible from outside yet.

What exactly does the report check?

Twelve things in parallel, across four areas. Email: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and MX records. DNS: nameservers, DNSSEC and CAA. TLS: the certificate, its expiry and whether it covers the queried domain. And the HTTP security headers on the front page.

How is the score calculated?

Each area has its own score and the overall one is a weighted average: email counts for 35 per cent, TLS 25, and DNS and headers 20 each. Email and TLS weigh more because a failure there is exploitable today, whereas headers mitigate and DNSSEC or CAA are hardening. If an area does not apply, its weight is shared among the others.

It says it cannot find DKIM but I do have it. Is it wrong?

It is not wrong, but it cannot claim otherwise either. A DKIM public key lives at a subdomain that depends on the selector, and only the signer knows the selector: there is no way to enumerate them. The report tries the most common ones and, if none match, marks it as informational rather than accusing you of missing it. If you know your selector, check it in the DKIM tool.

Is this a vulnerability scan?

No, and that is worth being clear about. The report looks only at what is public: DNS records, the certificate served on port 443 and the front page headers. It does not enter your server, does not test exploits and does not review your application. An A grade means the public configuration is in good shape, not that the site is impregnable.

Why does my domain score badly on headers if it is just an informational site?

Because it checks for seven headers and many sites configure none. It is not an emergency: headers do not fix a vulnerability, they limit what can be done with one. Start with the two that most change a site's posture, Strict-Transport-Security and Content-Security-Policy.

Reviews & ratings

No reviews yet. Be the first to leave one!

Write a review

Your rating *