The website that went down on a Saturday
A client's website shows a certificate warning to every visitor. The certificate was bought years ago by the web designer and renewed manually each year. The designer has moved on. The renewal email went to their address. Monday's ticket starts with a scramble to find who controls the certificate and the domain's DNS.
A different client's domain came close to lapsing because it was registered to a former director's personal email address, and the renewal card had expired. Nobody at the MSP knew the domain existed on that registrar at all.
Why expiries catch MSPs out
Domains and certificates sit outside the tools MSPs watch every day. The RMM does not know about them, and the PSA only knows if someone created a record.
- Clients have more domains than they remember, across several registrars.
- Renewal emails go to whoever registered the domain, often long gone.
- Certificates are renewed by web designers, hosting firms or the client.
- Auto-renewal fails silently when a stored card expires.
- Some services (VPN, remote access, on-premises mail) have certificates nobody tracks.
What an expiry costs a client, and you
| Expired item | Effect |
|---|---|
| Domain | Email and website stop working, and recovery can be slow |
| Website certificate | Visitors see warnings and leave |
| Remote access certificate | Staff cannot connect from home |
| Mail-related certificate | Mail delivery or client connections fail |
| Unknown controller | Hours spent finding who can renew |
Whether domains and certificates are within your contract is set by each contract. Even when they are not, knowing about an expiry early lets you warn the client.
The expiry register we build
- Domain discovery per client from their Microsoft 365 or Google Workspace verified domains, email headers, DNS and a list you add to.
- Daily checks of domain expiry dates from public registration data, and certificate expiry by connecting to each public service (website, remote access, mail).
- A record of who controls each domain and certificate: you, the client, a third party, with registrar and contact details.
- Tickets raised in your PSA at intervals you choose before expiry, with the controller named, and a note to the client when a third party is responsible.
- Checks that auto-renewal is on where the registrar or certificate provider shows it.
- A per-client summary for QBRs, showing every domain and certificate with its expiry and controller.
After: expiries become ordinary tickets
Weeks before the web designer's certificate expires, a ticket appears saying the certificate on the client's website will expire, the controller is recorded as the web designer, and the client has been sent a note. The account manager suggests moving the certificate to automated renewal. The domain on the former director's email address shows up in the register as controlled by 'unknown', which becomes a project to transfer it to the client's own account.
Internal certificates that used to surprise you, on remote access gateways and firewalls, appear on the same list, so their renewals are planned rather than discovered by users unable to connect.
Registrar clean-up follows naturally. Once every domain is on the register with its controller, the account manager can suggest consolidating a client's scattered domains into one account the client owns, with your team as a named contact, and turn on auto-renewal with a current payment method. That is the client's choice, and the register gives them the facts to make it: how many domains they hold, where, and which ones they still use.
When a client leaves, the register is also the checklist for making sure domain and DNS control is handed over cleanly.
Could this be your MSP?
- A client domain or certificate has expired without warning.
- You do not have a list of every domain each client owns.
- Renewal emails go to people who no longer work for the client.
- Remote access and firewall certificates are not tracked.
- You are not sure who controls some clients' domains.