How to Check a Client Domain's SSL and DNS in 60 Seconds

You have just taken on a client, or you are about to. Somewhere there is a domain you did not register, an SSL certificate you did not provision, and a DNS zone someone else built — possibly years ago, possibly by a person who has since left. Before you take responsibility for keeping it online, you need to answer one question: what is actually live right now?

You do not need registrar access or a hosting login to answer most of it. SSL certificates and DNS records are public by design. A 60-second spot-check tells you the certificate's expiry, who issued it, what hostnames it covers, and where the domain's traffic and email are pointed. This guide walks through what to read and what each signal actually means.

If you want to run the check while you read, our free SSL & DNS checker returns all of it for any hostname — no account, no signup.

The Fast Check: What You Can See Without Any Access

Two layers of a website are publicly inspectable from outside, and both are the layers that fail silently:

The TLS certificate. Every HTTPS site presents a certificate during the handshake. That certificate is public — it states who issued it, the exact window it is valid for, and every hostname it covers. You can read all of it without touching the server.

The DNS records. A domain's A/AAAA records (where the site is hosted), MX records (where email is delivered), and NS records (which nameservers are authoritative) are queryable by anyone. They tell you how the domain is wired together.

Neither requires permission. That is the point of the spot-check: you can audit a client domain before you have credentials for anything, and confirm what you are inheriting before you promise to keep it running.

Reading the SSL Certificate

Pull the certificate and read four things, in order.

Days until expiry. This is the headline number. A certificate that expires in 9 days is a near-term incident; one that expires in 240 days is fine for now. Most managed platforms auto-renew at roughly 30 days before expiry — so anything inside that window that has not renewed is worth a second look, because it means the auto-renewal has not fired yet and may not.

The issuer. Who signed the certificate tells you how it is managed. Let's Encrypt or Google Trust Services almost always means automated, short-lived (90-day) certificates renewed by the platform — Vercel, Netlify, Cloudflare, Firebase, and most modern hosts. A commercial CA like Sectigo, DigiCert, or GoDaddy more often means a manually purchased certificate on a fixed annual cycle, which is the kind that lapses when nobody remembers to renew it. The issuer is your first clue about whether expiry is somebody's job or nobody's.

The covered hostnames (SANs). A certificate lists every name it is valid for in its Subject Alternative Names. This is where coverage gaps hide. A certificate valid for example.com but not www.example.com throws a security warning for every visitor who types the www version. A certificate covering the marketing site but not app. or api. means those subdomains have their own certificates — which you now need to find and check separately. Read the SAN list and confirm it covers every hostname the client actually uses.

The validity window. The not-before and not-after dates. Mostly you care about not-after (expiry), but a not-before date in the future is a sign of a misconfigured or freshly swapped certificate, and an unusually long validity window can indicate an older certificate issued before the industry moved to short lifetimes.

Reading the DNS Records

DNS is how the domain is assembled. Three record types tell you the most.

A / AAAA records — where the website lives. These resolve the hostname to an IP address (IPv4 for A, IPv6 for AAAA). For an apex domain (example.com with no www), the records often point at a platform's load balancer or a specific set of IPs the host requires. A common failure mode: apex domains on GitHub Pages require all four of GitHub's specific A records, and a client DNS edit that drops one breaks SSL provisioning silently. If the A records point somewhere you do not recognize, find out what is there before you change anything.

MX records — where email is delivered. MX records route the domain's email. They matter for two reasons. First, they tell you the client's email provider (Google Workspace, Microsoft 365, a host's mail server). Second — and this is the one that causes outages — if you ever migrate the domain's DNS to a new provider and forget to recreate the MX records, the client's email stops being delivered. Reading the current MX records before a migration is how you avoid taking down a client's inbox.

NS records — who controls the domain. The nameservers are authoritative for the zone. They tell you where DNS is actually managed, which is often not the same place as the registrar and frequently not where the client thinks it is. If the NS records point at Cloudflare but the client believes their DNS is at their old host, that mismatch is exactly the kind of thing that produces "I changed the record and nothing happened" confusion later. Confirm where DNS actually lives before you try to edit it.

Where a One-Time Check Stops Being Enough

A spot-check is a photograph. It tells you the state of the domain at the instant you looked — which is exactly what you want when you are onboarding a client or diagnosing a live problem.

What it cannot tell you is what changes next week. The certificate that reads "valid, 38 days" today is the one that quietly fails to auto-renew and expires next month. The DNS records that look correct today are the ones a client edits — or a registrar transfer rebuilds — without telling you. The whole category of failure that hurts agencies is not "the certificate is expired right now"; it is "the certificate expired three days ago and the client found out before you did."

That gap is the difference between a checker and monitoring. A checker answers what is true now. Monitoring answers what changed and tells you before it becomes a client phone call. For a single domain you are actively working on, the spot-check is enough. For a portfolio of client domains you are responsible for, watching every certificate and DNS zone by hand does not scale — and the failures happen on exactly the domains you are not looking at that week.

A Repeatable Onboarding Check

Make this part of taking on any new client domain:

Run the spot-check. Read SSL expiry, issuer, and SAN coverage, plus A/AAAA, MX, and NS records. The free checker returns all of it at once.
Flag anything inside 30 days of expiry and confirm whether it auto-renews — a commercial-CA certificate inside the window is the highest-risk item you will find.
Check every subdomain the client uses, not just the apex. app., api., admin., and staging. each carry their own certificate.
Record the current MX and NS records before you change anything, so a future migration cannot silently break email or DNS.
Decide what gets monitored. Anything you are now responsible for keeping online belongs on continuous monitoring, not a recurring manual check you will eventually skip.

The spot-check is free and takes a minute. The monitoring is what turns "I hope someone renewed that" into a system. Start a free 14-day trial and put every client domain on watch.

→ Related: Free SSL & DNS Checker