Audit an unfamiliar domain in one query
Sooner or later you need to understand a domain you did not set up. A vendor you are about to trust with data. A client's site you have inherited. A domain you are thinking of buying. A service that is down and you do not know where it lives. The usual route is ten tabs: a WHOIS lookup, a DNS tool, a certificate checker, a header viewer, and a lot of cross referencing.
Everything in that list is public information, and most of it can be read in a single pass. Domain X-ray does that, and this post is about how to read what it shows.
What one query tells you
The report brings several independent sources together, because each one answers a different question.
Registration comes from RDAP, the structured successor to WHOIS. It shows the registrar, the expiry date and the nameservers. An expiry date a few weeks away on a domain someone depends on is a real finding. Contact details are usually redacted, which is normal and expected. For the background, see WHOIS and domain lookups explained.
Nameservers and hosting show who answers DNS for the domain. ns3.cloudflare.com or an awsdns host tells you where the DNS lives, which is often, but not always, where the site lives too.
CDN and WAF are read from the HTTP response. Headers such as cf-ray or x-amz-cf-id and the server value identify common providers. A WAF in front of the site is relevant if you are about to run a scan against it or wonder why requests are being blocked.
Mail is inferred from the MX records. Hosts under aspmx.l.google.com mean Google Workspace, and hosts under mail.protection.outlook.com mean Microsoft 365. This tells you who handles the domain's email, which matters for both trust and deliverability.
The certificate shows whether HTTPS is valid, how many days remain, and whether the server sends a complete chain. A certificate with a few days left on a site that matters is worth a message to its owner. How to read an SSL certificate explains the fields.
DNSSEC shows whether the zone is signed and whether a validating resolver authenticated it. This is a quick indicator, and it is not a full validation.
Records and headers list every DNS record found and which of the common security headers the site sets.
Reading the pieces together
The value is in how the facts line up or do not.
- A distant expiry date, signed DNSSEC and a complete certificate chain suggest a team that looks after the basics.
- Short expiry, no DNSSEC, no CDN, and a certificate with days left suggests something is run on goodwill. That is worth knowing before you build on it.
- DNS at one provider, mail at another, site at a third is normal, but a change in any one can break the others, so know which pieces can move independently.
- A mail provider that does not match what the company says it uses is worth a question. It is sometimes a leftover from a migration and sometimes a sign the domain is not what it claims to be.
Four common uses
Vendor due diligence. Before you give a vendor data, a few minutes of looking at their domain reveals whether their infrastructure is maintained. It is no substitute for a security review, but it filters out the obviously neglected.
Preparing a migration. Before you move a site, you need to know who runs DNS, what the TTLs are, where mail goes and what depends on the current setup. Read the records and the mail provider first, then plan the order of changes with DNS TTL planning for a migration.
Taking over a domain or site. Registration shows who the registrar is, so you know where to go to get access. The records show what is pointing where, including services you did not know existed.
Triage during an incident. When a site is down you need to know quickly whether it is DNS, the certificate, or the origin. Registration status, nameserver answers and the certificate are the first three things to rule out.
Where the guesses stop
Honesty about what the report cannot tell you is part of using it well.
Hosting, CDN, WAF and mail detection are fingerprints. They are built from nameserver names, response headers and MX hostnames. "Not detected" means no known signal was present, not that the service is absent. For example, a domain whose MX hosts are not on the tool's list of known providers shows no mail provider, even when a hosted service is in use. The list covers the common ones and is extended over time.
The DNSSEC line is a presence check. It reports whether keys exist and whether a resolver authenticated the zone. To verify the actual chain of trust and get an explanation if something is broken, use the DNSSEC Validator.
One snapshot from one place. The query comes from a single location at a single moment. CDNs and resolvers can answer differently elsewhere.
Public data only. The tool reads what the domain publishes. It does not scan for vulnerabilities, and it does not look inside anything protected.
When one section raises a question, a dedicated tool goes deeper: DNS Lookup for individual records, the SSL checker for the certificate, the security headers scanner for grading the headers, and the email deliverability score for the mail side.
A short routine
Run the X-ray on the domain. Read registration and the certificate expiry first, because those are the ones that cause outages. Then look at where DNS and mail live and whether that matches what you were told. Note anything surprising, and follow each surprise with the dedicated tool. The whole thing takes a few minutes and gives you a factual starting point, which is more than most conversations about an unfamiliar domain begin with.