Domain Monitoring: Build an Expiry and Availability Workflow That Works

The worst time to discover a domain problem is after customers stop reaching it. Registration expiry can interrupt a website, mail, login, or API even when every server behind the domain is healthy. A forgotten defensive registration can also become available to someone else. Monitoring reduces that risk, but only when the monitored signal, the responsible person, and the response are clearly defined.

Domain monitoring is often used as an umbrella term for several different jobs. Registration monitoring watches availability, expiry, and registration status. DNS monitoring watches records and delegation. Certificate monitoring watches validity and issuance. Mail monitoring watches MX and authentication policy. Brand monitoring looks for confusing registrations. These jobs support one another, but one check does not automatically cover all of them.

Start With the Failure You Need to Prevent

For a domain you already own, the first question is usually whether the registration is approaching expiry or has entered an unexpected state. For a domain you hope to acquire, the question is whether its registration becomes available. Those two cases use similar registration data but require very different responses. An owned production domain should trigger renewal and registrar investigation. A watched acquisition target should trigger a fresh verification and a purchase decision.

Write the response before you create the alert. Name the registrar account owner, the renewal method, the payment contact, and the escalation path for each critical domain. For acquisition targets, name the budget owner and the approved registrar. An alert without authority or context becomes another notification that somebody assumes somebody else will handle.

• Production domains need a verified registrar owner and renewal path.
• Defensive registrations need a keep-or-release decision before renewal time.
• Acquisition targets need a budget, a verification step, and a clear buyer.
• Every alert channel needs a person or team that is expected to act.
• Unknown or conflicting data needs a manual verification path.

What DomScan Domain Monitor Checks

A signed-in user can add domains to a DomScan portfolio and choose a check frequency. The scheduled monitor checks whether each domain appears registered or available and reads an expiration event when the registration source provides one. It classifies results as registered, available, expiring soon, or unknown. Expiring soon currently means a reported expiry date within 90 days.

The monitor stores the most recent check time, expiry date when available, days until expiry, check count, notes, tags, and configured frequency. The account interface can filter and sort the portfolio, and a manual check is available when you need a fresh result immediately. Manual checks consume credits because they run the underlying availability workflow.

Scheduled frequencies include hourly, every six hours, daily, and weekly. Faster schedules are restricted to paid accounts. A selected frequency is a target cadence, not a contractual guarantee that every upstream registry will respond or that a result will arrive at an exact second. Network failures, registry limits, incomplete RDAP events, and ambiguous responses can produce an unknown state.

When configured conditions are met, DomScan can record an in-app alert and queue enabled notification channels. Current channels include email, Telegram, signed webhooks, Slack, and Discord. Notification settings decide which events and channels are active. Test the chosen channel after setup, and keep an independent registrar renewal contact in place. A monitor complements registrar notices; it should not be the only control protecting a valuable name.

What It Does Not Check Automatically

Domain Monitor does not currently compare DNS record sets, certificate chains, HTTP responses, mail authentication, subdomains, reputation lists, or lookalike registrations on each scheduled run. It also does not claim to identify ownership changes. A registrar or status transition can be useful evidence, but registration data is often redacted and a technical change does not establish who caused it.

This boundary matters because the old version of this guide described a broad, unified monitoring profile as if DomScan executed every item. It does not. The product provides separate tools for current DNS, SSL, domain health, WHOIS, RDAP, typosquatting, and related checks. Those tools are valuable for investigation and periodic review, but they are not silently attached to every Domain Monitor schedule.

If DNS or certificate drift could break your service, configure a dedicated system for those signals. Use the DNS Lookup tool to inspect current records, DNS History to review prior DomScan observations, and the SSL checker for a current certificate inspection. DNS History is an observation log populated by qualifying lookups, not a continuous global archive. The SSL checker is an on-demand view, not proof that certificate alerts are enabled.

Build a Tiered Portfolio

Not every domain deserves the same interrupt path. A primary login domain, customer-facing API domain, or flagship mail domain can justify frequent registration checks and immediate escalation. A parked campaign name may only need a weekly review. A speculative acquisition target may be important to one buyer but irrelevant to operations. Tiering keeps urgent alerts rare enough to remain credible.

1. Tier 1: domains whose loss would interrupt customer access, authentication, mail, payments, or a critical API. Assign a named owner, faster checks, and more than one notification channel.
2. Tier 2: important redirects, regional domains, defensive registrations, and campaign infrastructure. Use daily or weekly checks based on consequence and renewal process.
3. Tier 3: low-value experiments, parked names, and acquisition candidates. Keep the response proportional and remove names that no longer have a business reason.
4. For every tier, record notes and tags that explain purpose, owner, registrar context, and the expected action when status changes.

The tier should reflect business consequence, not how interesting the domain looks. A plain redirect can be critical if customers or identity providers depend on it. A visually prominent campaign domain may be disposable after the campaign ends. Review the list with the teams that understand customer journeys, mail, authentication, and legal commitments.

Handle Expiry Dates Carefully

An expiry date in registration data is an operational signal, not a promise that a domain will become publicly available on that date. Registry and registrar policies can include auto-renewal, grace, redemption, deletion, or auction stages. Timelines vary across top-level domains and providers. If an owned domain appears close to expiry, confirm renewal directly with the registrar. If an acquisition target passes its reported expiry date, keep verifying rather than assuming it can be registered.

ICANN's Expired Registration Recovery Policy applies to covered gTLD registrations and defines notice and recovery requirements, but it does not make every domain or every top-level domain follow one universal release schedule. Country-code operators set their own policies. The registrar account, registry rules, and current registration status remain the authoritative operational sources for a renewal or recovery decision.

Respond to Unknown and Conflicting Results

Unknown is a valid monitoring state. It can mean the upstream source failed, the top-level domain lacks expected RDAP coverage, the response was ambiguous, or a transient network problem occurred. Do not convert unknown into available. Run a manual check, inspect WHOIS or RDAP directly, and use the registrar or registry's own lookup before taking action. For a critical owned domain, repeated unknown results deserve escalation because they hide the condition you intended to monitor.

Conflicting dates also need human review. Registry and registrar responses can expose different events, and cached tools may lag. Save the raw context where possible, note when each source was checked, and prefer the registrar account for renewal status. The goal is not to force every source into false agreement. It is to identify which source is fit for the decision you need to make.

A Practical Setup and Review Cycle

1. Inventory the domains that support customer access, mail, authentication, APIs, redirects, and defensive protection.
2. Confirm each domain's registrar account, renewal method, billing owner, and recovery contact outside DomScan.
3. Add the domains to Domain Monitor, choose a frequency based on consequence, and attach useful notes and tags.
4. Enable at least one notification channel with a real responder, then send a test notification from the settings page.
5. For critical names, schedule separate DNS, certificate, mail, uptime, and brand reviews with the appropriate tools.
6. Review the portfolio after launches, acquisitions, provider migrations, and staff changes. Remove stale names and reassign owners.

A quarterly control review should answer simple questions. Are all critical domains present? Does each have an owner? Are the registrar and billing contacts current? Are notification tests succeeding? Are alert thresholds still appropriate? Does the portfolio contain names that nobody recognizes? A technically correct check cannot compensate for an abandoned account or an expired payment method.

Where DomScan Fits

Use Domain Monitor as the registration-status part of your control set. It gives signed-in users a portfolio, configurable check frequency, status and expiry context, notes and tags, alert history, and several notification options. Use Domain Availability, WHOIS, or RDAP when a result needs immediate registration verification.

Use separate current-state tools for the other layers. DNS Lookup shows current records, SSL Certificate Checker inspects the certificate served by a host, and Domain Health combines several on-demand checks. This is a clearer and safer model than pretending one registration monitor covers every domain risk.

Independent references: ICANN's registrant information explains the registrant's relationship with the registrar. ICANN's ERRP guidance covers expiration notices and recovery for applicable registrations. Let's Encrypt's monitoring guidance shows why certificate monitoring belongs to its own control rather than being assumed from domain registration monitoring.