What does the checkup actually run?

For a domain: a per-type sweep of the core DNS records, one composite mail check covering MX, SPF, DKIM, DMARC, and PTR, a DNSSEC signing and validation check, a TLS connection to port 443 for the certificate, an RDAP query for creation and expiry dates, and DNS blocklist queries against the mail IP. Every one is a live query at the moment you press the button — nothing is served from a stored database of scan results.

Why does it say DKIM not found when my mail works fine?

Because DNS gives no way to list the selectors that exist under a domain, any tool can only probe guessed names — this one tries about 22 common defaults. If your platform uses a custom selector, the probe misses it even though DKIM is working. Open a message you sent, read the s= tag in the DKIM-Signature header, and check that selector directly — or paste the whole header block into this tool and it will use the real selector automatically.

Is an unsigned DNSSEC zone a problem?

No, and we deliberately report it as an info line rather than a warning. Most zones on the internet are unsigned, and an unsigned zone resolves perfectly everywhere. Signing adds tamper-proofing at the cost of a real operational risk: a stale DS record after a key rollover makes the whole zone SERVFAIL for validating resolvers. Sign if you can commit to managing rollovers; do not sign because a checker shamed you into it.

Can I check an IP or a URL too?

Yes. An IP gets a PTR lookup with forward confirmation plus blocklist status — the two things receivers actually judge an address on. A URL has its hostname extracted and checked as a domain, with the SSL check aimed at the exact host in the URL, so pasting https://shop.example.com tests the certificate on shop.example.com rather than the apex. Pasted email headers get parsed for the sending domain, selector, and IP, and the checkup runs on those.

Why is my domain's SSL check a neutral note instead of a failure?

Because nothing answered on port 443, and the tool cannot know whether that is a mistake. A domain used only for mail, or one that is registered but not yet launched, has no reason to serve HTTPS, so the absence is reported as a fact rather than a fault. If you expected a website there, treat the info line as your finding — the certificate check only fails when a certificate exists and is expired, mis-named, or served with a broken chain.

Checks run live and results are rendered per-request — there is no account, and nothing you check is published anywhere. Pasted email headers are parsed in memory to extract the sending domain, selector, and last-hop IP, then discarded; the message body is never needed, so do not paste it. If a header block contains recipient addresses you would rather not send at all, trim it to the Received and authentication lines — those are all the parser reads.

Domain Checkup — DNS, Email, SSL & Registration Health Check

A domain checkup runs every core diagnostic against one input in a single pass: DNS records, the full mail stack (MX, SPF, DKIM, DMARC, PTR), DNSSEC, the SSL certificate, registration age and expiry, and blocklist status. Paste a domain, an IP, a URL, or raw email headers — the tool detects which and runs the right checks.

One box, four kinds of input

The input field detects what you pasted and picks the diagnostic to match. Detection is mechanical, not clever: a value that parses as an IPv4 or IPv6 address is an IP, a value with a scheme or a path is a URL, a blob containing Received: or DKIM-Signature: lines is a header block, and everything else is treated as a domain.

You paste	Detected by	What runs
Domain (example.com)	Anything that is not one of the other three	The full checkup: core DNS records, the mail-stack composite (MX, SPF, DKIM, DMARC, PTR), DNSSEC, the SSL certificate, registration age and expiry, then blocklist status on the mail IP.
IP address (192.0.2.7 or 2001:db8::7)	Parses as IPv4/IPv6	PTR lookup with forward confirmation, then blocklist status on the address itself.
URL (https://shop.example.com/checkout)	Has a scheme or a path	The hostname is extracted and gets the full domain checkup; the SSL check runs against the exact host in the URL rather than the apex.
Email headers	Contains Received: / DKIM-Signature: lines	The headers are parsed for the sending domain, DKIM selector, and last-hop IP, and the checkup runs on those real values instead of probed guesses.

Pasting headers is the most precise mode, because the one thing DNS refuses to tell any tool — your DKIM selector — is sitting right there in the s= tag of the signature. If you only want the header decode without the rest of the checkup, the header analyzer does that on its own.

How to read the verdicts

Every check resolves to one of four verdicts, and the plain-English line always comes first — the raw records sit underneath, expandable when you want them. The four words carry exact meanings:

Read the full explanation of domain checkup results ↓

Fail — broken right now, with a consequence you can name: an MX host that does not resolve, an SPF record returning PermError, an expired certificate on a live site, a mail IP listed on a major blocklist.
Warn — works today but carries a known risk: DMARC still at p=none, a certificate inside its renewal window, a domain expiring soon, a PTR that exists but does not forward-confirm.
Info — a neutral fact we report without judging, because judging it would require knowing your intent.
Pass — queried, present, and correct by the published standard.

The info verdict exists because plenty of absences are choices, not mistakes. An unsigned DNSSEC zone is the majority case on the internet and breaks nothing by itself. A null MX (0 .) is RFC 7505's deliberate way of saying "this domain sends and receives no mail" — publishing one is better hygiene than leaving MX empty. A domain with no website is just a domain with no website.

A checker that paints every absence red trains you to ignore red. We reserve fail for things with a real, current consequence, so that when this page shows a failure you can act on it without first wondering whether the tool is exaggerating.

The order a support engineer actually works in

When a ticket says "mail is bouncing and the site is down," you do not check things in the order the control panel lists them. You check in the order that eliminates the most causes soonest. The checkup fires its queries in parallel for speed, but it reports them in that elimination order, so reading the page top to bottom retraces the same path a hosting support engineer would walk:

Registration. Is the domain expired or about to be? A lapsed registration explains every other symptom at once — parked nameservers, NXDOMAIN, dead mail. The domain age checker is the standalone version of this step.
Resolution. Do the base records answer, and if the zone is signed, does it validate? A stale DS record after a key rollover produces SERVFAIL on every query and is invisible from non-validating resolvers — run the DNSSEC checker when everything fails at once, and the DNS lookup when only some records look wrong.
Mail routing and authentication. MX first, because nothing downstream matters if delivery cannot connect; then SPF, DKIM, and DMARC in dependency order. The SPF checker, DKIM checker, and DMARC checker each go deeper than the composite card does.
Reputation. PTR with forward confirmation on the mail address, then that address against the blocklists via the blacklist check.
The web side. Certificate expiry and chain completeness, with the SSL checker for the full chain detail.

If the failure you are chasing started right after a nameserver or registrar change, Mail Bouncing After a DNS Change walks this same path with the specific mistakes each step tends to surface.

What this checkup cannot see

DKIM discovery is a guess. DNS provides no way to enumerate the selectors under a domain, so the scan probes roughly 22 published defaults (default, google, selector1, selector2, k1, and so on). "Not found" therefore means *not found among common selectors* — never proof that DKIM is absent. Paste headers instead, or read the s= tag yourself and check it directly with the DKIM checker; How to Find Your DKIM Selector shows three ways.
The SSL check assumes nothing. If nothing answers on port 443, that is reported as an info line, not a failure — a mail-only or parked domain has no obligation to serve HTTPS. The tool cannot know whether you intended to run a website.
The blocklist check targets the IP the domain publishes — the address behind the lowest-priority MX host. If you send through a separate relay, that outbound IP is the one receivers judge, and you will find it in the topmost Received: header of a message you sent. Paste those headers and the checkup uses the real IP.
Results come through a recursive resolver, so a record you changed minutes ago may still show its cached predecessor until the TTL runs out.
Runs are rate-limited per client. A single checkup fires several dozen queries, so repeated back-to-back runs are throttled. While iterating on one record, use the single-purpose tool for that record — it is faster and far lighter.

The same checks from your terminal

Every verdict on the page traces back to a query you can reproduce. Substitute your own domain:

DOMAIN=example.com

# Core DNS records
dig +noall +answer $DOMAIN A
dig +noall +answer $DOMAIN MX
dig +noall +answer $DOMAIN NS
dig +noall +answer $DOMAIN TXT

# Mail stack: SPF, DKIM (you must know the selector), DMARC
dig +short $DOMAIN TXT | grep -i 'v=spf1'
dig +short selector1._domainkey.$DOMAIN TXT
dig +short _dmarc.$DOMAIN TXT

# DNSSEC: a DS record at the parent means the zone is signed
dig +short $DOMAIN DS

# PTR on the primary MX address, then forward-confirm it
MXIP=$(dig +short $(dig +short $DOMAIN MX | sort -n | head -1 | awk '{print $2}') A | head -1)
dig +short -x $MXIP
dig +short $(dig +short -x $MXIP | sed 's/\.$//') A   # must print $MXIP back

# Blocklist: reverse the octets, query the list zone. NXDOMAIN = not listed.
# For 192.0.2.7 the query is:
dig +short 7.2.0.192.zen.spamhaus.org

# The two checks dig cannot do — certificate dates and registration dates
echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null \
  | openssl x509 -noout -dates
whois $DOMAIN | grep -iE 'creat|expir'

The checkup in raw form. The last two commands need openssl and whois — certificates and registration data do not live in DNS.

The blocklist line is worth understanding once: DNS blocklists are themselves DNS zones, queried by reversing your IP's octets. An answer of 127.0.0.x means listed; NXDOMAIN means clean. That is why a blocklist check is fast — it is just more DNS.

When mail is the problem, go one level deeper

The mail-stack card in this checkup is a summary. If your actual complaint is bounces or spam-foldering, the deliverability test runs the same five checks with a score out of 100 and orders the findings by what to fix first:

Email Deliverability Test

SPF + DKIM + DMARC + MX + PTR on one screen

Domain Checkup