Handling renewals across many domains

Treat renewals as an availability risk, not an accounting chore. An unpaid server gets you a suspension you can undo; a lapsed domain can end up in someone else's account, and no support queue anywhere reverses that. Almost none of these losses come from a hard decision. They come from a stored payment method that quietly expired, a notice sent to a mailbox nobody reads, or auto-renew switched on for the domain but not the hosting underneath it.

Get every expiry date onto one list you control

The first job is not to change settings, but to find out what you hold and when each piece lapses. Export the list from each registrar and hosting account, then verify it against registry data with a WHOIS or RDAP lookup per name; a panel can show a date that a failed transfer or a pending verification has already moved.

Record eight columns per item: name, registrar, expiry date, renewal term, auto-renew state, payment method attached, who receives the notice, and what breaks if it lapses. That last column turns a billing list into a risk list, because forty domains are never forty equal domains.

Where auto-renew is safe, and where it is not

The rule underneath the table: switching auto-renew off is a decision to lose the item, so make it only after deciding the item is going.

The notification address problem

The classic circular failure is registering a domain with a contact address hosted on that same domain. If it lapses, DNS stops answering, mail stops arriving, and the warning cannot reach anybody. Fix it by policy, not case by case:

• Put registrar and hosting contacts on a domain and provider you are not renewing in that account.
• Point them at a role alias reaching at least two people, never a personal mailbox and never a contractor's.
• Keep registrant and admin details current. Verification mail that bounces can suspend a name on its own, independent of payment.
• Check that alias's quarantine folder once per cycle. Renewal notices look exactly like what filters are trained to bury.

Align terms so you decide twice a year, not monthly

Thirty domains scattered across the calendar produce a decision every twelve days, and each one is small enough to postpone. Collapse them into one or two windows and you get two focused sessions a year instead of thirty distracted ones. Extending a registration adds years to the existing expiry rather than resetting it from today, so you can walk names into a shared window over time, and a transfer usually adds a year of its own. Align the hosting term with the domain term while you are there. Terms are on the domains page.

The pre-expiry review

Run this about six weeks before each window, in order:

1. Confirm the stored payment method is valid past every date in the window.
2. Send a test message to the notification alias and confirm a human replies.
3. For each candidate to drop, check what still points at it: inbound links, redirects, live mail addresses, old hard-coded references.
4. Drop only names that pass step three. Anyone can pick up a dropped name, and your brand stays attached to whatever appears on it.
5. Extend the keepers into the window, setting the term at the same time.
6. After the window, reopen the list and confirm each renewal completed. A queued renewal is not a completed one.

If losing a name would end the project, say so before the window rather than during it. Contact us to have critical items flagged ahead of the automated cycle.