"Domain checker" means different things depending on who you ask. A startup founder looking for a brand name thinks availability lookup. A sysadmin who just migrated nameservers thinks DNS health. A security engineer preparing for an audit thinks posture assessment. The problem is that most domain checker tools only do one of these things, and the gaps between them are exactly where problems hide.
A domain that is registered does not mean it is healthy. A domain with perfect DNS does not mean its SSL certificate is valid. A domain with a valid certificate does not mean email from it is authenticated. Each layer depends on the others, and checking them in isolation gives you a partial picture at best. This guide walks through every layer a thorough domain check should cover, why each matters, and how to combine them into a single health assessment.
Domain Availability: What 'Available' Actually Means
When you type a domain into a registrar's search bar and see "available," you are seeing the result of a WHOIS or RDAP query that returned no active registration record. That sounds simple, but the reality is more nuanced than a binary registered/unregistered state. Domains exist in several states, and misunderstanding them can cost you money or lead to false assumptions.
Unregistered means no entity holds the domain. You can register it at the standard price. Registered means someone owns it, full stop. Reserved means the registry itself has withheld the domain, often for regulatory or technical reasons. You cannot register it regardless of what a WHOIS lookup shows. Premium means the registry has flagged the domain as high-value and set a price above standard registration fees, sometimes orders of magnitude higher. A domain can appear "available" while actually being premium-priced at $5,000 instead of $12.
The transition between states adds further complexity. A domain that was just dropped by its previous owner enters a redemption grace period (typically 30 days) where the old registrant can reclaim it. After that comes a pending delete phase (5 days) before it actually becomes available. During these phases, different registrars may show different statuses. One registrar's search might show the domain as available because they are querying a cached state, while another correctly shows it as still in redemption.
Then there is front-running: the practice where a registrar or affiliated entity registers a domain immediately after you search for it, then offers it back to you at a markup. While major registrars deny this practice, the pattern appears frequently enough that experienced domain buyers use neutral lookup tools rather than registrar search bars for initial availability checks. RDAP queries (defined in RFC 9224) go directly to the registry, bypassing intermediaries. The Domain Checker on DomScan uses RDAP as its primary source for exactly this reason.
DNS Health Checks
Once a domain is registered, DNS is the foundation everything else sits on. A misconfigured DNS record does not throw an error message. It simply makes things quietly fail: email stops arriving, subdomains resolve to old servers, or visitors get certificate warnings because the A record points somewhere the SSL certificate does not cover. DNS health checking means systematically verifying that every critical record type is correct, consistent, and current.
Here is the checklist a proper DNS health check should cover, in order of priority.
- NS delegation is correct. The nameservers listed at the registry (parent zone) match the NS records in the zone itself. Mismatches here (lame delegation) cause intermittent resolution failures.
- A and AAAA records resolve. The domain's primary records return valid, routable IP addresses. Check both IPv4 and IPv6 if AAAA records are published.
- MX records exist if email is expected. A domain that should receive email needs MX records pointing to valid, responsive mail servers. Missing MX records mean silent email loss.
- No dangling CNAMEs. CNAME records pointing to decommissioned services (old CDN endpoints, removed SaaS apps) are a subdomain takeover risk. An attacker can claim the target and serve content on your subdomain.
- SOA serial is recent. The SOA serial number should increment with every zone change. A stale serial suggests the zone has not been updated when it should have been, or that secondary nameservers are not syncing.
- TTL values are reasonable. Extremely low TTLs (under 60 seconds) create unnecessary query load. Extremely high TTLs (over 86400 seconds) mean changes take more than a day to propagate. For most production domains, 300 to 3600 seconds is the practical range.
- No conflicting record types. A CNAME at the same name as an MX, TXT, or A record violates the DNS specification and causes unpredictable resolver behaviour.
- DNSSEC chain is valid (if enabled). If the domain uses DNSSEC, the DS record at the parent must match the DNSKEY in the zone, and signatures must not be expired.
The Domain Health tool runs these checks automatically and flags failures by severity. The point is not to memorize every check but to run them systematically rather than spot-checking individual records.
SSL/TLS Status
SSL certificate checking has evolved well beyond "is it expired?" Modern browsers enforce strict certificate validation, and a failure at any point in the chain means your visitors see a warning page instead of your site. Here is what a complete SSL check covers.
Certificate validity is the baseline: the certificate has not expired and its notBefore date is in the past. But expiry alone misses most real-world SSL problems. Chain completeness matters equally. The server must send all intermediate certificates between the leaf certificate and a trusted root. Missing intermediates cause failures on mobile devices and older systems that do not perform AIA fetching. Use the SSL Certificate Checker to inspect the full chain.
Hostname match verifies that the certificate's Subject Alternative Name (SAN) list includes the domain you are checking. A certificate for `www.example.com` does not automatically cover `example.com` or `api.example.com`. Wildcard certificates (`*.example.com`) cover one level of subdomains but not the apex domain itself, which catches people off guard.
Protocol version is increasingly important. TLS 1.0 and 1.1 are deprecated and rejected by all modern browsers. If your server still negotiates TLS 1.0, scanners will flag it, compliance audits will fail, and browsers will show warnings. TLS 1.2 is the minimum acceptable version; TLS 1.3 is preferred for its improved handshake speed and stronger cipher suites.
Expiry window deserves special attention. A certificate that expires in 72 hours is technically valid, but operationally it is an emergency. Let's Encrypt certificates have a 90-day lifetime, meaning automated renewal must work reliably or you will face frequent outages. Your domain checker should flag certificates expiring within 30 days, not just expired ones.
Email Authentication Audit
Email authentication is the most overlooked layer in domain health checks, especially for domains that "don't send email." The absence of email authentication records does not mean your domain is neutral regarding email. It means anyone on the internet can send email pretending to be you, and receiving mail servers have no basis to reject it. Three DNS-based mechanisms work together to prevent this.
SPF (Sender Policy Framework) is a TXT record at the domain apex that lists which IP addresses and servers are authorized to send email for your domain. A valid SPF record for a domain that does not send email should be `v=spf1 -all`, which explicitly tells receivers to reject everything. No SPF record at all means receivers must guess, and many will default to accepting the message.
DKIM (DomainKeys Identified Mail) uses cryptographic signatures embedded in email headers. The receiving server looks up the public key at a specific DNS selector (like `selector1._domainkey.example.com`) to verify the signature. Unlike SPF, DKIM does not require you to enumerate every sending IP; the signature travels with the message. But if you have no DKIM records at all, your domain cannot benefit from DKIM verification.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. Published as a TXT record at `_dmarc.example.com`, it tells receivers what to do when authentication fails: nothing (`p=none`), quarantine the message (`p=quarantine`), or reject it outright (`p=reject`). For domains that never send email, `v=DMARC1; p=reject` is the strongest defence against spoofing.
The Email Security Check validates all three in one pass, flagging missing records, syntax errors, and weak policies. Even if your domain is purely a website with no mailboxes, these records are part of its security posture.
WHOIS and Registration Health
Registration data is the administrative layer beneath DNS. A domain can have perfect DNS, a valid SSL certificate, and complete email authentication, yet still be one expired credit card away from disappearing. Registration health checks verify the operational status of the domain itself at the registry level.
Registrar lock status (clientTransferProhibited) prevents unauthorized transfers. An important domain without this lock is vulnerable to social engineering attacks against the registrar. Check that both transfer and delete locks are set. Expiry date is the most obvious metric, but "expiry" is misleading. Most registrars offer an auto-renewal grace period after expiry, during which the domain still resolves but is technically lapsed. You want to know the hard expiry, the auto-renewal state, and whether the payment method on file is current.
Nameserver consistency means the nameservers listed in the WHOIS/RDAP record match what the zone actually delegates to. If WHOIS says your nameservers are `ns1.oldprovider.com` but your DNS zone has been moved to `ns1.newprovider.com`, the mismatch indicates an incomplete migration.
There are specific red flags worth watching for. Expired domains that still resolve suggest the registrar has not yet pulled the plug, but it is only a matter of time. Domains missing registrar locks on business-critical properties are accidents waiting to happen. WHOIS records showing a different registrant than expected may indicate an unauthorized transfer or a lapsed ownership update. The Domain Profile combines all of these registration data points into a single view.
Putting It All Together: A Domain Health Score
Individually, each layer tells you something useful. Combined, they tell you whether a domain is genuinely healthy or just superficially functional. DomScan's protection score takes this approach: rather than checking one dimension and declaring the domain "fine," it evaluates DNS, SSL, email authentication, and registration status as a composite.
The logic is conceptually straightforward. Each category contributes to an overall score, weighted by impact. A missing SSL certificate is more immediately damaging than a missing DKIM record, but both reduce the score. A domain with perfect DNS but no registrar lock and an expiring certificate is not healthy; it is one incident away from failure.
Here is what a health check response looks like in practice.
{
"domain": "example.com",
"overallScore": 82,
"categories": {
"dns": {
"score": 95,
"checks": {
"nsConsistent": true,
"aRecord": true,
"aaaaRecord": true,
"mxRecord": true,
"danglingCnames": false,
"soaFresh": true,
"dnssecValid": false
}
},
"ssl": {
"score": 88,
"checks": {
"valid": true,
"chainComplete": true,
"hostnameMatch": true,
"tlsVersion": "TLS 1.3",
"expiresIn": "34 days",
"expiryWarning": true
}
},
"email": {
"score": 67,
"checks": {
"spfExists": true,
"spfValid": true,
"dkimFound": true,
"dmarcExists": true,
"dmarcPolicy": "none"
}
},
"registration": {
"score": 78,
"checks": {
"transferLock": true,
"deleteLock": false,
"expiryDate": "2027-03-15",
"autoRenew": true,
"nsMatchesWhois": true
}
}
}
}In this example, the overall score of 82 looks decent, but the details reveal three problems. DNSSEC is not enabled, the SSL certificate expires in 34 days (inside the warning window), and the DMARC policy is set to `none`, which means authentication failures are reported but not enforced. The registration category loses points because the delete lock is not set. None of these are emergencies on their own, but together they represent a domain that is more vulnerable than it needs to be.
When to Run a Domain Check
Domain checks are not a one-time task. Different situations call for different levels of scrutiny, and the right time to find a problem is before it affects users.
- Before purchasing a domain. Check availability via RDAP, look at historical WHOIS data for past ownership, and verify the domain is not on any blocklists. A cheap domain with a spam history can take months to rehabilitate.
- After DNS changes. Every time you modify nameservers, add records, or migrate providers, run a full DNS health check. Confirm that the change propagated and that you did not break something adjacent (like MX records during an A record migration).
- Monthly audit for critical domains. Production domains, customer-facing services, and brand domains should be checked on a schedule. SSL certificates expire, registrar locks get accidentally removed, and DNS records drift over time.
- During incident response. When a service is down, a domain check eliminates or confirms DNS as the cause in seconds. Is the domain resolving? To the right IP? Is the certificate valid? These are the first questions to answer before diving into application logs.
- Before launching a new service. If you are putting a new application on a subdomain or a new domain entirely, run the full checklist before go-live. Missing email authentication records or an incomplete SSL chain on launch day creates a poor first impression.
From Checker to Workflow
A domain checker that only tells you whether a domain is registered is solving a 2005 problem. Modern domain management requires checking availability, DNS configuration, SSL certificates, email authentication, and registration status together, because failures in one layer compound failures in others. A domain with an expired certificate and a DMARC policy of `none` is not just two separate problems; it is a domain that looks untrustworthy to both browsers and email servers simultaneously.
Start with the Domain Checker for a quick availability and health snapshot. Use the Domain Health tool for a deeper DNS, SSL, and email posture audit. Check the Domain Profile for full registration and intelligence data. Validate certificates with the SSL Certificate Checker, and audit email records with the Email Security Check.
Further reading: RFC 9224 defines the RDAP protocol used for modern domain registration lookups. Let's Encrypt provides free, automated certificates that make SSL health maintenance straightforward for any domain.