Check a domain

What each layer actually controls

three separate companies, three separate logins
REGISTRARowns the registration, handles renewal and transfersRDAP
NAMESERVERSanswer every DNS question — SPF, DKIM, DMARC, MX, ANS
WEB HOSTserves the actual pages from an IP or a platformA / CNAME
MAIL HOSTaccepts inbound mail for the domainMX
ASSUMPTION"it is all with the registrar"USUALLY WRONG
Changing a record at the wrong provider is the single most common reason a "correct" DNS change does nothing at all.
01

Query RDAP

The registry publishes the sponsoring registrar, the IANA ID, creation and expiry dates and the transfer lock status.

02

Read the NS records

Whoever is named there is authoritative. That is the panel where DNS edits actually take effect.

03

Resolve and trace the site

A, AAAA and CNAME records, then the owning network for each IP, then the live HTTP response headers.

04

Separate CDN from origin

If the answer is a proxy, that is reported as a proxy — and common unproxied subdomains are checked for the real origin.

Why the registrar is almost never the host

Registration, DNS and hosting look like one product when you buy them in a bundle, but they are three independent services and they can each live at a different company. A domain bought at Porkbun can have its nameservers delegated to Cloudflare while the site itself runs on a DigitalOcean droplet and the mail sits on Google Workspace. Four companies, four dashboards, one domain.

This matters the moment something needs changing. Add a DKIM record in the registrar's DNS panel when authority has been delegated elsewhere and the record saves cleanly, displays perfectly, and resolves nowhere. Nothing errors. The change simply never existed as far as the internet is concerned.

How the hosting answer is worked out

Hosting detection is a chain of evidence rather than a single lookup, because no single record names the host. A CNAME pointing at cname.vercel-dns.com is conclusive. Failing that, the response headers frequently identify the platform outright — server: Netlify, x-vercel-id, server: Squarespace. Failing that, the IP address is mapped to the autonomous system that announces it, which names the network operator: Amazon, Hetzner, OVH, Newfold and so on.

Each result shows which of those methods produced the answer, so you can judge how much to trust it. An answer from a CNAME target is a fact. An answer from ASN ownership tells you whose network the server sits on, which for a VPS provider is the host, and for a reseller platform is the underlying cloud.

The Cloudflare caveat, stated plainly

When a domain is proxied through Cloudflare, the published A records belong to Cloudflare and the origin is deliberately concealed. Any tool claiming to reveal the true host in that situation is guessing. This one says so, then checks a short list of subdomains that are commonly left unproxied — cpanel, webmail, mail, ftp, direct, origin. When one of those resolves to a different network, it is reported as a likely origin rather than a confirmed one.

Reading the results

FindingWhat it meansWhat to do
DNS provider matches the registrarThe domain is on the registrar's default nameservers.Fine for a single domain. On a fleet it means no API, no bulk edits.
DNS provider differs from the registrarAuthority has been delegated. Only that provider's records resolve.Make every DNS change there. Ignore the registrar's DNS tab entirely.
Nameservers from two providersSplit DNS — normally an unfinished migration.Consolidate onto one, then re-verify every record.
One nameserver onlyNo redundancy. If it goes down, web and mail go with it.Add a second. Every serious provider issues at least two.
Host reported as a CDNProxied. The origin is hidden by design.Treat any origin hint as a lead, not an answer.
Expiry inside 30 daysRenewal risk. Expiry takes down mail as well as the website.Confirm auto-renew and that the card on file is current.
No transfer lockThe domain can be moved with less friction than it should take.Enable the registrar lock. It costs nothing.
No MX recordsThe domain cannot receive mail at all.Expected for a send-only domain. A problem for anything else.

Where this fits in a sending setup

On a cold email fleet, this is the audit you run before touching anything. Domains get bought across three registrars over two years by two different people, and half of them end up with DNS somewhere nobody remembers. Until you know which provider is authoritative for each one, every authentication fix is a guess.

Once the layers are mapped, the next checks are the mail-side ones: nameserver detail, MX and ESP, then SPF, DKIM and DMARC.

Questions

Does this show who owns the domain?

Almost never, and that is not a limitation of the tool. Registrant names and addresses have been redacted from public records since GDPR, and most registrars apply privacy by default regardless of jurisdiction. What remains public is the registrar, the dates, the status codes and the nameservers — which is what actually matters operationally.

Why is the registrar blank for some domains?

Not every TLD runs an RDAP service. Many country-code TLDs publish nothing machine-readable, and a few publish nothing at all. In those cases the registrar field is empty while DNS and hosting still resolve normally, since those come from the DNS system rather than the registry.

Is the hosting result always right?

It is as right as the evidence allows, and each result names its own method. CNAME targets and platform-specific headers are definitive. ASN ownership identifies the network operator, which is the host for a VPS but the underlying cloud for a managed platform. Proxied domains are reported as proxied rather than guessed at.

Does checking a domain here notify its owner?

No. Every lookup uses public data — RDAP, public DNS resolvers, public routing tables — plus one ordinary request to the site's homepage, identical to a browser visit.

Can I check a lot of domains at once?

Ten per run here. For a fleet audit across a whole estate, that becomes a scripted job against the same data sources — get in touch if that is the situation you are in.

Domains & web

More in this category

Related tools

What to run next

The checks people most often reach for alongside this one.

Services

When the tools tell you something is wrong

The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.

Get in touch

Start with a call

Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.

Thirty minutes, no pitch

We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.

Based inRangpur, Bangladesh — all time zones
RepliesWithin one business day
LicensingWorkspace below list price
Back to top