Domain and DNS Security Checklist: Protect Your Website From Account Takeover

Overview

Domain hijacking and DNS tampering often begin with a compromised account, an exposed recovery email, an overlooked API key, or an unclear ownership process. If an attacker gains control of your registrar or DNS provider, they may be able to redirect website traffic, interrupt email, replace records, or attempt to transfer the domain.

Think of domain security as a chain of controls rather than a single setting. The registrar protects the domain registration and transfer functions. The DNS provider publishes the records that direct traffic and email. Your hosting platform serves the website, while your identity and access controls determine who can change any of these systems.

Use this checklist during a quarterly review, before a major launch, after a staff or vendor change, and whenever you move domain and hosting services. For related operational controls, see the domain renewal and expiration guide and the website backup and restore testing guide.

Core domain security checklist

• Enable multi-factor authentication: Turn on MFA for the registrar, DNS provider, hosting account, primary email account, and any identity provider used to access them. Prefer a phishing-resistant method where the service supports one, and keep recovery methods under controlled ownership.
• Use a dedicated administrative identity: Avoid tying domain ownership to a former employee, personal mailbox, or shared inbox that lacks clear accountability. Use a monitored business address and document who can approve sensitive changes.
• Protect recovery channels: Review recovery email addresses, phone numbers, backup codes, and security questions. They should be current, private, and protected by controls comparable to the main account.
• Apply domain locks: Enable the registrar's available transfer and domain-lock controls. These settings can add friction to unauthorized transfers, but they do not replace MFA or careful account management.
• Review registration data and renewal settings: Confirm that the legal owner, administrative contact, billing contact, and renewal email are accurate. Enable renewal reminders and, where appropriate, automatic renewal with a monitored payment method.
• Limit user permissions: Give staff and service providers only the access they need. Separate billing, DNS editing, domain transfer, and read-only permissions when the platform allows it.
• Audit API keys and tokens: Remove unused keys, record where active keys are used, restrict their permissions, and set an expiration or rotation process. Never place registrar or DNS credentials in public repositories, client-side code, tickets, or chat messages.
• Turn on change alerts: Subscribe to notifications for login events, MFA changes, nameserver changes, DNS edits, contact changes, transfer requests, and lock-status changes. Send important alerts to more than one responsible person.

Checklist by scenario

When securing a new domain

1. Register the domain through an account owned by the business or project, not an individual’s personal account.
2. Enable MFA before adding collaborators or connecting automation.
3. Record the registrar, DNS provider, nameservers, renewal date, owner, and emergency contacts in a restricted internal document.
4. Use domain privacy protection when it fits your legal, operational, and contact requirements. Treat privacy protection as a reduction in public exposure, not as an access-control feature.
5. Publish only the DNS records you need. Confirm that every A, AAAA, CNAME, MX, TXT, and other record has an owner and a purpose. The DNS records guide provides a reference for common record types.

When taking over an existing domain

1. Change the registrar password, DNS credentials, recovery details, API keys, and delegated user access.
2. Review nameservers and DNS records for unexpected providers, redirects, mail destinations, verification records, or stale services.
3. Check forwarding rules and administrative contacts at the registrar and email provider.
4. Confirm that the domain is not awaiting a transfer, renewal, ownership, or contact verification action.
5. Compare the live zone with an approved baseline before removing records. Deleting an unfamiliar record without investigation can interrupt a website, custom email domain, certificate validation, or third-party integration.

When moving DNS or hosting

1. Document the current DNS zone and reduce the time-to-live for records only when there is a clear migration plan.
2. Build and test the new website or service before changing nameservers or production records.
3. Verify SSL certificates, redirects, website uptime, transactional email, MX records, SPF, DKIM, and DMARC after the change. Use the SSL certificate troubleshooting guide if certificate warnings appear.
4. Keep the previous provider available until the new configuration has been observed and validated. DNS propagation can produce a period in which different users reach different answers.
5. After migration, remove obsolete accounts, tokens, users, and records rather than leaving them as permanent fallback access.

When an account may be compromised

Do not begin by deleting evidence or making many unrecorded changes. Preserve relevant alerts and access logs, then use a trusted device to change credentials, revoke sessions and tokens, restore MFA, and contact the registrar or DNS provider through its official support channel. Review nameservers, DNS records, forwarding, SSL configuration, and domain transfer status. If website traffic or email was redirected, coordinate with hosting and email administrators and document the timeline.

What to double-check

DNSSEC is not the same as account security

DNSSEC helps validating resolvers detect altered DNS responses by using digital signatures. It can be a valuable part of a DNS security program when the registrar, DNS provider, and operational process support it correctly. It does not stop someone from logging in and editing the zone. Before enabling or changing DNSSEC, document the signing configuration, key-management responsibility, and recovery procedure. A broken delegation or mismatched signing setup can make records fail validation.

Review email authentication separately

DNS changes can affect both website access and email delivery. Confirm that MX records point to the intended provider and that SPF, DKIM, and DMARC records match the approved email configuration. Be cautious with TXT records: they are commonly used for verification, but an old or unnecessary value may grant a third party continued association with a domain.

Verify the emergency path

Your emergency contact list should identify the domain owner, registrar, DNS provider, hosting provider, email administrator, and the people authorized to approve urgent changes. Store it somewhere available when the primary website or email system is unavailable. Test the recovery process without weakening production security, and make sure at least two trusted people understand it.

Common mistakes

• Using one shared password: Shared credentials prevent reliable accountability and make access removal difficult. Use individual accounts and a controlled password manager instead.
• Protecting the registrar but ignoring email: A compromised mailbox can allow password resets even when registrar MFA is enabled. Secure the recovery mailbox with equal or stronger controls.
• Leaving former providers connected: Old DNS users, API tokens, nameservers, and verification records expand the attack surface and create confusion during an incident.
• Assuming a domain lock prevents every change: Locks generally address transfer-related risk. They do not prevent an authorized or compromised user from editing DNS.
• Changing nameservers without a zone inventory: Missing an MX, TXT, or validation record can break email, certificate issuance, analytics, or other services.
• Relying on memory: If ownership, renewal, access, and recovery procedures are undocumented, an otherwise secure setup can become fragile when personnel or tools change.

When to revisit

Run a lightweight domain security review at least quarterly and complete a deeper review before seasonal planning cycles, major launches, domain transfers, hosting migrations, or changes to your email provider. Revisit the checklist immediately after a staff departure, administrator change, suspected phishing attempt, registrar notification, unexpected DNS edit, or service outage.

At each review, record the date, reviewer, registrar, DNS provider, nameservers, renewal status, privileged users, active API keys, MFA coverage, alert recipients, DNSSEC status, and emergency contacts. Compare the current DNS zone with the approved baseline and remove anything that no longer has a clear purpose.

Finish by assigning owners and deadlines for unresolved items. A practical first pass is to enable MFA, protect the recovery mailbox, remove stale users and tokens, confirm domain locks and renewal alerts, and test that a trusted person can reach the registrar and DNS provider during an outage. Repeat the test whenever your workflows or tools change.