Most domain disasters don’t start with a bang. They start with something small that nobody looked at.
A card that expired in a registrar account nobody logs into. A transfer lock that quietly came off on a Tuesday. An MX record edited at 2am by a contractor who forgot to mention it. A certificate on its last morning.
Every one of those is visible in public data, hours or days before it turns into a dead website, a bounced invoice, or a domain that belongs to someone else. Domain monitoring is the practice of watching for them automatically — and getting told while the fix still costs nothing.
This guide covers what domain monitoring actually watches, how the checks work under the hood, what to do when an alert fires, and where the whole discipline runs out of road.
Domain monitoring in one paragraph
Domain monitoring is the continuous, automated observation of a domain’s public registration, DNS and certificate data, with alerts sent when something changes or is about to expire.
It tracks expiry dates, registration records, nameservers, DNS records and TLS certificates. It detects unauthorised changes, risky registry statuses, and domains registered to impersonate a brand. It prevents downtime, domain loss and successful spoofing — by removing the surprise, not by paying the renewal invoice. And it triggers the response that follows: a registrar call, an abuse report, a takedown request, sometimes a UDRP filing.
The two halves of domain monitoring
Ask six vendors what domain monitoring is and there will be two incompatible answers. Both are correct. They describe different halves of the same discipline.
Half one: the domains a business owns
This half watches the perimeter from the inside. Expiry dates, registration records, nameservers, registrar locks, DNS records, certificates, email authentication.
The failure mode here is losing control or breaking quietly. It’s what keeps a company online.
Half two: the domains a business doesn’t own
This half watches the outside. Newly registered lookalikes, typo variants, homoglyph tricks, certificates suddenly issued for a near-identical name, phishing infrastructure being assembled.
The failure mode here is impersonation. It protects a brand’s customers rather than its uptime.
Why the two get mixed up
Vendors define the category as whatever they happen to sell. Security companies describe half two and barely mention expiry. Domain tools describe half one and skip typosquatting entirely.
Worth saying plainly: most organisations need half one first. There is no point defending a brand whose own domain silently lapses on a Sunday.
What domain monitoring is not
This is where most of the confusion lives. Several adjacent tools sound identical and do something else.
| It is not… | What that actually does | The real difference | Both needed? |
|---|---|---|---|
| Uptime monitoring | Pings a site, alerts when it stops answering | Reports the outage after it happens. Domain monitoring catches the causes — expiry, DNS edits, dead certs — before | Yes. They don’t overlap |
| Website change monitoring | Diffs or screenshots page content | Watches the page. Domain monitoring watches the record behind it | Only for defacement or competitor tracking |
| DNS resolver monitoring | Checks nameservers answer correctly and fast | Performance-focused. Domain monitoring is change-focused | Partly overlapping |
| Brand protection | Detects infringement, files takedowns, runs UDRP cases | That’s enforcement. Monitoring is detection | Detection first. Enforcement when volume justifies the cost |
| Dark web monitoring | Watches breach dumps for exposed credentials | Watches people, not the domain record | Complementary — it often explains how an attacker got in |
| EASM (external attack surface management) | Discovers every internet-facing asset | Broader and shallower. Domain monitoring goes deep on the registration layer | Larger organisations run both |
| Backorder / drop-catch | Grabs a domain the second it becomes available | A purchase mechanism. It acts on what monitoring finds | Only when chasing someone else’s expiring name |
| Registrar renewal emails | Reminds an account holder about their own renewals | Comes from the party most likely to be the point of failure | See the section below — this one deserves its own answer |
Why domain monitoring exists: five things that go wrong
These are ordered by how often they actually happen. Not by how dramatic they sound.
1. The renewal that silently failed
Auto-renew is a payment instruction, not a guarantee. It fails for boring reasons:
- The card on file expired and nobody noticed
- The TLD isn’t eligible for auto-renew at that registrar
- A reseller sits in the middle and didn’t renew upstream
- The domain lives in a former employee’s personal account
- Renewal notices go to an address hosted on the domain that’s dying
That last one is the cruel one. The alarm gets switched off by the fire.
After expiry the domain doesn’t vanish. For gTLDs it moves through a registrar grace period, then a 30-day Redemption Grace Period mandated by ICANN, then a few days of pendingDelete, then it drops. Recovery gets more expensive at every step — the full sequence is laid out in what happens when a domain expires.
2. The hijack that starts with a lock coming off
Domain hijacking has a signature. It looks like this:
- Registrar account gets compromised — usually reused credentials, sometimes a phished login
- The transfer lock quietly disappears
- Registrant contact details change
- Nameservers get repointed
- The domain transfers out
Steps two through four are all public. They sit in the registry record, readable by anyone, often for days before step five.
A transfer lock disappearing on its own is the single highest-signal, lowest-noise alert in this whole field. Almost nothing else causes it.
3. The DNS change nobody made
An A record pointing somewhere new sends visitors to a stranger’s server.
An MX record pointing somewhere new sends mail to a stranger’s server — with no outage, no error page, and nothing obviously wrong. Invoices keep arriving. Just not at the right company.
A deleted TXT record breaks SPF or DMARC and quietly re-opens the door to spoofing.
The triage rule is short: no change ticket means treat it as an incident until proven otherwise.
4. The certificate that ran out on a Saturday
Browsers show a full-page interstitial. Mobile apps and API clients fail hard, often without a readable error.
Certificates also got much shorter, and the deadline keeps moving. Since 15 March 2026, publicly trusted TLS certificates max out at 200 days. That drops to 100 days in March 2027 and 47 days in March 2029. Let’s Encrypt still issues 90-day certificates by default, offers a 6-day option, and plans to move to 45 days by February 2028.
Shorter certificates mean more renewals. More renewals mean more chances for an ACME job to break silently.
5. The domain that looks like the real one
Someone registers acme-billing.com, or swaps a Latin a for a Cyrillic one, or picks up the .cm version. Three days later a supplier gets an invoice with new bank details.
The tell usually arrives before the attack: a lookalike domain that suddenly acquires a TLS certificate and MX records is a lookalike getting ready to send mail.
What gets monitored, signal by signal
Domain expiry date
Pulled automatically from the registry record. The point isn’t the date itself — it’s the distance to it, checked daily, with warnings that arrive more than once.
One reminder is a single point of failure. Layered warnings at 30, 14, 7 and 1 days survive a holiday, a sick week, and a slow finance department.
Registration data
Registrar name, registrant organisation, creation date — and the Updated Date, which is the catch-all. It moves whenever the registry record is touched, even when nothing visible changed. An Updated Date that shifts without a matching change ticket deserves a look.
Registrar and transfer locks
clientTransferProhibited is the standard defensive lock. Its presence is normal and boring. Its absence, on a domain that had it yesterday, is not.
EPP status codes, in plain English
Anyone who looks up their own domain sees these and has no idea whether to worry. Here’s the decoder — and WHOIS change monitoring is what watches them for you.
| Status | What it means | Normal? | What it calls for |
|---|---|---|---|
clientTransferProhibited | Registrar rejects transfer requests | Yes — leave it on | Nothing. Removal is the alert |
clientUpdateProhibited | Registrar rejects update requests | Good practice | Nothing |
autoRenewPeriod | Registry auto-renewed after expiry; grace window running | Expected right after expiry | Confirm the payment actually cleared |
clientHold | Registrar told the registry not to activate the domain in DNS | No | Site and mail are down. Call the registrar today |
serverHold | The registry itself is holding it out of DNS | No | Usually a policy or verification issue. Registrar, immediately |
inactive | No nameservers associated with the domain | No | Nothing will resolve. Check delegation |
pendingTransfer | A transfer to another registrar is in progress | Unless expected | If nobody authorised it, contact the registrar to deny it — now |
redemptionPeriod | Registrar asked the registry to delete it; 30 days on the clock | No | Only the original holder can restore it, and it costs |
pendingRestore | A restore was requested; registry awaits paperwork | In progress | Make sure the documentation gets filed in time |
pendingDelete | Redemption ran out. Days from dropping | Terminal | Nothing restores it now |
Nameservers
The highest-impact single field on a domain record. A nameserver change is either a planned migration or a hijack. There is no third option.
DNS records
A and AAAA for where the site lives. MX for where mail goes. NS for delegation. TXT for the authentication records — all five are what DNS monitoring compares from one day to the next.
MX deserves special attention because MX failures are silent. A website going down generates complaints within the hour. Redirected mail generates nothing at all.
(DNSSEC belongs in this family too: a broken or removed DS record makes the domain fail to resolve for validating resolvers, which looks like a total outage for a subset of the internet and works fine for everyone else — a genuinely miserable thing to debug.)
TLS certificates
Expiry date, issuing CA, and unexpected reissues. The certificate clock runs separately from the domain clock, which is why the two expire at unrelated moments and why teams forget the second one — SSL certificate monitoring exists for exactly that gap.
Email authentication
SPF and DMARC are DNS records. They drift like any other record, and “present” is not the same as “working.”
Two examples that catch a lot of companies:
- Two SPF records on one domain. Under RFC 7208 that’s a permanent error. The domain doesn’t get a partial pass — it fails SPF outright. Usually caused by adding a second mail provider without merging the record.
p=nonein DMARC. That policy asks receivers to take no action. It generates reports and stops nobody. Plenty of domains have sat onp=nonefor years believing they were protected.
Both are visible in seconds — the free SPF & DMARC checker returns a plain-language verdict rather than just the raw record.
(Reputation and blacklist status is a related signal, though most companies discover a listing the way they discover most things: a customer mentions it.)
The signal table
| Signal | A change can mean | Urgency | First move |
|---|---|---|---|
| Expiry approaching | Renewal will fail, or nobody owns the renewal | Days–weeks | Confirm who can pay and who has the login |
| Registrar changed | Transfer completed — authorised or not | Immediate | Verify against change records |
| Nameservers changed | Migration, or hijack in progress | Immediate | No ticket = incident |
| Transfer lock removed | Someone is preparing a transfer | Immediate | Treat as compromise until disproven |
Status → pendingTransfer | Transfer already in flight | Immediate | Registrar can still deny it |
Status → clientHold | Registrar suspended DNS | Immediate | Usually billing or compliance |
| Updated Date moved | Record touched, cause unknown | Same day | Diff every other field |
| A / AAAA changed | Traffic redirected | High | Compare to deployment history |
| MX changed | Mail redirected — silently | Immediate | Test inbound mail, then investigate |
| SPF / DMARC changed | Spoofing protection weakened | High | Re-validate both records |
| Certificate expiring | Browser warnings imminent | Days | Check why automated renewal didn’t fire |
| Certificate issuer changed | New CA, or a certificate nobody ordered | High | Match against known providers |
Monitoring the domains nobody owns yet
The outward half of the discipline. Smaller companies can’t run it at enterprise scale — but understanding it changes what they do instead.
The attack families, named properly
- Typosquatting — swapped, dropped, doubled or transposed characters.
arcme.com,acmee.com - Combosquatting — the real brand plus a plausible word.
acme-support.com,acme-login.net,acmepayments.co. This is the most common form in practice and the one people fall for - IDN homograph attacks — Unicode characters that render identically. A Cyrillic
аinside a Latin word is invisible in most fonts - TLD squatting — the same name on
.co,.cm,.shop,.online - Path spoofing —
acme.com.billing-check.io, which reads left to right like the real thing and isn’t
How lookalikes get found
Tools generate permutations, then score how close each candidate is to the protected name — usually with edit distance or similar fuzzy matching, plus lookup tables of Unicode confusables for the homoglyph cases.
Then comes the honest part. Permutation space is effectively infinite. Every tool ships a trade-off between coverage and noise, and that trade-off is the false-positive rate a buyer should be asking about.
The certificate is the tell
A parked lookalike domain is annoying. A lookalike that just obtained a TLS certificate and configured MX records is a phishing campaign in its final hour of preparation.
Certificate Transparency makes this visible. Every publicly trusted certificate gets logged to public, append-only ledgers, and anyone can watch them. It’s the fastest external signal available in this whole field.
What a smaller company can realistically do
Nobody with 40 domains and no security team is going to police the permutation space. The realistic version is three moves:
- Register the obvious variants defensively. The five or ten a customer might genuinely mistype
- Watch the ones close enough to matter, and ignore the rest without guilt
- Make the real domain verifiable. This is the one that scales
That third point is the underrated one. A correctly configured SPF record, DKIM signing, and a DMARC policy set to quarantine or reject means mail forged from a lookalike fails authentication at the recipient’s server. It doesn’t stop the domain existing. It stops the domain working.
How domain monitoring actually works
RDAP and WHOIS: the registration record
This changed recently and most articles haven’t caught up. Since 28 January 2025, RDAP — the Registration Data Access Protocol — is the definitive source for gTLD registration data. ICANN sunset the WHOIS requirement for gTLD contracted parties on that date.
RDAP returns structured JSON instead of free text that varied by registry. Practically, that means fewer parsing failures and consistent field names.
A monitoring service finds the right RDAP server through IANA’s bootstrap registry, queries the registry directly, and falls back to WHOIS where a registry still runs one — which many ccTLDs do. The free WHOIS / RDAP lookup shows exactly what comes back for any domain.
Going registry-direct matters more than it sounds. No third-party data broker sits in the middle deciding what gets returned or how stale it is.
DNS queries: the live configuration
Straightforward: authoritative lookups per record type, compared against the last known state.
Zone files: how new registrations get discovered
TLD registries publish daily zone files listing every delegated domain. For gTLDs, access runs through ICANN’s Centralized Zone Data Service (CZDS).
This is the machinery behind every “newly registered domains” feed. It’s also why lookalike discovery is a daily rhythm rather than an instant one, and why ccTLD coverage in those feeds is patchy — many country registries don’t publish zone data at all.
Certificate Transparency logs
Near-real-time, unlike zone files. Public and free to watch.
Passive DNS
Aggregated observations of what resolved where, historically. Used for pivoting — finding every domain that shared an IP with a known-bad one. Threat-intelligence tier. Not something a small portfolio needs.
Baseline and diff
The core mechanic, and it’s simpler than it sounds:
- Take a snapshot of the current known-good state
- Re-check on a schedule
- Alert on the difference
Which explains two things people find confusing. The first check of a domain never alerts — there’s nothing to compare it to yet. And the first week can be noisy, because normal churn hasn’t been separated from real change yet.
How often is often enough
Different signals want different rhythms:
- Expiry — daily, with tiered thresholds. The date doesn’t move hourly
- WHOIS / RDAP, DNS, certificates — daily minimum. More for high-value names
- Lookalike discovery — continuous, but bounded by zone-file publication
“Real-time” claims about registry data deserve some scepticism. The registry itself updates on its own cadence; no amount of polling gets ahead of it.
On-demand re-checks are a different tool for a different moment. Scheduled checks answer has anything changed? An on-demand re-check answers is it fixed yet? — which is the question that matters in the ten minutes after responding to an alert.
Does monitoring touch anything?
No. It reads public registration, DNS and certificate data. No registrar login, no API key, no DNS access required.
Which is exactly why it works on domains a company doesn’t control.
What to do when an alert fires
An alert nobody acts on is a notification, not a control. This is the part most guides skip.
The response matrix
| Alert | Probably | Possibly | First three actions |
|---|---|---|---|
| Expiry in 30 days | Routine | Nobody owns the renewal | Confirm account owner → confirm payment method → confirm someone has the login |
| Nameservers changed | Planned migration | Hijack in progress | Check change records → check for lock removal same week → contact registrar |
| Transfer lock removed | Someone preparing a legitimate transfer | Account compromise | Re-apply the lock → rotate registrar credentials → check 2FA and access logs |
pendingTransfer appeared | Authorised transfer | Hijack, late stage | Contact registrar to deny → rotate credentials → review who had access |
| MX changed | New mail provider | Mail interception | Send a test message → check DNS provider audit log → restore if unauthorised |
| Certificate expiring | ACME job broke | Validation now blocked | Check renewal logs → verify DNS validation records → reissue manually if needed |
clientHold appeared | Unpaid invoice | Abuse complaint | Call the registrar. Nothing else will fix it |
| Updated Date moved | Cosmetic registrar-side change | Something changed that wasn’t shown | Diff every other field before dismissing it |
Runbook: nameservers changed and no ticket exists
- Check deployment and change records for the last 72 hours
- Verify who has access to the registrar and DNS accounts
- Check whether the transfer lock also came off recently — the two together are a strong hijack signal
- Contact the registrar and ask for the change log
- Restore the correct records
- Rotate registrar credentials and enforce 2FA
- Review every account that could reset a password on the domain’s mailboxes
Runbook: the transfer lock came off
Treat it as an active incident until proven otherwise. Almost nothing removes a lock by accident.
Re-apply it, rotate the registrar password, check for a session that shouldn’t exist, and confirm the registrant contact email is still one the company controls.
Runbook: seven days to expiry and nobody can renew
This is rarely a payment problem. It’s an access problem.
Find the registrar. Find the account. Find who has the login. If the account belongs to a former agency or a departed employee, start registrar account recovery immediately — it takes days, and there are only seven.
Runbook: certificate expires tomorrow
Check whether the ACME client ran at all, then whether validation succeeded. The usual causes are a deleted DNS validation record, a firewall change blocking the HTTP challenge, or a domain in a registry state that blocks re-validation.
If automation can’t be fixed in time, issue manually and fix the automation afterwards.
When the problem is a domain nobody here owns
Monitoring stops at detection. Everything past that point is a different discipline, and it runs on evidence.
Collect first:
- A timestamped RDAP or WHOIS snapshot of the offending domain
- Screenshots of the site or the phishing page
- The Certificate Transparency entry, if a certificate was issued
- The alert history showing exactly when it appeared
Then escalate, roughly in this order:
- Abuse report to the registrar
- Abuse report to the hosting provider
- UDRP or URS — but only with a trademark to point at, and only where bad faith can be shown
- A cease-and-desist letter
- Defensive registration of the remaining obvious variants
None of these are monitoring features. They’re legal and enforcement processes. Monitoring’s job is to hand them a timestamped, credible evidence trail — which is also the reason alert history is worth more than it looks.
Why some domains give back less data
Anyone setting up monitoring hits this within a day, so it’s better known in advance.
GDPR redaction. Registrant contact details are hidden for most gTLDs. Dates and status codes are not — and those are the fields monitoring actually needs.
ccTLDs write their own rules. Different lifecycles, different fields, different grace periods. Some publish no RDAP service at all.
Some registries publish no expiry date whatsoever. .de is the clearest example, and it takes a moment to see why. DENIC isn’t listed in IANA’s RDAP bootstrap, so a standard lookup finds no service for .de and comes back empty-handed. Query DENIC’s own endpoint directly and it does answer — with exactly one event in the entire response: last changed. There is no expiration date to read, by any tool, at any price. .es and .eu end up in the same place, and the free domain expiry checker says so plainly rather than inventing a date.
The workaround is unglamorous and works fine: record the date manually once, and every reminder runs normally from there.
Rate limits. Registries throttle lookups. It’s the ceiling that eventually breaks homegrown scripts.
Doesn’t the registrar already do this?
Fair question, and it has a specific answer.
The circular failure
Registrar notices go to the address on file. On a depressing number of accounts, that address is a mailbox hosted on the domain about to expire.
When the domain goes dark, so does the warning.
The registrar is the alarm and the failure point
A registrar can’t independently warn about its own failure. And the failures are ordinary:
- The card on file declined
- A reseller relationship lapsed
- The domain sits in an ex-employee’s account
- Support doesn’t answer on a Saturday
A service reading the registry gives a second alarm on an unrelated path. That’s the whole argument.
What registrars never send at all
They email about renewals. That’s the product.
They don’t email when nameservers change, when a transfer lock comes off, when an MX record is edited, or when a certificate is about to expire — because from the registrar’s side, most of those are normal customer actions.
And then there’s the multi-registrar problem
Marta runs a six-person studio holding roughly 40 client domains across three registrars. That’s three inboxes, three notification formats, three dashboards, and no single view of what expires next month.
ICANN requires registrars to send at least two renewal reminders — around a month out and around a week out — plus one after deletion. Useful. Also three emails per domain, per year, arriving from three different senders into an inbox that already receives several hundred messages a day.
Who actually needs domain monitoring
| Situation | Real exposure | Honest verdict |
|---|---|---|
| One personal domain, nothing depends on it | A missed renewal | Nice to have. A free expiry watch covers it entirely |
| A business running on one domain — site and mail | Expiry, DNS drift, dead certificate, spoofing | Yes. The classic case, and it fits inside a free tier |
| An agency or freelancer holding client domains | Every risk above × client count, plus reputational liability | Yes, with per-client alert routing |
| An MSP or hosting business | Multi-tenant risk, plus a billable service | Yes, and the alert history becomes a deliverable |
| A domain portfolio held as an investment | Expiry across scattered registrars | Yes, expiry-focused |
| A large brand with an impersonation problem | Lookalikes, phishing, takedowns | Both halves — monitoring and enforcement |
“Nobody would bother attacking a company this small”
Probably true. Also mostly irrelevant.
The majority of domain damage isn’t an attack at all. It’s a declined card, a wrong DNS edit, a certificate nobody renewed. Those don’t check company size first.
And automated lookalike registration doesn’t either.
Setting it up, step by step
1. Build the inventory first
Nothing can be monitored that nobody remembers owning. Forgotten domains hide in predictable places:
- Old campaign and product names
- Defensive registrations from a rebrand
- Redirect-only domains
- A former agency’s registrar account
- A founder’s personal card
- TLD variants bought “just in case” in 2019
Ways to find them: audit every registrar account, search card statements for registrar charges, review DNS zones, and search Certificate Transparency logs for the brand string.
2. Decide what depends on each domain
Tier them. Critical, important, parked.
A redirect domain and the domain carrying company mail should not generate the same alerts to the same people.
3. Turn on the right signals per domain
- Expiry — everything, no exceptions
- WHOIS, DNS and certificate monitoring — everything critical
- Email authentication — anywhere mail is sent
All four signals are described one page over, in the product overview.
4. Set thresholds that match how the company actually works
Layered expiry reminders at 30, 14, 7 and 1 days. Plus a longer one where procurement is slow — a 60 or 90-day warning is not paranoia in a company where purchase orders take three weeks.
Change alerts are different. There’s no useful threshold for somebody altered the nameservers. Those fire immediately.
5. Choose channels, then route them
- Email — the baseline, always on
- Slack or Discord — team visibility for shared domains
- Webhooks — into ticketing or on-call
Route per domain, not globally. A personal blog and a client’s production domain shouldn’t wake the same three people.
6. Decide who acts before anyone needs to
One line per alert type: who owns it, what they do first. It takes twenty minutes and it’s the difference between an alert and a control.
7. Test it
Send a test alert on every channel. Then verify the receiving address isn’t hosted on a monitored domain.
Designing alerts people actually read
Three classes, three rhythms
- Scheduled — expiry thresholds. Predictable, plannable
- Event-based — WHOIS and DNS changes. Fire immediately, no batching
- State — certificate expiring, SPF misconfigured. Persistent until resolved
How alert fatigue kills the whole thing
The pattern is always the same. Too many low-value alerts, then the team stops reading, then the one real alert lands in a folder nobody opens.
Three fixes that work:
- Tier the domains, and alert accordingly
- Don’t alert on fields that legitimately churn
- Send noisy signals to a channel, not an inbox
What a good alert contains
Which domain. Which field. Old value → new value. When it was observed. What to do first.
Anything less turns into a research task at the worst possible moment.
One rule worth writing on a wall
Never send domain alerts to a mailbox hosted on a monitored domain.
What domain monitoring can’t do
- It doesn’t renew anything. It removes the surprise, not the invoice
- It doesn’t prevent changes. It’s a smoke alarm, not a lock. Pair it with registrar locks, 2FA, and registry lock on the names that matter
- It doesn’t take anything down. Detection and enforcement are separate disciplines
- It doesn’t watch uptime or content. A domain can be perfectly registered and completely broken
- It won’t catch every lookalike. Coverage is a spectrum, never a guarantee
- It can’t read what registries don’t publish. See
.de
Choosing a tool
The evaluation checklist
- Signal coverage — expiry only, or WHOIS, DNS, certificates and email authentication too?
- TLD coverage — does it handle the relevant ccTLDs, and does it say honestly when a registry publishes no expiry date?
- Data source — registry-direct via RDAP, or resold from an aggregator?
- Check frequency — per signal, not a single marketing number
- False-positive rate — for lookalike detection, what’s the noise floor? For change detection, which fields does it deliberately ignore?
- Alert channels and routing — per domain, or one global setting?
- Bulk import — matters immediately past ten domains
- Alert history — how long, and is it searchable?
- On-demand re-check — for the ten minutes after a fix
- API or webhook — for anything that needs to reach a ticketing system
- The free tier — what’s actually included, not just how many domains
Pricing shapes and where they bite
- Per domain — predictable until a portfolio grows
- Tiered — check the jump between tiers before committing
- Free tiers — usually domain-capped, which is genuinely fine for a small portfolio
- Enterprise brand-protection suites — priced for legal departments, not domain owners
Red flags
- Data from an unnamed third-party aggregator
- Expiry treated as a minor add-on feature
- No alert history
- No per-domain routing
- “Real-time” claims about registry data
- A free checker with no notification path at all
Or just script it?
Plenty of admins run whois or dig from cron and diff the output. It works. Until:
- WHOIS output formats differ per registry, and the parser breaks on one TLD
- Rate limits kick in
- The script dies silently on a server nobody watches
- RDAP replaces WHOIS at a registry and the endpoint moves
- The alert email goes to the domain that just expired
Rule of thumb: DIY works for a handful of domains checked often. It fails precisely when it matters. And with free tiers covering a few domains at no cost, an evening of scripting plus ongoing maintenance is an odd trade.
At scale: agencies, MSPs and teams
The multi-registrar problem. One view across names scattered over registrars, cards and accounts — which is the actual daily pain, not any individual alert.
Per-client routing. Notification groups so each client’s domains reach the right channel and the right people. Client A’s production domain to email plus Slack. An internal test domain to email only.
Bulk onboarding. Importing a list beats adding 60 domains by hand.
Proving the work happened. Alert history is the artefact for a quarterly review: here’s what was caught, and when. Prevention is invisible until it’s documented.
The handover problem. Domains held in an agency’s account become a negotiation when a relationship ends. A monitoring record is a neutral statement of what exists and who holds it.
All five are the reason there’s a page specifically about domain monitoring for agencies and MSPs.
Compliance, audits and insurance
Asset inventory obligations. NIS2 and ISO 27001 both require organisations to know what they own. Domains are assets. An unmonitored domain is an unmanaged asset.
Proving the control ran. Auditors rarely want proof a control exists. They want proof it operated. Check logs and alert history are that evidence.
Insurance questionnaires. Cyber policies increasingly ask about domain and DNS change controls, and answers get compared against reality after a claim.
Is reading this data legal? Yes. RDAP, WHOIS, DNS records and Certificate Transparency logs are published deliberately by registries and certificate authorities. GDPR restricts what gets published — it doesn’t restrict reading what is.
Ten mistakes worth avoiding
- Monitoring the main domain and forgetting twelve defensive registrations
- Sending alerts to a mailbox on the monitored domain
- Treating the registrar as the only alarm
- Mistaking auto-renew for monitoring
- Alerting on everything, then ignoring everything
- Watching expiry but not locks and nameservers — the fields a hijack actually touches
- Never testing that alerts arrive
- No named owner for any alert
- Forgetting the certificate clock runs on its own schedule
- Assuming a ccTLD behaves like a
.com
A twenty-minute starting checklist
- List every domain the organisation owns, including the forgotten ones
- Note the registrar and account owner for each
- Check today’s status and expiry date for each
- Mark which carry a website, mail, or both
- Turn on expiry monitoring for all of them
- Turn on WHOIS, DNS and certificate monitoring for the critical ones
- Set thresholds at 30, 14, 7 and 1 days — plus a longer one if procurement is slow
- Point alerts at an address hosted somewhere else entirely
- Add a team channel for shared domains
- Send a test alert on every channel
- Write one line per alert type: who acts, and what they do first