A Step-by-Step Guide to DNS Configuration

DNS connects your domain to the world, and it’s simpler than it looks.

You don’t need to be a network engineer to configure DNS confidently. What you need is a clear plan, the right order of operations, and a handful of best practices that prevent the classic mistakes. This step-by-step guide walks you from a blank domain to a production-ready setup, then through common scenarios such as migrations, email authentication, CDNs, SaaS platforms, and security hardening. Keep it handy as a working playbook.

What DNS Is and How It Works

The Domain Name System translates names like example.com into IP addresses that browsers and apps can reach. Two kinds of DNS servers matter to you:

Authoritative name servers store the truth for your domain. You or your provider edit records here.
Recursive resolvers (used by your visitors, ISPs, and public resolvers) ask authoritative servers for answers and cache them for a period called TTL.

When you update a record at the authoritative host, recursive resolvers learn the change the next time they refresh the cached answer. That refresh follows your TTL. Lower TTLs speed up change propagation. Higher TTLs reduce query load and improve resilience.

Core record types you will use most

A, AAAA map a name to an IPv4 or IPv6 address.
CNAME points one name to another name.
MX defines the mail servers that receive email for your domain.
TXT carries text data such as SPF, DKIM, and DMARC.
SRV advertises services like SIP or certain app auto-discovery.
CAA restricts which certificate authorities may issue TLS certificates for your domain.
NS, SOA define zone authority and housekeeping data.

One rule trips many beginners: the zone apex (example.com) cannot hold a CNAME by the DNS standard. If your provider offers ALIAS or ANAME, that is a server-side convenience that behaves like a CNAME at the apex by resolving to A or AAAA behind the scenes.

Before You Start: Smart Prep

Spend ten minutes on decisions that save you hours later.

Choose where your authoritative DNS will live
You can keep DNS at your registrar or move to a dedicated DNS provider or a CDN with DNS features. Pick one with a clean UI, API access if you automate, DNSSEC support, and health checks if you need them.
Collect your targets
Know the IPs for your web host, the hostnames for your CDN or SaaS platform, and the MX and TXT data for your email provider. Keep this in a simple change sheet.
Pick a canonical host name
Choose whether the canonical site resolves at the apex (example.com) or at www. Redirect the other to the canonical choice. Most teams pick the apex for simplicity.
Plan TTLs for changes
Set short TTLs, for example 300 seconds, a day before a migration or cutover. Raise TTLs to a steadier value, for example 3600 or 14400 seconds, after things stabilize.
Decide on DNSSEC
If your DNS host and registrar both support it, plan to enable DNSSEC after your records settle. You will publish a DS record at the registrar to point to your DNS host’s keys.
Set a rollback plan
Before you touch production records, know how you will undo a change. That can be as simple as keeping the old IP handy and leaving a note in your change sheet.

From Blank Domain to Live Site: The Clean Setup

Follow this order for a first-time configuration. It works for most hosts and CMSs.

Step 1: Create the zone and default records

In your authoritative DNS portal, create the zone example.com. Add:

NS records if your provider requires you to list them explicitly.
SOA is usually created for you.
A or AAAA records if your origin has assigned IPs already.
A CNAME for www that points to the apex, or the other way around, depending on your canonical decision.

Start with a modest TTL such as 600 seconds while you test.

Step 2: Delegate the domain at your registrar

At the registrar, set your domain’s nameservers to the ones provided by your DNS host. This is the moment you delegate authority. Changes to records now happen only at the DNS host.

Step 3: Confirm resolution and baseline reachability

Use dig or your provider’s query tool to confirm that A or AAAA records answer from your authoritative servers. Test both apex and www. You can query a specific nameserver with dig @ns.example-dns.com example.com A.

Step 4: Enforce your canonical redirect

In your web server or platform settings, redirect the non-canonical name to the canonical name with a 301. This avoids duplicate content and gives users one stable address. Check that both HTTP and HTTPS follow the same rule.

Step 5: Enable TLS and request a certificate

Most platforms issue certificates automatically once DNS points at them. If you manage your own TLS, request certificates for the exact set of hostnames you serve. Consider a CAA record to restrict issuance to your chosen CA.

Step 6: Configure email properly

Add MX records from your mail provider. Then add three TXT record families for deliverability:

SPF at the apex, format v=spf1 include:mailvendor1.net include:mailvendor2.com ~all or -all once you are confident. SPF has a 10-lookup limit, so keep includes tight.
DKIM selectors that your sending platform gives you, usually selector._domainkey. Publish each as a TXT.
DMARC at _dmarc.example.com. Start with v=DMARC1; p=none; rua=mailto:[email protected]; fo=1 to gather reports. Step toward quarantine and then reject when your legitimate senders pass consistently.

Step 7: Raise TTLs and document the final state

When everything works, raise TTLs to reduce needless churn and create a short change log so future you can see what changed and why.

Zero-Downtime Host Migration

When you move your site from one host to another, use DNS to cut over cleanly.

Lower TTLs 24–72 hours ahead
Reducing TTL ahead of time ensures most resolvers refresh quickly when you flip the record.
Build and test at the new host
Stand up the site on its final hostname or a temporary one. If possible, whitelist your office IP and test the site against the new origin directly.
Copy content and data
For dynamic sites, run a final sync near cutover. Freeze content briefly if needed to avoid missed edits.
Add new DNS records in parallel
If the new host requires additional records, such as a new A or a CNAME target for a managed platform, create them in your authoritative DNS but keep traffic flowing to the old origin for now.
Flip the traffic record
Change the apex A or the www CNAME to point at the new origin. Because TTLs are low, most visitors switch within minutes.
Monitor and roll back if necessary
Watch error logs, analytics, and uptime checks. If you uncover a critical problem, point the record back to the old origin while you fix it.
Raise TTLs and close the change
When stable, return TTLs to a higher value and capture the migration notes in your change log.

Adding a CDN or Reverse Proxy

CDNs and reverse proxies sit between visitors and your origin. DNS routes traffic to them, and the CDN routes traffic to your server.

Create a CNAME for the hostname you want behind the CDN, for example www to yourapp.cdnprovider.net.
At the apex, use ALIAS or ANAME if your DNS host supports it. Some CDNs offer CNAME flattening so the apex still resolves to A or AAAA.
Restrict direct origin access. Use allowlists or secret headers so only the CDN can reach your server.
Keep TLS certificates aligned. Many CDNs handle TLS at the edge and fetch over TLS from your origin.
Re-check caching and cookies. Logged-in pages and carts often require bypass rules.

CDN onboarding guides usually include the exact CNAME target and any required validation TXT records. Follow those precisely.

DNS For SaaS Platforms

SaaS providers such as storefronts, landing page builders, and email services commonly ask you to point your domain or a subdomain to them.

Rooted sites. The provider gives you a fixed A address or a CNAME target with ALIAS support at the apex.
Subdomain sites. You create a CNAME like shop.example.com to shops.example-saas.com.
Validation. They often require a TXT record to prove domain control.
Email sending. You will add SPF includes, DKIM selectors, and sometimes additional CNAMEs for tracking. Keep an eye on SPF lookup count.

When you later remove a provider, delete the validation and tracking records you no longer need.

Email Deliverability Hardening

Email succeeds when receiving servers can authenticate your messages and see consistent policy.

SPF strategy. List only the platforms that send mail on your behalf. Prefer a single include for a provider that aggregates multiple networks over individual IP ranges. Keep a copy of your current SPF in your notes before changing it.
DKIM hygiene. Use separate selectors per platform. Rotate keys yearly. Remove selectors for platforms you deprecate.
DMARC step-up. Start at p=none to collect aggregate reports. When pass rates hold, step to quarantine, watch impact, then go to reject. Add pct=100 when you are confident.
BIMI optional. Brand Indicators for Message Identification can add a logo in supporting inboxes if you meet DMARC at enforcement. It requires a DNS record and a properly prepared logo. Not required, but nice to have.

If someone reports that their outbound mail lands in spam, check that they are sending through an authenticated platform aligned with your DNS. Random desktop SMTP is a quick path to failure.

Advanced Topics Worth Knowing

DNSSEC in practice

DNSSEC signs your zone so resolvers can verify answers have not been altered in transit. Enable DNSSEC at your DNS host, then publish the DS record at your registrar. Test with a validator before you flip it on for production traffic. Maintain key rollovers on the host’s schedule. If you ever change DNS providers, disable DNSSEC, move the zone, then enable it again to avoid validation failures.

CAA for certificate issuance

A CAA record limits which certificate authorities may issue certificates for your domain. For example: 0 issue "letsencrypt.org" and 0 iodef "mailto:[email protected]". This helps prevent mis-issuance.

Split-horizon DNS

Larger teams sometimes serve different answers internally and externally. Use this with care. Keep internal zones maintained or you will chase phantom bugs that only appear on your VPN.

Glue records and vanity nameservers

If you run your own nameservers under your domain, you will publish glue records at the registry that map those NS hostnames to IP addresses. This is niche and easy to get wrong. Most teams should use a managed DNS provider instead.

Reverse DNS for mail servers

If you host your own outbound mail server, set PTR records through your IP provider and align them with your server’s HELO name and SPF. Many beginners skip this, then wonder why no one receives their mail.

Testing and Troubleshooting

You can solve most DNS problems with a small toolkit and a consistent process.

dig. Query specific nameservers, show TTLs, and spot whether answers come from cache. Try dig +trace example.com to walk the chain of authority.
nslookup or host. Quick checks from almost any system.
whois. Confirm the registrar, nameservers, and contact email.
Authoritative versus recursive answers. If authoritative servers show the right record and recursive resolvers do not, you are waiting for TTLs to expire.
NXDOMAIN and typos. A missing dot or a wrong label is a common cause of failures.
SPF limit. Use a checker to count DNS lookups in your SPF. Over the limit, receivers may treat SPF as a fail.
Apex CNAME mistake. If your DNS host does not support ALIAS and you set a CNAME at the apex, other records at the apex can behave strangely. Fix by moving to a provider with ALIAS support or by using A or AAAA records.

When in doubt, lower TTLs, make one change at a time, and verify from multiple networks.

Security and Reliability Best Practices

Enable registrar lock and 2FA on both the registrar and DNS host.
Limit access. Give write access only to people who change DNS. Use API tokens with least privilege.
Use secondary DNS if your availability requirements are strict. Two independent providers serving the same zone reduces risk from a single provider outage.
Monitor for changes. Some teams run a simple daily diff of the zone file. That catches surprises.
Auto-renew your domain and keep a working contact email at the registrar. Expired domains cause painful outages.
Document decisions. A two-page DNS runbook beats tribal knowledge and panic.

Common Mistakes and How to Avoid Them

Leaving TTLs sky high during a migration. Lower them ahead of time so you can steer traffic quickly.
Publishing both -all and ~all in SPF. Use one. Duplicates confuse receivers.
Mixing CNAME with other records at the same name. DNS does not allow this.
Forgetting IPv6. If your audience includes mobile networks that prefer IPv6, publish AAAA alongside A.
Pushing a database-heavy site behind a CDN without dynamic rules. Cart pages and dashboards need bypass rules.
Turning on HSTS before you validate redirects. Test redirects first so you do not trap browsers in a broken HTTPS loop.
Not removing legacy TXT records. Old DKIM selectors and vendor TXT leftovers can create confusion later.

Checklists You Can Copy

New domain, simple site

Choose authoritative DNS provider
Create zone and base records
Point registrar nameservers to DNS provider
Add A or AAAA for origin, CNAME for www
Enable TLS and enforce canonical redirect
Add MX, SPF, DKIM, DMARC
Verify, then raise TTLs and document

Migration to a new host

Lower TTLs 24–72 hours in advance
Build site at new origin and test
Sync content and freeze edits if needed
Flip A or CNAME to new target
Monitor, roll back if required
Raise TTLs and close the change

Add a CDN or reverse proxy

CNAME hostname to CDN target
ALIAS or flatten apex if needed
Restrict origin access
Validate TLS at edge and origin
Add cache bypass rules for dynamic pages

Email hardening

Add correct MX records
Publish SPF within lookup limits
Publish DKIM selectors per sender
Start DMARC at p=none, then step up
Remove old selectors and unused includes

Final Takeaway

DNS configuration is less about memorizing every record type and more about sequencing changes, testing the right things, and documenting what you did. If you choose a capable DNS host, keep TTLs under control during changes, harden email with SPF, DKIM, and DMARC, and protect your zone with DNSSEC and CAA, you will avoid the outages and deliverability headaches that hit so many teams. Start simple, make one change at a time, and keep a short runbook. That is how you stay fast and safe.

Frequently Asked Questions

How long does DNS propagation really take?

Most changes take effect in minutes when TTLs are low. Some resolvers ignore TTLs briefly or cache negative answers longer, so allow up to a couple of hours for global consistency. The old “48 hours” line is a very conservative worst case.

Should I keep DNS at my registrar or move it?

If your registrar’s DNS is reliable and supports DNSSEC, ALIAS, and sane tooling, keeping it there is fine. If you want advanced features or secondary DNS, move to a dedicated DNS host.

Do I need both IPv4 and IPv6 records?

Yes, if your origin supports IPv6. Many networks prefer IPv6. Publishing AAAA alongside A improves reachability without downsides.

What DMARC policy should I start with?

Start with p=none to collect reports and fix alignment issues. When you see consistent pass rates, move to quarantine and then to reject. Step gradually to avoid breaking legitimate mail.

Can I use a CNAME at the root of my domain?

Not by the pure standard. Use ALIAS or ANAME if your provider offers it. Those features let you point the apex at a hostname while answering with A or AAAA under the hood.

How do I avoid SPF’s 10-lookup limit?

Flatten includes where possible, remove unused senders, and prefer providers that bundle networks behind a single include. If you keep hitting the ceiling, revisit which systems really need to send as your domain.

Is DNSSEC worth the effort?

For public-facing domains, yes. DNSSEC provides integrity for DNS answers. Enable it after your zone stabilizes, publish the DS record at your registrar, and monitor with a validator.

References

Mockapetris, P. “Domain Names – Concepts and Facilities.” IETF RFC 1034.
Mockapetris, P. “Domain Names – Implementation and Specification.” IETF RFC 1035.
Elz, R. and Bush, R. “Common DNS Operational and Configuration Errors.” IETF RFC 1912.
Vixie, P. “Negative Caching of DNS Queries.” IETF RFC 2308.
Kucherawy, M. and Zwicky, E. “Sender Policy Framework (SPF).” IETF RFC 7208.
Crocker, D., Hansen, T., and Hallam-Baker, P. “DomainKeys Identified Mail (DKIM).” IETF RFC 6376.
Kucherawy, M. and Zwicky, E. “DMARC.” IETF RFC 7489.
Hallam-Baker, P. and Stradling, R. “DNS Certification Authority Authorization (CAA).” IETF RFC 6844, updated by RFC 8659.
Arends, R., et al. “DNS Security Introduction and Requirements.” IETF RFCs 4033–4035.
IETF RFC 8499 “DNS Terminology.”