Domain Monitoring: What to Watch and Why

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

Monitor the registration, not the website

Domain monitoring is the practice of continuously watching a domain's registration status, DNS and certificate issuance, so an unauthorized change is noticed within hours rather than discovered when the site goes down. Its whole value sits in one interval: the gap between a change and somebody noticing it. Everything below is about compressing that gap.

Which is why uptime monitoring, useful as it is, does not do this job. By the time a site stops resolving, a transfer has usually completed and the domain sits at another registrar under another account. Worse, the highest-value attacks do not take the site down at all. A hijack that redirects mail by changing MX records is quieter than one that redirects the website, and more damaging: password resets, invoices and contracts travel through mail while the site stays up.

The signals worth watching sit at four layers: registry, registrar, DNS and certificate. They fail independently, and a monitor covering one produces a false sense of coverage.

Registry layer: the EPP status codes that matter

Registration status is published as EPP status codes — flags set through the Extensible Provisioning Protocol that registrars use to talk to registries, saying what is permitted and what is in progress. ICANN's reference draws the distinction that governs the rest: "client codes are established by registrars, while server codes are set by registries and take precedence over client codes." The codes to alarm on:

pendingTransfer — a transfer is in progress. ICANN's guidance is to take action if you did not initiate it. This is the single highest-value alert in domain monitoring, and the one worth waking somebody for.
clientTransferProhibited — tells the registry to reject requests to transfer the domain away from your current registrar; clientUpdateProhibited and clientDeleteProhibited reject updates and deletions.
serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited — the registry-set equivalents, typically applied during disputes or as part of a registry lock service.
redemptionPeriod — the domain is deleted but recoverable; ICANN states it "will be held in this status for 30 days." Contact the registrar immediately.
pendingDelete — deletion is imminent after the redemption status.

Alarm on codes appearing and disappearing. Removal of a transfer lock is the precursor; the transfer is the event. Alert only on the event and you have given up the warning.

Registry lock is a monitorable fact, not an assumption

Registry lock is a registry-level service applying the server-side prohibitions, so a compromised registrar account alone cannot move or alter the name. Verisign's Registry Lock Service covers .com, .net, .cc and .name, and a locked domain displays three codes: Server Delete Prohibited, confirming the name cannot be deleted or lapsed; Server Transfer Prohibited, preventing unauthorized transfers away; and Server Update Prohibited, allowing no modifications, including nameserver re-delegations. Changing a locked object requires the registrar to contact Verisign support rather than push an ordinary EPP update.

The presence of those three codes is itself queryable. A lock that has silently lapsed — through a registrar migration, an account change, or a service never provisioned despite being paid for — looks exactly like one that works. Query the codes; do not trust the invoice.

Registrar layer: notices, auth codes and the two sixty-day windows

At the registrar, watch changes to registrant and administrative contact, nameservers, and the auth code (the secret that authorizes moving a domain to another registrar), plus removal of a transfer lock and any transfer authorization email.

The ICANN Transfer Policy sets the timing that makes this workable. On receiving notice of a transfer, the registrar must notify the Registered Name Holder "as soon as operationally possible, but must be sent not later than 24 hours." It must provide the auth code within five calendar days of a request, and codes must be "unique on a per-domain basis."

Two 60-day windows are commonly confused, and the difference is the attacker's opportunity. After an inter-registrar transfer, the policy permits the Registrar of Record to deny a further transfer within 60 days — a discretion, not an absolute bar, and excluding transfers back to the original registrar by mutual agreement or through dispute resolution. After a Change of Registrant the lock is mandatory: "The Registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant." But registrars may let the holder opt out in advance, so an attacker who changes the registrant on an account with opt-out enabled can move the name immediately.

Those notices are the primary monitoring signal, which is exactly why an attacker's first move is often to change the address they go to.

Expiry layer: three alarms you already have

Expiry is the most common way a domain is lost, and it is entirely preventable. The Expired Registration Recovery Policy, effective 31 August 2013, requires a renewal reminder approximately one month before expiration and another approximately one week before — compliance windows of 26 to 35 days and 4 to 10 days — plus a further notice within five days after expiration if the name is neither renewed nor deleted. It also requires the registrar to interrupt the existing DNS resolution path after expiration, for at least the last eight consecutive days during which the name remains renewable by the registrant.

Treat those three notices as scheduled checkpoints rather than reminders. If one does not arrive, that is itself the signal: either the domain is not where you think it is, or the notification address is not what you think it is. Note the structural weakness — all three go to the same address an attacker would change — which is why expiry monitoring has to exist independently of the registrar's mail.

DNS and certificate layers

At the DNS layer, watch nameserver delegation at the parent, A, AAAA, MX and TXT record changes, and the presence or absence of a DS record if the zone is signed. Watch MX with particular attention: mail redirection survives longest, because nothing visibly breaks.

At the certificate layer, monitor Certificate Transparency logs — public append-only records of publicly trusted certificates as they are issued. CT catches an attacker who obtained a certificate for your name, including issuance a CAA record did not block. It is the detection half of a control pair whose prevention half is silent.

That the two belong together is not theory. CISA Emergency Directive 19-01, issued 22 January 2019 and the first CISA ever issued, described an active campaign in three steps:"compromising user credentials ... of an account that can make changes to DNS records," "altering DNS records" to redirect traffic, and "obtaining valid encryption certificates for an organization's domain names." Its required actions, each within 10 business days: audit public DNS records, change passwords on accounts that can change them, add multi-factor authentication — with the note that "SMS-based MFA is not recommended" — and begin monitoring Certificate Transparency logs. Credentials, then DNS, then certificates. That is the chain monitoring is built to catch.

Build it on RDAP, not on WHOIS scraping

Since 28 January 2025, RDAP — the Registration Data Access Protocol — "will be the definitive source for delivering generic top-level domain name (gTLD) registration information in place of sunsetted WHOIS services." All gTLD registries and registrars must provide RDAP using the gTLD RDAP Profile, and are no longer required to provide WHOIS, except for .com, .name and .post. Note where that leaves the two TLDs most likely to matter: .com retains the WHOIS obligation, .net does not.

The migration is an improvement rather than a chore. RDAP returns structured JSON, so status codes, dates, nameservers and registrar of record can be diffed reliably instead of regex-scraped out of free text whose format varies by registry. It is Internet Standard STD 95, comprising RFC 7480, RFC 7481, RFC 9082 and RFC 9083, and ICANN operates a lookup service at lookup.icann.org.

Redaction limits what you can see but not what you need. Contact fields will be empty; status codes, nameservers, registrar of record and dates stay visible, and those are the fields worth diffing.

What good monitoring actually looks like

Poll RDAP on a schedule and diff the response — status codes, nameservers, registrar of record, updated and expiry dates — alerting on any delta, not only known-bad values.
Alert loudly on pendingTransfer appearing, and on any *TransferProhibited or *UpdateProhibited code disappearing.
Apply registrar-level locks as a baseline, and registry lock for names whose loss would be material.
Route registrar notifications to a monitored, role-based mailbox on a domain other than the one being protected, so a hijack does not take out the alerting channel too.
Monitor Certificate Transparency logs for issuance on the apex and on wildcards.
Monitor DNS from outside, including DS presence, and alarm on approaching RRSIG expiry if the zone is signed.
Put phishing-resistant multi-factor authentication on every account that can change DNS or registration data.
Keep an offline evidence pack current: registrar account records, renewal invoices, dated RDAP snapshots, DNS zone exports.

That last item is the one people skip, and it decides how a bad day ends. Recovery runs on evidence, and with contact data redacted the public record no longer supplies it.

Common mistakes

Monitoring the website rather than the registration, or checking once a year at renewal.
Sending registrar notifications to an address nobody reads — a personal address whose owner changed jobs, or a privacy forwarder pointed at a dead mailbox.
Relying on the registrar's own dashboard as the monitor. If the vector is a compromised registrar account, the attacker sees the same dashboard, can silence it, and can change the notification address.
Watching the registration but not DNS, so an MX change for mail interception passes unnoticed while the registration looks pristine — or watching DNS but not Certificate Transparency, so a certificate issued to an attacker stays invisible.
Leaving clientTransferProhibited off, or assuming a registrar's default "domain lock" is a registry lock. It is not: client codes are set by the registrar and removable through the registrar account.
Building monitoring on port-43 WHOIS scraping.

Frequently Asked Questions

How would I know if someone was transferring my domain away?

Two signals, and you want both. The registrar must notify the Registered Name Holder on receiving notice of a transfer, as soon as operationally possible and no later than 24 hours, so that email is the first warning, assuming it reaches a mailbox someone reads. Independently, the domain's registration data will show the EPP status code pendingTransfer while the transfer is in progress. Polling RDAP for that code and alerting on it does not depend on the notification address, which is exactly why it matters: changing that address is a standard first move.

What does pendingTransfer mean and what should I do?

It means a transfer of the domain to another registrar is in progress. ICANN's guidance is to take action if you did not initiate it. In practice that means contacting your current registrar immediately, through a channel you can authenticate on, and asking them to reject the transfer while it is still pending; a transfer that has not completed is far easier to stop than one that has. At the same time, check whether the transfer lock was removed and whether the contact email or auth code changed, because those changes preceded it.

How often should a domain be checked?

Frequently enough that the gap between a change and its detection is measured in hours, not weeks. Checking at renewal is not monitoring; a domain can be transferred, re-pointed and re-sold well inside a year. The natural cadence is a scheduled RDAP poll with a diff against the previous response, so that any delta in status codes, nameservers, registrar of record, updated date or expiry date raises an alert. The specific interval matters less than the fact that it is automated and that the alerts reach somebody.

Is registry lock enough on its own?

It is the strongest single control on the registration and it is still not a monitor. Registry lock applies the server-side prohibition codes so a compromised registrar account alone cannot move or alter the name, and changing a locked object requires the registrar to contact the registry out of band. But a lock can lapse through a registrar migration, an account change, or a service that was never actually provisioned. The presence of the three server-side codes is a fact you can query, so query it rather than assuming. And a lock does nothing about DNS or certificate issuance.

What is the difference between a registrar lock and a registry lock?

Who sets it, and therefore who can remove it. A registrar lock is the client-side EPP codes, principally clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited. Those are set by the registrar and can be removed through the registrar account, which means whoever controls that account can remove them. A registry lock applies the server-side equivalents, set by the registry, and server codes take precedence over client codes. Changing a registry-locked domain requires out-of-band contact between registrar and registry. Many registrars market the first as domain protection; it is not the second.

Should monitoring query WHOIS or RDAP?

RDAP. Since 28 January 2025 it is the definitive source for gTLD registration data, and gTLD registries and registrars are no longer required to provide WHOIS at all, with .com, .name and .post excepted. Beyond the obligation, RDAP returns structured JSON, so status codes, dates, nameservers and registrar of record can be diffed reliably rather than parsed out of free-form text that varies by registry. Any monitoring built on port-43 WHOIS scraping is running on a service most registries no longer have to operate.

Why monitor Certificate Transparency logs?

Because obtaining a certificate is a step in the attack, not a consequence of it. CISA's Emergency Directive 19-01 described a campaign that ran from compromised credentials to altered DNS records to "obtaining valid encryption certificates for an organization's domain names," and it required federal agencies to begin monitoring CT logs within 10 business days. CT logs record publicly trusted certificates as they are issued and are searchable by anyone, so they surface a certificate obtained for your name including issuance a CAA record did not prevent.

Domain Monitoring