DNS security is not a one-time configuration task. For website owners and publishers, it is an ongoing routine that connects domain ownership, email authentication, website availability, and privacy protection. This guide explains how SPF, DKIM, DMARC, DNSSEC, and WHOIS privacy work together, what to monitor, how to investigate changes, and when to repeat a domain-security review.
Overview
The Domain Name System (DNS) translates a domain name into the technical locations used by websites, email systems, and other online services. Because DNS controls where traffic and messages are directed, an incorrect or unauthorized change can cause outages, redirect visitors, disrupt email, or support impersonation.
Effective domain protection has several separate layers:
- SPF identifies the services allowed to send email for your domain.
- DKIM adds a cryptographic signature to outgoing messages so receiving systems can check that the message is associated with your domain and was not altered in transit.
- DMARC tells receiving systems how to handle messages that fail authentication checks and provides reporting options.
- DNSSEC helps validate that DNS responses have not been altered between the authoritative DNS service and a validating resolver.
- WHOIS privacy, where supported and appropriate, limits the public exposure of contact details associated with a domain registration.
These controls address different risks. SPF, DKIM, and DMARC primarily reduce email spoofing and impersonation. DNSSEC addresses the integrity of DNS answers. WHOIS privacy reduces unnecessary exposure of registration information. None of them replaces strong registrar security, careful access control, backups, or monitoring.
Start by creating an inventory of every domain, subdomain, registrar account, DNS provider, email platform, website host, and third-party sender your organization uses. Include inactive domains and domains used only for redirects or email. An old domain can still be useful to an attacker if it remains trusted by customers or connected to other services.
What to track
1. Registrar and account protections
Record the registrar, renewal date, account owners, recovery email addresses, and the people authorized to approve changes. Use a unique password and multi-factor authentication for the registrar and DNS provider. Prefer a stronger phishing-resistant method when the provider supports it. Review delegated users and remove former employees, unused accounts, and broad administrative permissions.
Check whether the registrar offers a transfer lock or equivalent domain-locking control. Keep the lock enabled unless a planned transfer requires a temporary change. Treat unexpected transfer notices, password-reset messages, and registrar emails as security events that require independent verification.
2. DNS records and ownership
Maintain a current record of important DNS entries, including A, AAAA, CNAME, MX, TXT, NS, CAA, and any records used for verification. For each entry, note its purpose, owner, service provider, and the date it was last reviewed. Remove obsolete verification tokens, test records, and subdomains that no longer point to an active service.
Pay particular attention to abandoned CNAME records. If a subdomain still points to a service that your organization has stopped using, another party may be able to claim or reuse that destination, depending on the provider and configuration.
3. SPF, DKIM, and DMARC
SPF is published as a TXT record at the domain or subdomain used for sending. A simplified example might look like:
example.com TXT "v=spf1 include:mail.example-provider.com -all"This is only an example. Use the exact SPF guidance supplied by your email platforms. Avoid creating multiple SPF records for the same name; receiving systems expect one combined policy. List only legitimate senders, and remove an old provider when it is no longer authorized. Changes to SPF can affect newsletters, password resets, contact forms, and transactional mail.
DKIM requires a public key in DNS, commonly at a selector such as selector1._domainkey.example.com. The corresponding private key is held by the sending service. Track each selector and provider so you know which key belongs to which system. Rotate keys according to the provider's instructions and remove obsolete selectors only after confirming that no active sender still depends on them.
DMARC is published at _dmarc.example.com. A monitoring-only example is:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"A policy of p=none requests reporting without asking receivers to reject or quarantine failed messages. After legitimate senders are identified and authentication is working, an organization may consider a stricter policy, but the change should be deliberate and tested. Keep in mind that DMARC alignment, forwarding, mailing lists, and third-party platforms can affect results. Do not move directly to a strict policy without reviewing legitimate failures.
For a deeper phishing and impersonation checklist, see How to Tell If an Email, Text, or QR Code Is a Phishing Scam.
4. DNSSEC status
DNSSEC generally requires two coordinated parts: signing at the authoritative DNS provider and a DS record at the registrar or parent zone. Record whether the domain is signed, where signing is managed, and who is responsible for the DS record. A mismatch can make a domain unreachable to validating resolvers, so follow the provider's exact activation and rollover process.
Do not copy a DS value from an old setup into a new provider without checking the current key and algorithm details. If you change DNS providers, plan the DNSSEC transition rather than treating it as an ordinary nameserver update.
5. WHOIS privacy and public registration data
Review the registration record for each domain and determine what information is publicly displayed. WHOIS privacy, privacy proxy services, or redaction may reduce exposure of personal contact details, but availability and treatment can vary by registrar, domain extension, and applicable registration requirements.
Use a monitored organizational email address for registrar notices rather than an inbox that no one checks. Privacy protection does not make an account anonymous to the registrar, and it does not replace accurate renewal contacts or strong account security.
Cadence and checkpoints
A simple schedule prevents domain security from being forgotten after the initial setup.
Monthly
- Review DMARC aggregate reports or the reporting service you use.
- Look for new sending sources, authentication failures, unusual volume, or messages sent from systems no one recognizes.
- Check security notifications from the registrar, DNS provider, and email platform.
- Confirm that critical websites, forms, and inbound email still work.
Quarterly
- Compare the live DNS zone with your internal inventory.
- Review SPF includes, DKIM selectors, DMARC reporting addresses, and third-party senders.
- Audit registrar users, recovery methods, multi-factor authentication, transfer locks, and API keys.
- Check for abandoned subdomains, unused verification records, and services that have changed owners.
- Confirm that WHOIS privacy and registration contacts still match your organization’s needs.
After a change
Repeat checks after a website migration, email-platform change, rebrand, acquisition, registrar transfer, DNS-provider move, or launch of a new marketing or customer-support tool. Record the old and new values, the person who approved the change, the expected result, and the rollback plan.
Use an independent DNS lookup or monitoring service to verify public results after a change. The control panel may show a saved value that has not yet propagated or may differ from what external resolvers return.
How to interpret changes
Not every new DNS record or authentication failure indicates an attack. A new legitimate marketing platform, help-desk system, website host, or payment provider can create expected changes. The important question is whether the change has a documented owner and business purpose.
Investigate promptly when:
- Nameservers change without an approved migration.
- A registrar reports a transfer, contact, password, or recovery change you did not authorize.
- DMARC reports show a new sender that no team recognizes.
- SPF or DKIM records change unexpectedly, become duplicated, or stop matching the email provider.
- A subdomain points to an abandoned service or an unfamiliar destination.
- DNSSEC validation fails after a registrar or DNS-provider change.
- Website visitors report redirects, certificate warnings, login failures, or intermittent availability.
First preserve evidence: export the relevant DNS records, save provider notifications, note timestamps, and capture the affected URLs or email headers. Then contact the registrar or provider through a verified support channel. If you suspect account compromise, secure the registrar, DNS, email, and hosting accounts in that order of practical priority, beginning with the account that can change nameservers or recovery credentials.
Authentication reports should be read as operational signals, not as a simple pass-or-fail score. A failed message may result from forwarding, a misconfigured vendor, a new legitimate platform, or a spoofed message. Identify the source, compare it with your inventory, and correct the underlying sender configuration before tightening enforcement.
For related website checks, use How to Check If a Website Is Safe Before You Click, Sign In, or Pay. If a credential was exposed during an incident, follow How to Recover After Phishing.
When to revisit
Review this DNS security plan at least monthly for email signals and quarterly for the broader domain inventory. Revisit it immediately after any unexplained registrar alert, DNS change, email impersonation attempt, website migration, ownership change, or new third-party service integration.
Set calendar reminders before every domain renewal, ideally with enough time to correct outdated payment, recovery, or administrative details. At renewal time, confirm the registrar account, domain contacts, transfer lock, WHOIS privacy setting, nameservers, DNSSEC status, and list of authorized users.
Use this annual review template:
- List every owned domain, subdomain, registrar, DNS provider, and renewal date.
- Verify multi-factor authentication, recovery contacts, transfer locks, and delegated access.
- Export and review the complete DNS zone, removing obsolete records.
- Confirm SPF has one current policy and only approved sending services.
- Confirm DKIM selectors and keys belong to active providers.
- Review DMARC reports and decide whether the current policy remains appropriate.
- Verify DNSSEC signing and DS records if DNSSEC is enabled.
- Check WHOIS privacy, registration contacts, and renewal notifications.
- Test the website, inbound mail, outbound mail, forms, and important subdomains.
- Document owners, evidence, unresolved issues, and the next review date.
Keep the finished review in a restricted business document, and avoid storing private keys, passwords, or recovery codes in the inventory itself. A small, accurate record reviewed on a schedule is more useful than a detailed record that becomes outdated. For broader privacy work, pair this process with the Online Privacy Checklist and the Website Privacy Audit Checklist.
