Skip to content

Field note

Recover Domain and DNS Administrator Access

The person who registered the domain should not be its only recovery route.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 800 words.

An organisation can have working website backups and still struggle to recover if nobody can reach the registrar or DNS account. The registration may sit with an old supplier, renewal notices may reach a former employee, and account recovery may depend on email delivered through the broken domain.

Resolve those dependencies while the domain works. The aim is an authorised alternative route to the existing accounts and a verified record of the configuration needed to run the service.

Establish who controls each part

Create a short ownership record for every important domain. Include the registrant organisation, registrar, reseller if relevant, authoritative DNS provider, renewal date, payment owner and named account administrators. Record who can change nameservers and who can change ordinary DNS records; they may use different accounts.

ICANN's registration process explanation distinguishes registrants, registrars, resellers and registry operators. It also distinguishes country-code domains such as .uk from the generic-domain arrangements it describes. Use the actual registrar and registry terms for your domain rather than assuming one transfer or recovery process applies everywhere.

Check the account directly with an authorised administrator. An invoice from a web agency does not establish which business is recorded as the registrant or who can approve an account change. Resolve any discrepancy with the supplier through its normal process and retain the resulting record.

Add an independent reminder to review renewal and payment details. Automatic renewal is useful, but the plan should still identify who handles an expired card, a disputed invoice or a notice sent to an unattended mailbox.

Avoid recovery that depends on the failed service

Review each administrator's sign-in and recovery methods. Where the provider supports it, use named users with appropriate roles and more than one authorised administrator. Secure recovery material so it remains available if the primary mailbox or identity provider is unavailable.

The provider's fallback process may take longer than your outage target. For example, Cloudflare's documented account recovery process can depend on access to the account email and a previously verified device; a successful device verification is followed by a waiting period. It is a fallback to understand in advance, not an assumption of instant support access.

Do not create a shared weak password to make emergency access convenient. Document how an authorised person retrieves protected recovery material, how that access is recorded, and what gets replaced afterwards. Test that the named backup administrator can sign in and view the required settings without changing live records.

Export DNS, then record what the export omits

Keep a dated export of the zone after meaningful changes. Store it with the domain record in a location independent of the DNS account. Cloudflare, for example, supports DNS record import and export, including provider-specific attributes in comments. An export's behaviour and portability need checking before it is used elsewhere.

Record the surrounding settings separately: DNSSEC delegation, redirects, proxy status, origin addresses, certificate arrangements and any traffic rules outside ordinary DNS. A zone file is a record inventory, not a complete replacement for every feature of a hosting or edge platform.

For each record, identify the service owner and purpose. Pay particular attention to mail routing, certificate validation, verification records and third-party applications. Retain enough context to distinguish a deliberate legacy record from one that can safely be retired.

Our SPF, DKIM and DMARC guide explains the email authentication records that need to survive a DNS recovery. Include their operational owner in the plan.

Rehearse a controlled reconstruction

Use a test domain or an isolated configuration review to check that another administrator can interpret the export and supporting notes. Compare the reconstructed records with the current authoritative answers. Do not change production nameservers just to demonstrate that a login works.

If you need a provider migration, plan DNSSEC and cached-record timing with both providers before changing delegation. Keep the old service available through the transition where possible. Record the conditions under which you would stop or reverse the migration, including how existing cached answers will behave.

The finished recovery pack should answer four questions quickly: who owns the domain, who can regain access, what configuration must be restored, and who approves the change. Review it when suppliers, administrators, payment methods or hosting arrangements change. That is more useful than discovering the account's history during an outage.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?