Domain Expiry Monitoring for Agencies: Stop Losing Client Domains

Jordan's domain-expiry problem is rarely that nobody understands domains expire. The problem is that nobody can answer the operational question fast enough: who owns the registrar account, who pays for renewal, who receives notices, and who has authority to act before the domain lapses?

That is why domain expiry monitoring for agencies needs to be more than a date column. It needs ownership context, warning windows, client communication, and a monthly evidence trail. Public RDAP can surface an early warning, but the registrar account and payment method still decide whether renewal actually happens.

This guide refreshes the agency workflow around the real failure mode: ambiguity. The goal is to prevent website, email, SSL, and client trust failures by making renewal ownership visible before the renewal window becomes urgent.

Why domain expiry is the highest-stakes failure mode agencies face

An expired SSL certificate breaks a website. An expired domain name erases it — or worse, allows someone else to register it.

When a domain expires and is not renewed before the redemption period ends, it returns to the open market. Competitors, domain squatters, and malicious actors actively watch for dropped domains, particularly those associated with established businesses. A client whose company domain is registered by a squatter faces a recovery process that can take weeks and cost thousands — or may not be recoverable at all.

Unlike SSL certificate expiry, which causes a browser warning, domain expiry causes a complete site outage: DNS resolution fails, email stops working, and all services tied to the domain go dark simultaneously. For a client who relies on their domain for business email, this is an immediate operational crisis.

Agencies are responsible for this more often than they should be. The typical scenario: a client asks you to manage their website, your agency is the technical contact for the hosting, but domain registration stays with the client — or was set up years ago by a previous agency. Nobody checks it. The domain renews automatically for two years. Then the credit card on the registrar account expires, the auto-renewal fails, and the domain lapses while everyone assumes the other party is handling it.

The domain lifecycle every agency should understand

Registration and auto-renewal

A domain registration is an annual or multi-year lease. Most registrars default to auto-renewal, which works reliably as long as the payment method on the account is current. The failure modes are:

• Expired credit card: The most common cause of accidental domain lapses. Registrar sends renewal notices to an email address nobody monitors. Auto-renewal fails. The domain enters the grace period.
• Billing account closure: A client closes the email address or credit card account associated with the registrar.
• Registrar account lockout: Password reset issues, two-factor authentication problems, or account deactivation after inactivity.
• Ownership ambiguity: The domain was registered by a previous web agency and the current agency does not have registrar access.

Grace period and redemption period

After expiry, most gTLDs (.com, .net, .org) follow this sequence:

Use this structured version:

• Phase: Active; Typical duration: Until expiry; What happens: Normal operation; Domain usable?: Yes
• Phase: Grace period; Typical duration: 0–45 days after expiry; What happens: Registrar notifies, renewal at normal price; Domain usable?: No (DNS usually stops resolving)
• Phase: Redemption period; Typical duration: 30 days; What happens: Renewal available at elevated fee ($80–200+); Domain usable?: No
• Phase: Pending delete; Typical duration: 5 days; What happens: Cannot be renewed; deletion queued; Domain usable?: No
• Phase: Available; Typical duration: After deletion; What happens: Domain returns to open registration; Domain usable?: No (gone)

Country-code TLDs (.co.uk, .de, .fr) have different timelines, often shorter. Some ccTLDs drop domains within days of expiry.

The agency responsibility ambiguity problem

The most dangerous configuration for domain expiry is ambiguity about who is responsible for renewal.

In a typical agency-client relationship, responsibilities are divided but not always clearly documented:

• Agency controls: hosting, SSL configuration, DNS records, deployments
• Client controls: domain registrar account, billing, renewal

When both parties assume the other is handling it, neither checks. The domain expires.

Mapping ownership for every client

Build a clear record for each client domain:

Use this structured version:

• Field: Registrar; Options: Name the registrar explicitly — Namecheap, GoDaddy, Cloudflare Registrar, Google Domains, etc.
• Field: Who pays for renewal; Options: Client direct, agency billing, third-party
• Field: Who has registrar access; Options: Client only, agency only, shared, previous agency
• Field: Auto-renewal status; Options: Enabled / disabled / unknown
• Field: Renewal notice email; Options: The email address the registrar sends to
• Field: Next renewal date; Options: The date you are monitoring

"Unknown" in any of these fields is a risk. Resolve it with the client, ideally at project onboarding.

Getting the renewal date without registrar access

You do not need registrar access to check a domain's expiry date. WHOIS data includes the expiry date for most gTLDs:

whois example.com | grep "Expiry Date"

For ccTLDs and privacy-protected registrations, WHOIS may not include the date. In those cases, external monitoring tools that track expiry via alternative sources (RDAP, registrar-specific data feeds) are necessary.

Setting alert thresholds for domain expiry

Domain renewal is slower than SSL renewal — you often need to confirm billing details, get client approval for multi-year renewals, and handle transfer paperwork if the domain needs to move registrars. Alert windows should be longer than for SSL.

Use this structured version:

• Alert level: Early warning; Days remaining: 90 days; Recommended action: Confirm auto-renewal is enabled; verify payment method
• Alert level: Alert; Days remaining: 60 days; Recommended action: Contact client if they control the registrar
• Alert level: Warning; Days remaining: 30 days; Recommended action: Escalate — begin manual renewal or transfer if needed
• Alert level: Critical; Days remaining: 14 days; Recommended action: Immediate action; domain may lapse during renewal process
• Alert level: Emergency; Days remaining: 7 days; Recommended action: Emergency renewal; domain squatting risk is imminent

Ninety-day early warnings feel distant, but they give you time to handle the common failure scenario: auto-renewal is enabled, but the payment method has expired, and getting updated billing details from a client takes three email exchanges over two weeks.

Domain expiry and SSL: the compounding failure

Domain expiry and SSL expiry are separate events with separate monitoring requirements, but they are operationally linked in one important way: a lapsed domain destroys auto-SSL-renewal.

When a domain expires, DNS resolution fails. Any ACME-based SSL renewal that relies on DNS propagation or HTTP validation will also fail. If your SSL monitoring shows a certificate entering its warning window at the same time a domain is approaching expiry, the risk is compounded: the SSL renewal may silently fail because DNS is broken.

This is why unified monitoring — checking both domain expiry and SSL expiry together — gives you a clearer picture than two separate tools. See the SSL expiry tracking guide for how to structure the SSL side of this.

Including domain expiry in client reporting

Domain registration status is a straightforward addition to monthly client reports. Clients appreciate seeing their domain registration date alongside SSL expiry and DNS health — it makes the "we are watching everything" claim concrete.

For a report format that covers both, see the client website health report template.

Build the domain renewal control record

A domain expiry date is useful, but it is not enough. The operating record should explain whether the agency can act, whether the client must act, and what evidence supports the status. A domain governance register is the durable place to keep that owner, purpose, lifecycle, renewal decision, and review context. For every client domain, keep a lightweight control record with these fields:

• Domain: the exact registered domain.
• Client or brand: who depends on it.
• Registrar: the company controlling registration.
• Registrar account owner: agency, client, founder, previous vendor, reseller, unknown.
• Renewal payer: who pays the invoice or owns the card.
• Notice mailbox: where registrar notices go.
• Auto-renew status: enabled, disabled, unknown, or not visible.
• Public expiry date: the RDAP or other public-signal date if available.
• Registrar-confirmed expiry date: the dashboard-confirmed date when accessible.
• DNS provider: current nameserver owner.
• Email dependency: whether MX records indicate business email depends on the domain.
• SSL dependency: whether key hostnames have certificates that rely on the domain resolving.
• Last review date: when the ownership record was last confirmed.
• Next action: monitor, confirm, renew, transfer, update payment, or escalate.

Unknown values are not paperwork defects. They are risk signals. A domain with 200 days of runway but unknown registrar ownership should still enter the cleanup queue, because the team will not want to solve ownership for the first time at day 14.

Warning windows that reflect ownership reality

The right warning window depends on who controls renewal. If the agency owns the registrar account and payment method, a 30-day warning may be manageable. If the client owns the registrar or the account owner is unknown, 90 days is not excessive.

Use these practical tiers:

• 90 days: confirm owner, auto-renew state, notice mailbox, and payment responsibility.
• 60 days: contact the client if they own renewal or if ownership is unknown.
• 30 days: escalate to a named person; do not rely on passive reminders.
• 14 days: urgent operational risk; verify registrar access or client confirmation immediately.
• 7 days: incident-prevention mode; website and email continuity may be at risk.
• Expired: incident mode; follow the expired client domain recovery checklist and communicate clearly.

The date alone should not determine urgency. A client-owned domain inside 60 days can be more urgent than an agency-owned domain inside 30 days, because the agency cannot complete the action without the client.

Monthly review questions

During the monthly domain health review, ask these questions for each warning or limited-data domain:

1. Is the public expiry date complete enough to trust?
2. Has the registrar-confirmed date been checked recently?
3. Is auto-renew enabled, and is the payment method current?
4. Does the agency have authority to renew if needed?
5. If the client controls renewal, has the client confirmed ownership and payment?
6. Are MX records present, meaning email may fail if the domain lapses?
7. Are important SSL certificates approaching renewal at the same time?
8. Has the outcome been recorded for next month's report?

These questions are simple, but they prevent the common mistake of treating monitoring as resolution. A warning is not resolved until the renewal path is known or the owner has accepted the action.

How to report domain expiry risk without sounding alarmist

Use language that is specific and measured:

example.com is inside the 60-day renewal review window. Public registration data shows an expiry date of [date]. Because the registrar account is client-owned, please confirm auto-renew and payment status by [date]. If the domain is not renewed, website and email services tied to the domain may stop resolving.

If data is limited:

Public registration expiry data for example.com is incomplete. We recommend confirming the renewal date directly in the registrar account and recording the renewal owner in the domain register.

If renewal is confirmed:

Renewal ownership for example.com was reviewed this month. Auto-renew is confirmed in the registrar account, and no client action is needed at this time.

The point is not to frighten clients. It is to make ownership and action visible early enough that renewal does not become a surprise.

If ownership stays unknown

Do not let an unknown owner sit as a note forever. Unknown ownership needs its own escalation path because it is usually the thing that turns a routine renewal into an incident.

If the registrar owner is still unknown after the first review, ask the client to search for renewal emails, invoices, card charges, registrar names, and old agency handover notes. Check whether the domain's nameservers reveal a likely DNS provider, but do not treat the DNS provider as proof of registrar ownership. A domain can be registered at one company and hosted at another.

If the domain is important and the registrar is still unclear inside the 60-day window, move the task out of passive monitoring. Assign one person to find the account owner, open a client-facing ticket, and decide whether a registrar transfer should be started after renewal is safe. The worst outcome is not simply that the domain expires. The worse operational outcome is discovering during an incident that nobody ever had authority to renew it.

Connect domain expiry to evidence, not auto-renew promises

CertPilot can support this workflow by checking public RDAP/domain expiry signals, keeping customer-entered owner and renewal-decision notes, and including domain expiry in the on-demand Domain Health Report. It does not renew domains, process payments, log in to registrar accounts, guarantee recovery, prove legal ownership, or transfer domains. If renewal action is required, the registrar owner must complete it in the registrar's own system.

That boundary is useful. The report can say exactly what was observed and what should happen next without implying CertPilot has authority it does not have.

What CertPilot monitors for domain expiry

CertPilot checks public domain registration signals alongside SSL and DNS monitoring, so teams can review domain health in one place:

• Domain expiry date checked from public registration/RDAP-style signals where available
• Days remaining with review thresholds and status labels
• SSL expiry on the same dashboard, so you catch compounding failures
• DNS health to surface misconfigurations before they block renewals
• Client grouping for portfolio-level views
• On-demand Domain Health Reports that include domain expiry alongside SSL and DNS evidence

The external footprint monitoring for domains and expiry page explains how RDAP/domain expiry checks fit with SSL, DNS, and email-authentication monitoring.

Review External Footprint Monitoring for the monitored workflow, or run a free 10-domain audit with no account needed.

External references

• ICANN domain expiry policy — the formal ERRP that governs grace and redemption periods for gTLDs
• RDAP (RFC 7483) — the modern replacement for WHOIS used to query registration data
• Verisign domain lifecycle — .com/.net registry timeline data

Related resources

• Full renewal ledger checklist — the hub where domain expiry sits alongside hosting, SaaS, plugin, and contract renewals.
• Domain and hosting renewal checklist for agencies
• Client domain about to expire workflow
• Client asset register for web agencies
• How CertPilot checks domains

Frequently Asked Questions

What should agencies monitor for domain expiry?

Agencies should monitor the registration expiry date, registrar, renewal owner, auto-renewal status when known, and whether public RDAP data is complete.

Domain expiry monitoring agencies rely on should also connect expiry risk to DNS, email, SSL renewal, and client ownership notes.

How early should agencies warn clients about domain expiry?

Ninety days is a practical early warning for client-owned domains because registrar access, payment updates, and ownership questions can take time.

Use shorter escalation windows as expiry approaches, such as 60, 30, 14, and 7 days, depending on the domain's importance.

What if the agency does not control the registrar?

The agency should warn the client, document the ownership boundary, and ask for confirmation that auto-renewal and payment details are current.

Do not promise renewal if the registrar account is outside agency control. The useful role is monitoring, reporting, and clear follow-up.

Should domain renewal be part of agency care plans?

Yes, at least as a documented responsibility. A care plan should state who controls the registrar, who pays for renewal, and how expiry warnings are handled.

Even when the client owns the registrar account, domain health reports help keep the risk visible.