A DNS security policy is the document that tells your team exactly who can touch DNS records, how changes get approved, and what “healthy” DNS actually looks like for your organization – and most companies don’t have one until after something breaks. This guide walks through building that policy from scratch, covering ownership, change control, record standards, and the review cadence that keeps it from going stale.
Skip the temptation to copy a generic security policy template and swap in your company name. DNS touches email deliverability, subdomain sprawl, third-party integrations, and public-facing infrastructure all at once, so a policy that doesn’t reflect how your organization actually provisions and retires DNS records will be ignored within a quarter.
Why a formal DNS security policy matters
DNS is one of the few systems where a single misconfigured record can redirect customer traffic, let attackers spoof your email domain, or hand a subdomain to a stranger who claimed an abandoned S3 bucket or Heroku app. Yet in most mid-sized companies, DNS changes happen through a support ticket to whoever has registrar access, with no review and no log of why the record exists.
A policy fixes this by defining, in writing: who owns DNS administratively, what approval a change needs before it goes live, how records get documented, and what “stale” means for your environment. Without that baseline, audits take days instead of hours, and nobody can say with confidence which of the 40 CNAME records pointing at old marketing tools are still needed.
Step 1: Establish ownership and access control
Every domain and subdomain zone needs a named owner – not “the DevOps team,” but a specific role with a backup. Registrar and DNS provider accounts should sit behind SSO and MFA, never a shared login passed around in a spreadsheet. Cloudflare, AWS Route 53, and NS1 all support role-based access controls that limit who can create versus who can only view records; use them.
A common mistake here: giving broad “DNS admin” rights to an entire engineering org because it’s faster than requesting access per change. That convenience is exactly how a departed contractor’s still-active API key ends up creating a wildcard CNAME nobody notices for eight months.
Step 2: Define change management rules
Every DNS change – new record, modified TTL, deleted entry – should go through the same path your infrastructure-as-code changes do: a pull request or ticket, a second reviewer, and a timestamped log. Terraform with the Cloudflare or Route 53 provider works well here because the diff shows exactly what changed and when.
The policy should specify:
Who can propose a change – typically any engineer provisioning a new service.
Who must approve it – a second person on the infra or security team, never the requester alone.
What documentation is required – purpose of the record, owning team, expected retirement date if temporary.
Maximum TTL for temporary records – campaign or staging subdomains should default to a 90-day expiry review, not live forever.
Emergency change process – a documented fast path for incident response that still leaves an audit trail.
Step 3: Set baseline standards for records
The policy needs concrete technical requirements, not vague language about “secure configuration.” Specify that every domain sending mail must have SPF, DKIM, and DMARC records, and set a minimum DMARC enforcement level – p=quarantine at minimum, moving to p=reject once you’ve confirmed legitimate senders are covered. A soft-fail SPF record (~all) left in place indefinitely is one of the most common gaps found in DNS audits; the policy should require a hard fail (-all) once onboarding is complete.
Also define what’s prohibited outright: wildcard DNS records without documented justification, CNAME records pointing to third-party services the organization doesn’t actively pay for, and NS delegation to providers without a signed data processing agreement if the organization operates under GDPR.
Step 4: Build the subdomain inventory
You can’t secure what you haven’t catalogued. Most organizations discover during their first real audit that DNS zone files list 150+ records but nobody can account for a third of them – old staging environments, agency-created campaign pages, a partner API integration from a deal that closed in 2022. The policy should mandate an initial full inventory and a process for keeping it current, since manual spreadsheet tracking degrades within a few months as teams spin up new subdomains without telling anyone. This is where continuous subdomain discovery earns its place in the policy rather than a one-time spreadsheet exercise – tools built for this, including structured DNS documentation practices, keep the inventory from decaying between audits.
Step 5: Set a monitoring and review cadence
A policy without an enforcement mechanism is a PDF nobody reads. Define how often DNS gets reviewed – quarterly at minimum for most organizations, monthly for anyone running more than a few hundred records or operating in a regulated industry. Annual penetration tests catch some DNS issues, but they miss the record that went stale in month three and sat exposed for the other nine; a shorter, more frequent review cycle closes that gap far more effectively, a point covered in more depth in the case for quarterly over annual reviews.
Pair scheduled reviews with continuous alerting for the things that shouldn’t wait for a quarterly check: a CNAME suddenly pointing to an unclaimed cloud resource, a TXT record disappearing, an SPF record silently modified outside the change process.
Common mistakes when writing the policy
The most frequent failure is writing a policy that describes an idealized process instead of the one your organization can actually sustain – requiring three-person sign-off when the security team has one person guarantees the policy gets bypassed within a month. The second is treating the policy as a one-time document; DNS ownership changes when teams reorg, and a policy that still names someone who left 18 months ago is worse than no policy, because it creates false confidence. Third, teams often write detailed rules for production domains and completely ignore marketing and campaign subdomains, which is precisely where the checklist approach to DNS security tends to catch gaps that ad hoc reviews miss.
Frequently asked questions
How long should a DNS security policy be?
Most effective policies run two to four pages. Longer documents tend to get skimmed once and never referenced again; the goal is a document engineers actually open before making a change, not a compliance artifact.
Who should own the DNS security policy once it’s written?
Ownership should sit with security or infrastructure leadership, but the policy needs input from DevOps, marketing (for campaign subdomains), and IT, since each group creates DNS records independently.
Does a small company with under 50 employees need a formal policy?
Yes, though the process can be lighter – a single approver instead of a review board is reasonable. The core requirements, an owner, a change log, and a periodic review, still apply regardless of headcount.
A DNS security policy only works if it matches the pace at which your organization actually creates and retires records. Start with ownership and a change log, add the technical baseline for SPF, DKIM, and DMARC, and schedule reviews frequently enough that a forgotten subdomain gets caught in weeks, not years.