How to Set Up DNS Records for a New Website: A, CNAME, MX, TXT, and More

Overview

When people talk about domain DNS setup, they usually mean one practical question: what records do I need to add so the right service answers for the right part of my domain? For a new website, that may mean pointing the root domain to a server IP, sending the www hostname to a canonical target, routing mail to a provider, and adding TXT records for verification, SPF, DKIM, or DMARC.

The easiest way to think about DNS is as a directory with rules. Each record type has a job:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: aliases one hostname to another hostname.
• MX record: tells other mail servers where to deliver email for your domain.
• TXT record: stores text values used for domain verification, email authentication, and other service settings.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.
• CAA record: limits which certificate authorities may issue an SSL certificate for website hostnames on your domain.

Before you change anything, identify three things clearly:

1. Who hosts your DNS: your registrar, your web host, a CDN, or a dedicated DNS provider.
2. What service is authoritative: if nameservers point to one provider, records added elsewhere will not take effect.
3. What exact values your provider supplied: target hostname, IP address, MX priority, TXT string, and any required TTL.

If you skip that first step, it is easy to make correct-looking changes in the wrong control panel. That is one of the most common reasons DNS for a new website appears broken.

As a working habit, lower the TTL before major planned changes when possible, document the old values, and change one service layer at a time. If you are moving both site hosting and email, avoid changing everything in one session unless you have a written rollback plan. For more on pointing a domain to a host, see How to Connect a Domain to Web Hosting: DNS Records Explained.

Checklist by scenario

This section is the practical core: use the scenario that matches what you are doing, then confirm each record before you save.

1) Launching a website on the root domain

Use this when you want example.com to load your site.

• Get the destination from your host: usually an IP address or a provider-specific target.
• Add an A record for @ pointing to the IPv4 address.
• Add an AAAA record only if your provider explicitly supports IPv6 for that site.
• If your provider uses an alias-style setup for the apex, follow its instructions carefully. Some DNS providers support special flattened or synthetic behavior at the root, while standard CNAME rules do not apply there.
• Keep TTL moderate unless you are in an active cutover window.
• Confirm the web server is configured to answer for your domain after DNS resolves.

Important: DNS can point correctly while the web server still serves a default page, wrong tenant, or certificate warning. DNS setup and web server setup are related but separate.

2) Making www work

Most sites want both the apex domain and www.example.com available, with one version redirecting to the preferred canonical hostname.

• Add a CNAME for www pointing to the hostname your provider recommends, often the root domain or a platform hostname.
• Decide your canonical version: apex or www.
• Configure redirects at the application, CDN, or load balancer level.
• Make sure the SSL certificate covers both names.

A common pattern is: example.com uses an A record, and www uses a CNAME to example.com. That keeps www aligned if the destination changes later.

3) Setting up business email on your domain

Use this if you want addresses like name@example.com.

• Add the exact MX records supplied by your email provider.
• Check the priority values carefully. Lower numbers usually mean higher priority.
• Remove old MX records unless your provider specifically says to keep them.
• Add the provider’s verification TXT record if required.
• Add an SPF TXT record as instructed. Avoid publishing multiple SPF records for the same hostname.
• Add DKIM TXT or CNAME records exactly as provided.
• Add a DMARC TXT record at _dmarc for reporting and policy control.

If you are comparing providers for business mail, see Business Email Setup With Your Domain: Google Workspace, Microsoft 365, and Zoho Compared.

4) Verifying your domain with a third-party service

Many SaaS tools ask you to prove domain ownership before they enable features.

• Add the required TXT record at the specified hostname, often @ or a provider-specific label.
• If the provider requests a CNAME verification record, use that instead of improvising a TXT value.
• Copy the string exactly, including punctuation.
• Wait for propagation, then click verify from the service dashboard.

Leave documentation about why the record exists. Months later, verification records often look like clutter and get deleted by accident.

5) Connecting a subdomain to a separate app or environment

Use this for app.example.com, docs.example.com, staging.example.com, or region-specific endpoints.

• Create the subdomain as a hostname in DNS.
• Point it with an A, AAAA, or CNAME depending on provider instructions.
• Do not point a subdomain to a URL path. DNS only works with hostnames and addresses, not paths like /blog.
• Confirm SSL coverage and redirect rules for the subdomain separately from the main site.
• If the subdomain is delegated to another team or platform, that may require NS records instead of an A or CNAME.

6) Preparing email authentication correctly

This is where many otherwise functional deployments run into delivery issues.

• SPF: publish one SPF TXT record for the hostname, typically the root domain. Merge mechanisms if multiple senders are authorized.
• DKIM: add the exact selector-based records the mail platform provides.
• DMARC: start with monitoring if you need visibility before stricter enforcement, then tighten over time based on actual sending patterns.

Email may send before all of these are perfect, but long-term deliverability is stronger when all three are aligned.

7) Securing certificate issuance

If you want tighter control over who can issue certificates, add a CAA record.

• Publish the certificate authority values approved by your environment.
• Review CAA whenever you change certificate tooling, CDN, or managed hosting.
• Do not add restrictive CAA values without checking your current certificate issuance path.

If you need the broader picture, see SSL Certificate Guide: Types, Costs, Renewal, and Installation Basics.

8) Moving a site or changing hosts

Migration is where DNS changes carry the most risk because content, certificates, and caching may all be changing too.

• Lower TTL in advance if your provider allows it and the migration is scheduled.
• Export or copy existing DNS records before editing anything.
• Confirm the new hosting environment is tested on a temporary URL, hosts file override, or platform preview method.
• Change only the records required for the website first.
• Leave email records untouched unless mail is also moving.
• Monitor site response, certificate behavior, and error logs after cutover.

For a broader process, use Website Migration Checklist: Move Your Site to a New Host Safely.

What to double-check

If you only have two minutes before saving changes, review these items. They catch most DNS setup errors quickly.

• You are editing the authoritative DNS zone, not a stale zone at a former provider or registrar.
• The hostname is correct: @, blank, full hostname, or relative label depending on your DNS editor.
• The record type matches the instruction: do not use an A record when a provider requires CNAME, and do not convert TXT values into other formats.
• The target value is exact: no missing trailing characters, extra quotes, or merged strings.
• There are no conflicting records on the same hostname, especially CNAME versus other records.
• Old MX records are removed if your mail provider expects exclusive routing.
• SPF exists only once for the relevant hostname.
• TTL is reasonable for the change window and not so low that it creates unnecessary query load over time.
• Certificates cover the hostnames you are exposing, including www and subdomains where needed.
• Application-level redirects are configured so users land on the preferred hostname.

After updating, test from outside your own browser session. Check the record values directly with your DNS provider tools or a command-line utility, then test the site or mail flow separately. DNS resolution does not guarantee service health.

If you are waiting on changes, this is where a DNS propagation checker becomes useful, especially during cutovers.

Common mistakes

Most DNS issues are not advanced technical failures. They are small mismatches between intent and record behavior.

Adding records at the wrong provider

The domain may be registered in one place, hosted in another, and using nameservers from a third service. If the nameservers point elsewhere, edits in the registrar panel may do nothing.

Using CNAME at the root domain where it is not supported

Standard DNS rules do not allow a CNAME at the zone apex when other required records exist there. Some providers offer special alias behavior, but that is platform-specific. Follow the host’s exact apex instructions.

Keeping old and new MX records together

During email changes, leftover MX records can split or misroute delivery. Unless the provider explicitly documents coexistence, old MX entries should usually be removed.

Publishing multiple SPF records

This is a classic email issue. SPF should be a single consolidated TXT record for the hostname. Multiple SPF records can cause evaluation problems.

Confusing hostname labels

Some DNS editors expect www; others want the full www.example.com. Some use @ for the root, some use a blank value. The same intended record can be entered incorrectly if you assume the interface behavior.

Expecting instant results

Even when records are saved correctly, cached answers may persist for some time. Build propagation time into launch plans and avoid making repeated edits just because one network still shows old data.

Forgetting the service layer above DNS

You can resolve the domain to the right IP and still see the wrong site because the virtual host, reverse proxy, container ingress, or CDN mapping is not configured. Treat DNS as one layer in the chain, not the whole deployment.

Not documenting why a record exists

TXT records for verification, DKIM selectors, and delegated subdomains can look cryptic later. Add internal notes or maintain a zone inventory so future cleanup does not break a hidden dependency.

When to revisit

DNS is not a one-time setup. Revisit your records whenever the inputs change or before periods when reliability matters most.

• Before a website launch or relaunch: confirm apex, www, SSL coverage, redirects, and CDN or proxy settings.
• Before migrating hosting: review A, AAAA, CNAME, and any provider-specific verification records.
• When changing email providers: replace MX, SPF, DKIM, and DMARC carefully and verify outbound sending sources.
• When adding a new SaaS tool: document verification TXT and subdomain routing requirements.
• When certificate automation changes: audit CAA and hostname coverage.
• During seasonal planning cycles: check whether legacy records still serve a real purpose before traffic-sensitive periods.
• After team or workflow changes: make sure DNS ownership, access, and documentation are still current.

A practical review routine looks like this:

1. Export or copy the current zone.
2. Mark each record as website, email, verification, security, or legacy.
3. Remove only what you can positively identify as unused.
4. Test web, mail, and third-party verifications after cleanup.
5. Record the reason for each non-obvious entry.

If your next step is choosing where the site itself should run, these related guides may help: Best Web Hosting for Small Business Websites, Shared Hosting vs VPS vs Cloud Hosting, and WordPress Cloud Hosting Comparison: Managed vs Self-Managed Options.

Final checklist before you close the DNS tab:

• Root domain resolves correctly.
• www resolves and redirects as intended.
• Mail records match the active provider only.
• SPF, DKIM, and DMARC are present where needed.
• Verification TXT records are documented.
• SSL is valid for every public hostname.
• No duplicate or conflicting records remain.
• Propagation has been checked from outside your local network.

That small routine is what turns DNS from a launch-day risk into a repeatable process. Keep it nearby, and update it whenever your hosting, email, or deployment workflow changes.