How to track domain expiration across multiple registrars

Letting a domain expire by accident is not a hypothetical risk. In 1999, Microsoft lost msn.com temporarily because a renewal check bounced. Foursquare's domain lapsed in 2010 while the company was at its peak. The common thread isn't negligence, it's fragmented visibility. When your domains are spread across multiple registrars, you're depending on each of them to remind you at the right time, through an email address you actually monitor. This article explains how to build a centralized domain expiration tracking system that doesn't depend on any of those assumptions being true.

Why registrar reminder emails are not enough

The email-based reminder system at most registrars has several failure modes that are easy to overlook until one of them bites you:

• Spam filtering: registrar emails routinely end up in spam folders, especially if your email provider has aggressive filtering or you use a catch-all address.
• Stale contact email: the email on file at a registrar might be a previous employee's address, a shared inbox that nobody monitors, or a personal email that's since been abandoned. Registrars don't verify that contact information is still active.
• Auto-renew dependencies: if auto-renew is enabled, many registrars reduce or stop sending reminder emails. If the associated payment method then expires or fails, the domain may not renew and you won't have received manual warnings.
• Multi-registrar fragmentation: if you have domains at GoDaddy, Namecheap, and AWS Route 53, you're receiving three different email formats from three different systems, with no consolidated view.

None of these failure modes are unusual. They're the normal operating conditions for any organization that has accumulated domains over several years.

How RDAP exposes the expiration date

The expiration date for a domain is stored in the events array of the RDAP response, under eventAction: "expiration". This is a direct read from the registry's database, not from the registrar's system. Whether you registered through GoDaddy or Gandi or directly via an API, the expiration date in RDAP reflects what the registry actually has on record.

Domain Sentinel reads this field at each verification cycle. If you renew a domain through your registrar and the registry updates its data, Domain Sentinel will reflect the new expiration date on the next check, without you needing to update anything manually.

What if the domain doesn't support RDAP?

Some TLDs (predominantly country-code domains like .ru, .cn, and various African and Asian ccTLDs) don't yet expose RDAP endpoints. Domain Sentinel falls back to WHOIS for these domains. WHOIS is less standardized: the expiration date field name and date format vary by registrar, and parsing can occasionally produce incorrect results. For domains on major TLDs (.com, .net, .org, .io, .fr, .de, .co.uk), RDAP is available and reliable.

Setting up a centralized expiration tracking system

Phase 1: build your domain inventory

Before you can track expiration dates, you need to know what you own. This sounds obvious but many organizations have domains they've forgotten about, registered for a project that never launched, or transferred from a previous provider without full documentation.

Practical ways to find them:

• Search old email inboxes for "domain registration confirmation" messages.
• Check invoices from your accounting system for registrar charges.
• Look at DNS records pointing to current infrastructure, each subdomain implies a parent domain.
• Ask colleagues in IT, marketing, and legal, people tend to register domains without telling anyone.

Phase 2: configure Domain Sentinel

1. Add each domain to your watchlist. Use the lookup bar, search for the domain, and click "Add to watchlist." Domain Sentinel queries RDAP and displays the current expiration date.
2. Verify the expiration date matches what your registrar shows. If there's a discrepancy, investigate, a mismatch can indicate a data sync issue at the registrar.
3. Configure expiration alerts per domain. Set the thresholds that make sense for each domain's criticality.
4. Use an email address you actually read. Not the one on file at the registrar, a team inbox or personal address that someone checks daily.

Recommended alert thresholds by domain type

Domain type	90-day alert	30-day alert	7-day alert	Why
Primary domain (main site, email)	Yes	Yes	Yes	Maximum criticality
Secondary domain (redirect, alias)	No	Yes	Yes	Sufficient coverage
Defensive domain (brand protection)	No	No	Yes	Low priority but can't lose
Domain for sale or parked	No	Yes	No	Business decision at 30 days

The 90-day threshold is worth explaining. If you have a domain expiring in 90 days, you have three months to either renew it or make a deliberate decision to let it go. That's not an emergency, it's a planning window. The 7-day alert is the operational urgency marker.

Does auto-renew make expiration tracking unnecessary?

Auto-renew is a good practice. It is not a sufficient replacement for expiration tracking. Here's why.

Auto-renew fails when: the credit card on file expires, the PayPal account gets closed, the billing email stops working, or the registrar has a payment processing outage. All of these happen. They tend to happen at the worst times, when someone is on vacation, when a card was recently replaced and the registrar wasn't updated.

Expiration tracking is a safety net on top of auto-renew, not a competing approach. The two together eliminate virtually all risk of unintentional domain loss. Either one alone leaves a gap.

A domain expiring takes your website offline, breaks your email, and in some cases erases years of SEO equity, within hours. Expiration tracking takes 30 minutes to set up once and eliminates that risk permanently. If you have more than two active domains, it's critical infrastructure.