domain --health | praneeth.me

praneeth@website:~$ domain --health [beta]

A graded report on everything public DNS says about a domain’s email and DNS security — SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, DANE, DNSSEC and CAA — and what to fix first.

Runs in your browser. Nothing is sent to this site. The only thing that leaves the tab is public DNS queries about the domain you enter, sent to Cloudflare’s resolver when you press check — the same questions any mail server asks. The report lists every one.

This is a tool rather than a document, so it needs JavaScript: every lookup and every check happens in your browser. That's also why nothing is sent to this site — enabling JavaScript lets your browser ask a public DNS resolver directly, it doesn't introduce a server. What the report covers is described below.

What it checks

SPF RFC 7208: Follows every include and redirect and counts the DNS lookups against the limit of ten — the thing that silently breaks when a provider changes theirs. Flags +all, ?all, ptr, loops, void lookups and multiple records.
DKIM RFC 6376: Probes the selectors your mail providers use by default plus 34 common ones, and checks each key against RFC 6376's syntax and RFC 8301's sizes: under 1024 bits fails, 1024 meets the minimum but not the recommended 2048, and Ed25519 (RFC 8463) is fine.
DMARC RFC 9989: Validated by the same library as /bin/dmarc. Follows the tree walk for subdomains, and checks that any external report address has authorised receiving your reports — otherwise they are silently dropped.
MX RFC 5321: Every mail host resolves to an address, none is an IP address or a CNAME (RFC 5321 §5.1, RFC 2181 §10.3), and a domain that takes no mail can say so with a null MX (RFC 7505).
MTA-STS / DANE RFC 8461: Whether sending servers are told to insist on authenticated TLS when delivering to you: an MTA-STS policy whose host resolves, or DANE — validated TLSA records on every MX, reached through validated MX records (RFC 7672 §2.2.1).
TLS-RPT RFC 8460: Whether anyone tells you when a sender couldn't deliver securely.
DNSSEC RFC 4033: Signed and validating; unsigned, or signed with no DS record in the parent — both leave answers unauthenticated; or signed and broken, which makes the domain vanish for every validating resolver.
CAA RFC 8659: Which certificate authorities may issue for the domain, climbing to parent names as CAs do (RFC 8659 §3), and whether a record restricts nothing — or, marked critical, blocks everyone.
Nameservers RFC 2182: At least two, as the DNS specification requires (RFC 2182 recommends three), and who operates them.
BIMI, IPv6: Reported, not graded: a brand logo record and whether it can show, and whether the web and mail hosts are reachable over IPv6.

How the grade works

Each check scores points, and each category is the share of its points earned. The overall score weights them: email authentication 50%, mail transport 25%, dns security 25%. Checks that don’t apply — transport security for a domain that takes no mail — are left out rather than counted as zero.

Letters from the score: A from 85, B from 70, C from 55, D from 40, F below. Some failures cap the grade however good the rest is:

max F DNSSEC is broken, so validating resolvers can't reach the domain at all
max F SPF ends in "+all", authorising every server on the internet
max D no DMARC policy is in force (missing, or invalid)
max C DMARC is at p=none, so the domain can still be spoofed
max C SPF returns permerror (too many lookups, multiple records, bad syntax)
max C no MX host can receive mail

A+ is an A with nothing left undone: every graded check passing outright, DMARC at reject, DNSSEC signed, and encrypted delivery enforced with MTA-STS or DANE (or, for a domain that takes no mail, a null MX). If a lookup a graded check depends on fails, there is no grade — a score built on a resolver that didn’t answer would be a claim about the resolver.

What a browser can’t check

STARTTLS and certificates on your mail servers — needs a connection to port 25, which browsers can't make.
The contents of your MTA-STS policy — a browser can only read it if your server sends CORS headers, which RFC 8461 doesn't require — and fetching it would be a request to your server. The report links to it instead.
Blocklists — Spamhaus, the most widely used, refuses queries that arrive through public resolvers such as Cloudflare's and answers with an error code instead, so a result through one would be meaningless.
Alignment of real mail — whether your senders actually sign as your domain is in each message's Authentication-Results header, not in DNS. Paste one into headers --trace.
DKIM selectors nobody guessed — DNS can't list them. Add yours — it's the s= in any DKIM-Signature header.

For a staged route from no DMARC to p=reject, see dmarc --check; to see how one real message fared, headers --trace. Every DNS question here goes to cloudflare-dns.com over HTTPS, with no cookies and no referrer.