A secure domain depends on more than a strong password at the registrar. This reusable DNS security checklist shows how to review SPF, DKIM, DMARC, nameservers, certificates, subdomains, and account controls so you can detect misconfiguration, email spoofing, and possible domain hijacking before they become larger incidents.
Overview
Domain security is a chain of connected controls. The registrar account controls ownership and delegation. Nameservers determine where DNS records are managed. DNS records direct web traffic, email, verification services, and other systems. TLS certificates help browsers establish encrypted connections, while email authentication records help receiving mail systems assess whether messages claiming to come from your domain are authorized.
A problem in one layer can create confusion or exposure elsewhere. For example, an incorrect nameserver change can make expected records disappear. A broad SPF record can authorize more senders than intended. Missing DKIM or DMARC records can make it harder to identify unauthorized email activity. An abandoned subdomain may continue pointing to a service that the organization no longer uses.
Use this guide as a domain security audit rather than a one-time setup exercise. Record the expected configuration, identify who is responsible for each control, and investigate changes that do not have a corresponding ticket, deployment, provider migration, or approved business reason.
Checklist by scenario
When onboarding a new domain
- Confirm the registrar account uses a unique password and multifactor authentication where available.
- Record the registered owner, administrative contacts, renewal settings, and people authorized to make changes.
- Review registrar transfer protections, domain locks, recovery methods, and notification preferences.
- Document the authoritative nameservers and the DNS provider responsible for the zone.
- List required records before publishing them: A or AAAA records, CNAME records, MX records, TXT verification records, and any service-specific entries.
- Identify every planned sending service before creating an SPF record. Keep the list limited to services that are genuinely authorized to send.
- Enable DKIM for each approved mail platform and record the selector names used by those platforms.
- Publish a DMARC record that matches the organization’s testing and enforcement plan. Begin with a monitored policy only when the sending inventory is incomplete, then tighten it as legitimate senders are confirmed.
Before a DNS migration or provider change
- Export or otherwise preserve the current DNS zone, including records that may not be visible in a simplified dashboard.
- Lower the relevant record time-to-live values ahead of a planned change only when the migration plan requires it; restore appropriate values afterward.
- Compare the old and new zones line by line. Pay particular attention to MX, TXT, CNAME, certificate-authority authorization, and verification records.
- Confirm that both the registrar and DNS provider accounts have current recovery contacts and multifactor authentication.
- Plan validation for the website, email delivery, DKIM signing, DMARC reporting, third-party integrations, and subdomains.
- Keep the previous configuration and rollback instructions available until the new setup has been tested.
When investigating suspected email spoofing
- Save representative messages with their full headers rather than relying only on the visible sender address.
- Check whether SPF passed for the relevant sending IP and whether that IP was authorized by the domain’s SPF record.
- Check DKIM results, including the signing domain and selector. A message can pass DKIM while using a domain that does not align with the visible From address.
- Review DMARC results and alignment between the visible From domain and the authenticated SPF or DKIM domain.
- Compare the incident with DMARC aggregate or forensic reports if your reporting configuration receives them and your handling process permits review.
- Check for unauthorized changes to SPF, DKIM selector records, DMARC, MX records, and mail-provider settings.
When checking for possible domain hijacking
- Compare the current registrar, nameservers, DNS records, and certificate details with your approved baseline.
- Look for unexpected redirects, new login pages, unfamiliar subdomains, unexplained mail-flow changes, or certificate issuance notifications.
- Review registrar and DNS audit logs for changes made by unknown users, unfamiliar locations, or unexpected automation.
- Verify that recovery email addresses, phone numbers, API tokens, delegated users, and billing contacts have not been replaced.
- If compromise is plausible, preserve evidence and use a separate trusted channel to secure the registrar, DNS, hosting, and email accounts.
What to double-check
| Control | What to verify | Warning signs |
|---|---|---|
| SPF | Authorized sending services, a single published SPF policy, and a documented change owner. | Unknown providers, duplicated SPF records, or an entry that is much broader than expected. |
| DKIM | Active signing for every approved mail platform and current selector records. | Unsigned messages, selectors that no longer belong to a provider, or unexpected selector changes. |
| DMARC | Policy, reporting destinations, alignment expectations, and a review process for reports. | No record, reports sent to an unmonitored address, or a policy that does not match the organization’s stated risk tolerance. |
| Nameservers | Correct provider, approved values, account ownership, and change notifications. | Unrecognized nameservers or a sudden change without a migration record. |
| Certificates | Expected certificate names, issuing activity, renewal ownership, and deployment locations. | Certificates for unexpected hostnames or changes that coincide with suspicious DNS activity. |
| Subdomains | Business owner, destination, purpose, and status for every active subdomain. | Abandoned records, third-party destinations no longer in use, or forgotten staging and testing hosts. |
Use more than one view during a review. A DNS lookup can show what is publicly published, but it does not prove that the registrar account or DNS provider account is secure. Provider dashboards may show change history that public lookups cannot. Conversely, external checks can help reveal unexpected public records or propagation differences. For repeatable reviews, save dated results from the same validation methods and compare them with the approved baseline.
For a broader investigation of an unfamiliar domain, pair this checklist with the website safety check guide. If a change appears connected to a phishing campaign, the phishing and impersonation guide can help organize the next steps.
Common mistakes
- Treating DNS as a set-and-forget system. Records outlive projects, providers, and staff changes. Every record should have a purpose and an owner.
- Adding every email provider to SPF. New entries should be approved and tested. Remove services that no longer send mail for the domain.
- Assuming DMARC alone prevents all abuse. Authentication results are useful signals, but they do not replace mailbox security, fraud monitoring, or review of suspicious messages.
- Ignoring subdomains. Staging, support, campaign, and legacy subdomains can expose old applications or point to retired third-party services.
- Making emergency changes without recording them. An undocumented fix can later look like an attack and may be overwritten during the next migration.
- Relying on the browser padlock. Encryption does not establish that a site or account is trustworthy. Review domain ownership, destination, login context, and expected behavior as well.
- Using one administrator for everything. Separate access where practical, review delegated permissions, and maintain recovery paths that do not depend on a single person.
When to revisit
Run a focused review before seasonal planning cycles, major campaigns, domain renewals, and changes to hosting, DNS, registrar, or email providers. Repeat it after an employee with administrative access leaves, after a suspected phishing or account breach warning, or whenever mail delivery and website behavior change unexpectedly.
At minimum, schedule a recurring review for each production domain and keep a dated record of the results. The review should cover registrar access, nameservers, DNS records, SPF, DKIM, DMARC, certificates, subdomains, and third-party integrations. Update the checklist when provider interfaces, workflows, or validation tools change.
Finish each review with three practical outputs: a list of confirmed findings, a list of exceptions with owners and deadlines, and a short incident path for unexplained changes. If you find a likely unauthorized registrar or DNS change, do not quietly overwrite the evidence. Preserve relevant logs and messages, secure affected accounts through a trusted route, and assess whether website visitors, employees, customers, or mail recipients need to be warned. A maintained baseline turns a difficult domain security investigation into a much faster comparison exercise.
