Domain Security Checklist: Registrar Lock, 2FA, DNSSEC, and Recovery Settings

Overview

This article gives you a durable domain security checklist built around four control areas: registrar lock, account-level two-factor authentication, DNSSEC setup, and recovery settings. These are not the only protections that matter, but they are among the most important because they affect who can control the domain and how safely DNS changes are made.

Before using the checklist, it helps to separate three layers that are often mixed together:

• Registrar security: protections on the account where the domain is registered, including login security, transfer controls, and ownership details.
• DNS security: protections around nameservers, records, and DNS integrity, including DNSSEC and change discipline.
• Operational recovery: your ability to regain access quickly if a user leaves, a device is lost, or a change goes wrong.

If you only do one thing today, make sure the person who controls the domain is using a dedicated account secured with strong authentication, and verify that domain transfer protections are enabled. That simple step reduces a large share of preventable risk.

For readers managing a broader launch, this checklist pairs well with a full website launch checklist after buying a domain. If you are still sorting out where DNS should live, review how to point a domain to web hosting before making structural changes.

Checklist by scenario

Use the scenario that fits your current situation. If your setup is mature, treat this as an audit list.

1. New domain purchase checklist

When you buy a domain name, security choices made on day one tend to remain in place for years. Start clean.

• Use a dedicated registrar account rather than a personal catch-all account shared with unrelated services.
• Turn on domain 2FA immediately. Prefer an authenticator app or hardware key over SMS if your registrar supports it.
• Create a strong unique password stored in a password manager.
• Enable registrar lock so the domain cannot be transferred casually or by mistake.
• Check who owns the account. The business, not an individual employee or contractor, should control the registrar login and recovery email.
• Review WHOIS or registration contact details for accuracy where visible and applicable.
• Enable domain privacy protection if it fits your jurisdiction and use case. For a deeper review, see the domain privacy protection guide.
• Document the registrar, renewal date, nameserver location, and billing owner in an internal record.
• Decide where DNS will be managed: at the registrar, hosting provider, or a DNS provider such as a reverse proxy or edge platform.

2. Existing domain hardening checklist

If the domain is already live, move carefully. The goal is better security without creating downtime.

• Audit user access and remove ex-employees, old contractors, and unused delegated accounts.
• Confirm the recovery email is current, controlled by the business, and also protected with strong 2FA.
• Enable or verify registrar lock on every important domain, including defensive registrations and alternate TLDs.
• Review nameservers and confirm they point to the DNS provider you expect.
• Export or copy DNS records before making any structural changes.
• Check DNSSEC status. If your DNS provider supports signing and your registrar supports DS records, complete the chain correctly.
• Review MX, SPF, DKIM, and DMARC records if the domain handles email. See Business Email DNS Setup: MX, SPF, DKIM, and DMARC Explained.
• Look at subdomains used for apps, staging, old campaigns, or third-party tools. Unused records and forgotten CNAMEs expand risk.
• Check renewal settings and billing method so a valid domain does not lapse over an expired card or stale invoice contact.

3. Domain transfer checklist

A domain transfer is a moment of elevated risk because you are changing the system of record. Treat it as a controlled change window.

• Do not begin until account ownership is clear and all stakeholders know who approves changes.
• Verify current DNS records and whether DNS will remain with the old provider or move.
• Understand the difference between transfer and DNS changes. A transfer does not have to change website hosting or nameservers, but many people accidentally combine them.
• Unlock the domain only when needed and relock it after the transfer is complete if the new registrar supports it.
• Protect the authorization process and treat any transfer code as sensitive.
• Confirm admin and recovery contacts before and after the move.
• Pause unnecessary DNS edits during the transfer window to reduce confusion.
• Double-check DNSSEC handling. If the DNS host or registrar changes, DS records and signing status may need coordinated updates.
• Monitor the domain after transfer for nameserver changes, email delivery issues, and certificate problems.

If you are planning a broader move, it helps to review your options around shared hosting vs VPS vs cloud hosting so domain changes are not mixed with avoidable infrastructure decisions.

4. DNS provider or hosting migration checklist

Many domain incidents happen during migrations because records are incomplete or rushed.

• Take a full inventory of records: A, AAAA, CNAME, MX, TXT, SRV, CAA, redirects, and verification records.
• Lower TTLs in advance where appropriate before a planned cutover, then restore more normal values after the move.
• Prepare rollback notes so you know exactly how to revert if the new configuration fails.
• Check DNSSEC compatibility before switching nameservers or providers.
• Validate email records so business mail keeps flowing after the cutover.
• Test SSL behavior if you are introducing a proxy or CDN layer.
• Use a DNS propagation checker and monitor from multiple networks after the change. For context, see DNS propagation explained.
• Keep registrar access separate from hosting access where possible. This reduces the chance that one compromised account controls both the domain and the application stack.

If you use a third-party DNS layer, the Cloudflare DNS setup guide is a useful companion for record structure, proxying, and SSL behavior.

5. High-value business domain checklist

For a primary company domain, customer portal, or revenue-driving site, baseline controls may not be enough.

• Use a shared internal process for approvals so one person cannot make major domain changes without visibility.
• Restrict registrar access to a very small group and use role-based separation where supported.
• Store recovery codes securely in a company-approved secrets or password management system.
• Register close variants defensively if brand confusion would be costly.
• Track certificates, nameservers, DNS host, registrar, and billing owner in one internal record.
• Review linked dependencies such as business email, CDN, hosting, and verification tokens.
• Schedule a recurring security review rather than waiting for an incident.

What to double-check

This is the short list of items that deserve a second look because they commonly appear secure while hiding a weakness.

Registrar lock is enabled and understood

Registrar lock helps protect against unauthorized domain transfer, but it is not a universal shield. Confirm what kind of lock your registrar offers and whether it applies only to transfers or also to certain account changes. Do not assume a label alone means every sensitive action is blocked.

Your 2FA method is resilient

Two-factor authentication is only as strong as its recovery path. If you use SMS, ask whether phone-number takeover would expose the account. If you use an authenticator app, confirm backup codes exist and are stored safely. If the registrar supports stronger methods, consider them for your main business domains.

Recovery email security matches registrar security

A well-protected registrar account can still be undermined by a weak recovery inbox. The recovery mailbox should be on a stable business-controlled account with its own strong password and 2FA.

DNSSEC is complete, not partial

DNSSEC setup requires coordination between the DNS host that signs the zone and the registrar that publishes the DS record. A half-finished deployment can create confusion or break resolution. Check that the current provider relationships match the active DNSSEC configuration.

Nameservers point where you think they point

Many site owners remember where records are edited but not where the nameservers actually live. This matters because the effective source of truth may be different from the provider you log into most often.

Renewal and billing settings are current

A domain can be perfectly secured and still fail due to preventable billing issues. Check auto-renew status, payment method validity, invoice contact, and whether renewal notices go to a monitored address.

Email records survive DNS edits

Website changes get most of the attention, but missing MX or TXT records can quietly break business operations. Whenever you adjust DNS, re-check mail flow and authentication records.

Common mistakes

The most common domain security failures are not exotic. They usually come from basic process gaps.

• Using a personal email address as the registrar master account. This creates ownership and continuity problems when roles change.
• Leaving old users in the account. Former team members and abandoned delegate accounts are a long-term risk.
• Confusing registrar and hosting provider responsibilities. Your web host may run the site while your registrar controls the domain. Treat them as distinct systems. If you need a refresher, compare the roles before making changes tied to business hosting choices.
• Turning on DNSSEC without understanding the chain of trust. This is worth doing carefully, not quickly.
• Changing nameservers without copying all records. A website might recover fast while email, verification records, or subdomains fail later.
• Skipping documentation. If only one person knows where the domain is registered or how recovery works, the business has a single point of failure.
• Making several major changes at once. Combining a registrar transfer, hosting move, DNS provider swap, and email change in one session makes troubleshooting much harder.
• Ignoring dormant subdomains and old third-party services. Forgotten DNS entries can outlive the project they were created for.

A good rule is simple: separate structural changes, document each step, and verify outcomes one service at a time.

When to revisit

This checklist works best as a recurring review, not a one-time project. Revisit it at moments when risk is naturally higher or your setup has changed.

• Before seasonal planning cycles when website traffic, campaigns, or staffing changes increase operational pressure.
• When workflows or tools change, especially if you switch registrars, DNS providers, hosting platforms, CDNs, or business email tools.
• Before a site launch or migration so the domain layer does not become the hidden point of failure.
• After team changes such as employee departures, role changes, or contractor offboarding.
• At renewal season to confirm billing, contacts, and portfolio ownership are still correct.
• After any unusual login or support event involving account recovery, password resets, or unexpected provider notices.

For a practical recurring routine, use this five-step review every quarter:

1. Log into the registrar and confirm account owner, 2FA status, recovery options, and active users.
2. Verify registrar lock is enabled on every important domain.
3. Confirm nameservers, DNS host, and DNSSEC status match your intended setup.
4. Check that critical records for web, email, and verification are intact.
5. Review renewal dates, payment method, and internal documentation.

If your domain setup supports a growing application stack, tie this review to infrastructure planning as well. Readers evaluating performance and scaling may also want to compare hosting for WordPress or review VPS hosting options for developers and growing sites. The key is to keep domain control, DNS reliability, and hosting decisions aligned without letting one provider become an unmanaged single point of failure.

Domain security is not about doing everything at once. It is about making sure the basic controls are real, documented, and tested before you need them. If you keep this checklist close whenever your tools, team, or DNS workflow changes, you will avoid many of the quiet mistakes that lead to the most disruptive domain problems.