Domain DNS Setup Checklist: Records You Need for Websites, Email, and Verification

Overview

If you are looking up domain DNS setup steps in the middle of a launch, migration, or troubleshooting session, the real goal is usually not to understand every detail of DNS theory. It is to make the right records exist in the right place without breaking anything already working.

At a practical level, DNS turns a domain name into instructions. Those instructions may point a browser to a website, tell mail servers where to deliver email, prove domain ownership to a service, or define security policies. The records themselves are small, but the consequences of a typo, duplicate entry, or wrong host value can be large.

For most small businesses, creators, and developer-run sites, the records you will touch most often are:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: points one hostname to another hostname.
• MX record: defines which mail servers receive email for a domain.
• TXT record: stores text used for verification, email authentication, and policies.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.
• CAA record: limits which certificate authorities may issue SSL certificates for the domain.

A good DNS checklist starts with one rule: know which system is authoritative before you edit anything. Your domain registrar may not be where your live DNS is hosted. Many teams buy a domain in one place, point nameservers to another provider, and then later forget where active records are managed. Before changing records, confirm:

• which nameservers are authoritative,
• which DNS dashboard controls them,
• which records already exist for the root domain and common subdomains like www, mail, api, and blog,
• whether email is already active on the domain.

If you are also changing hosting, deployment, or your site builder at the same time, pair this guide with a migration plan so DNS changes do not happen blindly. See Website Hosting Migration Checklist: Move Your Site Without Downtime for a broader process around cutovers and timing.

Checklist by scenario

Use this section as a reusable reference. Each scenario focuses on the records you typically need and the checks worth doing before and after changes.

1. Pointing a domain to a website

This is the most common dns records for website task. Whether you use managed cloud hosting, a static host, or a website builder, the provider will usually ask for one of two patterns:

• an A record for the root domain, such as example.com, or
• a CNAME record for a subdomain, most often www.example.com.

Checklist:

• Identify whether your provider expects an IP address or a target hostname.
• Create or update the A record for the apex or root domain if an IP address is required.
• Create or update the CNAME for www if the provider uses a hostname target.
• Decide which version should be primary: root domain or www.
• Confirm that redirects are configured at the application or hosting level so visitors do not see duplicate versions.
• Do not create a CNAME at the root domain unless your DNS provider explicitly supports an alias-style implementation.
• Check that no old A or AAAA records still point to a previous host.
• After saving, test both example.com and www.example.com.

For creators comparing a site builder to custom hosting, the DNS layer is often where setup complexity shows up first. If you are still choosing the platform side of the stack, see Best Website Builders for Creators and Freelancers and Portfolio Website Hosting Guide.

2. Connecting email for the domain

Email setup is where DNS gets more sensitive. A website can often tolerate a short delay or a misrouted subdomain during testing. Email cannot. The main records here are MX and several TXT records.

Checklist:

• Add the exact MX records provided by your email service, including priority values if they specify them.
• Remove old MX records if you are replacing a prior email provider and no longer need mail routed there.
• Add the provider's TXT verification record if required.
• Add an SPF TXT record if your provider instructs you to do so.
• Add DKIM records, often TXT or CNAME depending on the service.
• Add a DMARC TXT record to define reporting and handling policy for unauthenticated mail.
• Make sure only one intended SPF policy exists for a given hostname; multiple SPF TXT records can create validation problems.
• Send test messages to and from external inboxes after propagation.

When moving web hosting, verify whether email is staying with the current provider or moving elsewhere. Small businesses sometimes break mail by changing nameservers for a website launch without recreating MX, SPF, DKIM, and DMARC records in the new DNS zone.

3. Verifying a domain for third-party services

Many services need proof that you control a domain before they will send email, display ads, issue certificates, activate integrations, or connect branded links. This is often done with a TXT or sometimes CNAME record.

Checklist:

• Copy the host/name field exactly as provided; some dashboards want only the label, while others want the full hostname.
• Copy the value exactly, including punctuation and quotation behavior if required by your DNS provider.
• Check whether the record belongs at the root domain, a specific subdomain, or a provider-defined label such as _acme-challenge or _domainkey.
• Do not overwrite unrelated TXT records unless the provider explicitly tells you to replace an old one.
• Wait for propagation, then run the provider's verification process again.
• Keep a note of what service each verification record belongs to so you can clean up later.

This is one reason the article is worth revisiting: verification patterns change often, and providers do not all explain host values in the same way.

4. Setting up subdomains for apps, landing pages, or services

Subdomains let you route different traffic without moving the whole domain. Common examples include app.example.com, shop.example.com, status.example.com, or go.example.com.

Checklist:

• Decide whether the subdomain should use an A, AAAA, or CNAME record based on the provider's instructions.
• Check for collisions with existing records at the same hostname.
• If using a CNAME, do not place other incompatible records at that exact same hostname.
• Confirm SSL coverage for the subdomain after DNS resolves correctly.
• Test the subdomain directly in a browser and with DNS lookup tools.

This pattern is common in fast deployments, especially when teams want to launch a landing page, docs site, or app separately from the main marketing site.

5. Enabling SSL certificate issuance safely

Most modern hosting platforms automate SSL certificate setup, but DNS can still affect whether issuance succeeds. In some cases, you may also want to control which certificate authorities are allowed to issue certs for your domain.

Checklist:

• Ensure the website DNS records are correct and publicly resolvable before requesting a certificate.
• If your provider uses DNS validation, add the required TXT or CNAME challenge records exactly as instructed.
• Consider adding CAA records if you want to restrict certificate issuance to approved certificate authorities.
• If you already use CAA, confirm the chosen certificate provider is allowed before troubleshooting failed issuance elsewhere.
• Verify that both root and www hostnames are covered if both are in use.

6. Delegating a subdomain to another DNS provider

This is more advanced, but useful for teams splitting control across systems. You might keep the primary domain in one DNS platform while giving a product team or external service control over a subdomain.

Checklist:

• Create NS records for the subdomain at the parent zone.
• Set up the corresponding zone at the delegated provider.
• Add the needed records in that delegated zone, not just in the parent zone.
• Test resolution specifically for names inside the delegated subdomain.

Use delegation carefully. It can simplify ownership boundaries, but it also adds another place to forget about later.

What to double-check

If you only have time for a short review before hitting save, check these items. They account for many avoidable DNS issues.

• Host field format: Some providers expect @ for the root domain, others expect the domain left blank, and others expect the full domain name. Misreading this is common.
• Trailing dots and automatic suffixes: DNS dashboards differ in whether they automatically append the zone name. A host entered as www.example.com may become www.example.com.example.com in the wrong interface.
• Exact record type: If instructions say MX, do not substitute A or CNAME. If they say TXT verification, do not place it as a note or comment field.
• Duplicate or conflicting records: Old A records, stale MX entries, or multiple SPF TXT records can create inconsistent behavior.
• TTL awareness: Time to live affects caching. Lower TTLs can help before planned changes, but they are not instant propagation switches.
• IPv6 presence: If you publish AAAA records, make sure the destination actually serves traffic correctly over IPv6.
• Proxy or CDN settings: If your DNS provider offers traffic proxying, know whether the record should be proxied or DNS-only. Some verification or mail-related records should not be proxied.
• Nameserver changes versus record changes: Moving nameservers is not the same as editing a record. A nameserver switch requires the full DNS zone to exist at the new provider first.

It also helps to export or screenshot the current zone before making significant edits. DNS dashboards are not always strong at change history, and a simple reference can make rollback much easier.

Common mistakes

Most DNS problems are not caused by obscure protocol details. They come from a few repeated mistakes.

Changing nameservers when only a record change was needed

If a hosting provider asks you to point your domain to a website, that does not always mean changing nameservers. Often you only need an A record or CNAME update. Changing nameservers without replicating the rest of the zone can break email, verification, and subdomains all at once.

Using a CNAME where it does not belong

A CNAME is convenient for subdomains, but it should be used with care. The root domain often requires a different approach unless your DNS provider supports alias-like behavior. Similarly, mail routing should use MX records, not a CNAME workaround.

Forgetting email records during website moves

This is one of the most expensive oversights for small teams. The website launches successfully, but inbound mail disappears because MX, SPF, DKIM, or DMARC records were left behind in the old DNS provider.

Leaving old records in place

Stale records create ambiguity. Old A records may continue to send part of traffic to retired infrastructure. Old TXT verification records clutter the zone and make future troubleshooting slower. Keep records documented and prune what you no longer use.

Assuming propagation is the same everywhere

Even when you save a correct record, cached results may differ temporarily across resolvers and regions. Plan changes with a little patience, especially for mail and certificates.

Skipping post-change tests

Saving a record is not the finish line. Test the domain in a browser, query the DNS answer directly, send email if mail was involved, and confirm SSL issuance if a website is going live.

If you are evaluating whether a simpler hosting stack would reduce this kind of operational friction, it is worth reading Managed Hosting vs Shared Hosting vs VPS and Best Cloud Hosting for Small Businesses. The right hosting model does not remove DNS, but it can reduce how often you need to debug edge cases under time pressure.

When to revisit

DNS setup should be revisited whenever the underlying service map changes, not just when something breaks. A simple quarterly review is enough for many sites, and a focused review before a launch or migration is usually worth the time.

Revisit your DNS checklist when:

• you change hosting providers or deploy a new website stack,
• you move from shared hosting to managed cloud hosting or another platform model,
• you add a new email provider or sending service,
• you launch a store, portfolio, landing page, or app on a new subdomain,
• you switch DNS providers or nameservers,
• you add SSL restrictions with CAA,
• you retire services that previously required verification records,
• you are preparing for a seasonal campaign, product launch, or domain renewal audit.

A practical maintenance routine looks like this:

1. List every active hostname you use: root, www, mail, app, docs, shop, API, status, and any campaign subdomains.
2. Map each hostname to the service that owns it.
3. Review A, AAAA, CNAME, MX, TXT, NS, and CAA records for necessity and accuracy.
4. Confirm email authentication is still aligned with your current providers.
5. Remove or archive stale records after confirming they are no longer needed.
6. Test website resolution, SSL status, and mail flow after changes.
7. Store a plain-language note about why each non-obvious record exists.

That final step matters more than it seems. The most useful DNS zone is not the one with the fewest records. It is the one a future you, or another teammate, can understand quickly during a launch or outage.

Used this way, a dns checklist becomes more than setup documentation. It becomes lightweight operational protection for your domain, your site, and your email.