The Journey to a Healthy, Secure DNS: A Step-by-Step Roadmap
Most domains accumulate their DNS and email setup one ad hoc change at a time: a marketing tool added here, a record copied from a tutorial there. Getting to a genuinely healthy, secure setup isn't one task, it's a sequence, and doing the steps out of order tends to either break real mail or leave the biggest gaps unaddressed the longest.
Last updated: August 30, 2026
Stage 0: See what's actually there
Before changing anything, find out what's already published. A domain that's changed hands, hosts, or vendors over the years usually has DNS records nobody currently at the organization remembers adding, and some of those records are load-bearing. Run a full scan first and read every result, including the ones that look fine, since the goal here isn't to fix anything yet. It's to have an accurate map before touching a single record.
Once a record is changed, it doesn't take effect everywhere instantly. Understanding why resolvers around the world can show different answers for a while after an update matters for every stage that follows, so it's worth reading before making the first change, not after being confused by one.
Start with the free domain scanner on this site, and see the DNS propagation guide for why changes take time to show up everywhere.
Stage 1: Stop email spoofing
For most domains, this is the highest-impact stage relative to the effort it takes, which is why CISA's own federal directive sequenced it ahead of web hardening. Three records work together: SPF lists which servers are allowed to send as the domain, DKIM lets a receiver verify a message wasn't altered by checking a cryptographic signature, and DMARC tells receivers what to do when a message fails both, and where to send reports about it.
DMARC specifically should not start at its strictest setting. RFC 7489 defines p=none as a monitoring policy that should not change how receivers handle mail, precisely so the aggregate reports it generates can surface every legitimate source currently sending as the domain, including ones easy to forget, before anything starts getting rejected. The standard progression is p=none to watch and learn, then p=quarantine, then p=reject once the reports show every real sender is authenticated.
Build the three records with the SPF Record Builder, the DKIM Key Pair Generator, and read the reports that guide the DMARC rollout with the DMARC Aggregate Report analyzer. The SPF and DKIM guides cover each record in depth.
Stage 2: Decide who can issue certificates for the domain
Without a CAA record, any publicly trusted certificate authority is allowed to issue a certificate for the domain, which is the default the CA/Browser Forum's baseline requirements assume in its absence, not something anyone had to opt into. Publishing a CAA record naming only the CA (or CAs) actually in use closes that off, and it's a five-minute change once Stage 0 has confirmed which CA that actually is.
Check and build one with the CAA Record Checker & Builder; the CAA guide covers the parent-domain walk CAs perform when checking it.
Stage 3: Stop the TLS downgrade on inbound mail
SPF, DKIM, and DMARC authenticate who sent a message. They don't stop an attacker positioned on the network path from downgrading the connection that delivers it to an unencrypted one. MTA-STS closes that gap by letting a domain declare that inbound mail must arrive over a verified TLS connection, and TLS-RPT gives visibility into delivery failures that policy causes, so it doesn't need to be deployed blind.
Generate both with the MTA-STS & TLS-RPT Generator; the MTA-STS guide explains the downgrade attack it prevents.
Stage 4: Harden the web-facing side
This stage covers three separate but related checks. First, the TLS certificate chain itself: a leaf certificate that doesn't chain correctly to a trusted root breaks trust for visitors even if the certificate itself is valid. Second, HTTP security headers like HSTS and a content security policy, which are the web equivalent of the mail-side hardening in the earlier stages. Third, dangling DNS: a CNAME or A record still pointing at a cloud resource, subdomain, or third-party service that's since been deprovisioned, which an attacker can sometimes claim and use to serve content from a subdomain of the real domain.
Check these with the SSL/TLS Certificate Inspector, the HTTP Security Headers Analyzer, and the Subdomain Takeover Checker.
Stage 5: Watch beyond the domain's own DNS
Everything so far secures records the domain itself controls. Attackers don't need to touch those records at all to impersonate a brand: registering a lookalike domain, one character off or with a different TLD, and standing up a phishing page or spoofed mail flow from it works whether or not the real domain's DNS is perfectly configured. This is the one stage that's ongoing by nature rather than a one-time setup, since new lookalikes can appear at any point.
Scan for existing lookalikes with the Typosquatting & Lookalike Domain Checker; the typosquatting guide covers the common techniques it checks for.
Stage 6: Authenticate DNS itself
Every stage above assumes the DNS response describing a record can be trusted. DNSSEC is what actually backs that assumption: RFC 4033 defines it as adding data origin authentication and data integrity to DNS, so a resolver can cryptographically verify a response really came from the zone's owner and wasn't altered or forged in transit, closing off cache-poisoning-style attacks the rest of this roadmap doesn't address. It works through a chain of trust: each zone's records are signed, and a chain of signatures leads up to a trust anchor the resolver already trusts.
It comes last on this roadmap for a practical reason: it requires both the domain's registrar and its DNS host to support it, and a misconfigured DNSSEC deployment can take a domain offline for every validating resolver rather than degrading gracefully. It's also worth being clear about its limits. The same RFC states plainly that DNSSEC does not provide confidentiality and does not protect against denial-of-service attacks, so it closes one specific, real gap rather than replacing everything else in this roadmap.
Stage 7: Make it a habit, not a project
DNS drifts. Staff change, vendors get added and dropped, marketing spins up a new sending platform without looping in whoever manages DNS. A configuration that was correct on the day it was set up can quietly go stale months later. DMARC's aggregate reports are built for exactly this: reading them periodically, not just during the initial rollout, is what catches a new unauthenticated sender before it becomes a gap. Re-running a full scan on a regular cadence, and after any change to mail or hosting providers, catches the rest.
See exactly what's published for a domain today, the starting point for every stage in this roadmap.
Frequently asked questions
What's the right order to do all this in?
Visibility first, since every later step depends on knowing what's already published. After that, email authentication (SPF, DKIM, DMARC) tends to have the biggest impact for the effort involved, which is why CISA's own federal directive sequenced it before web hardening. CAA, MTA-STS, and the web-facing checks can follow in any order that matches what the domain actually uses. DNSSEC and ongoing monitoring come last: DNSSEC because it depends on registrar and DNS host support, monitoring because it only makes sense once there's something worth watching for drift.
Why start DMARC at p=none instead of going straight to reject?
Because p=none is a monitoring policy: RFC 7489 specifies it should not change how receivers handle mail. It exists so the aggregate reports (rua) can show every legitimate source currently sending as the domain, including ones easy to forget, like a marketing platform or a helpdesk tool, before a stricter policy starts rejecting their mail. Jumping straight to reject risks silently dropping real mail from sources nobody remembered to authenticate.
Is DNSSEC required to call a domain secure?
It depends what "secure" is protecting against. DNSSEC authenticates that a DNS response actually came from the real zone and wasn't tampered with in transit, which the other steps in this roadmap don't cover on their own. But RFC 4033 is explicit that DNSSEC does not provide confidentiality and does not protect against denial-of-service attacks, so it closes one specific gap rather than being a complete security posture by itself.
How long does this whole roadmap take?
It varies by how many services send mail as the domain and how much change control the DNS host requires, but CISA's own federal directive is a useful reference point: it gave agencies 90 days for STARTTLS, SPF, and an initial DMARC monitoring policy, 120 days for HTTPS and HSTS, and a full year before requiring DMARC at p=reject across every domain. That pace, weeks for the first steps and months for full enforcement, is a reasonable target for most organizations too.