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

Overview

If you want a durable website DNS setup guide, start with one principle: every DNS record should have a single job. Your apex domain should know where the site lives. Your www host should either point to the same site or redirect to the preferred hostname. Your mail records should point only to your email provider. Verification and security records should be explicit and documented.

DNS records are small entries in your domain’s zone file. They tell browsers, mail servers, CDNs, and external services where to go and what to trust. The records you will use most often are:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: makes one hostname an alias of another hostname.
• MX record: tells email senders which mail servers accept mail for your domain.
• TXT record: stores text-based instructions or verification data, commonly for SPF, DKIM, DMARC, SSL checks, and domain ownership verification.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.
• CAA record: optionally limits which certificate authorities can issue SSL certificates for your domain.

For most website owners using cloud hosting, managed cloud hosting, or a cloud site builder, DNS work usually falls into four tasks:

1. Connect the domain to web hosting.
2. Make www and the root domain behave consistently.
3. Connect or preserve email service.
4. Add verification and security records without overwriting working records.

Before you change anything, collect these details in one place:

• Your DNS provider or registrar where the zone is managed.
• Your hosting target: IP address, CNAME target, or nameserver instructions.
• Your preferred canonical hostname: example.com or www.example.com.
• Your email provider’s MX and TXT requirements.
• Any existing third-party services that already use DNS, such as CDN, monitoring, support platforms, or verification tools.
• The current records, exported or copied as a rollback reference.

If you are also planning a hosting migration, treat DNS as one step in a larger cutover process. A separate move plan is worth having before you switch live traffic, especially for production applications and stores. The migration workflow in How to Move a Website to Cloud Hosting Without Downtime pairs well with the DNS checklist below.

Checklist by scenario

Use this section as your practical checklist. Pick the scenario closest to your setup, then adjust only what your provider actually requires.

1. Connecting a domain to a website on a single server or cloud host

This is the simplest form of dns records for hosting. Your website provider usually gives you one IP address, sometimes two, and may also recommend a www CNAME.

• Create or update an A record for the apex domain, often shown as @, pointing to your server’s IPv4 address.
• If your host provides IPv6, add an AAAA record for the apex domain.
• Create a CNAME record for www pointing to the canonical hostname your provider recommends, or to the apex if your DNS provider allows the pattern cleanly.
• Configure a 301 redirect at the hosting layer so only one hostname is canonical.
• Wait for propagation, then test both example.com and www.example.com.

Good default: choose one preferred public hostname and redirect the other. This avoids split signals for SEO, SSL confusion, and inconsistent cookies.

2. Connecting a domain to a website builder or managed cloud hosting platform

Many website builder and managed cloud hosting platforms ask you to create one or more CNAME records, sometimes plus an A record for the root domain. Follow the exact hostnames they provide, but keep these rules in mind:

• If the provider asks for a CNAME for www, do not also create an A record for www. A hostname should not have both.
• If the provider gives an A record for the root domain, use that only at the apex.
• If the provider requires domain verification, add the requested TXT record exactly as shown.
• After DNS resolves, complete domain connection or SSL issuance inside the hosting dashboard.

This is a common path for a website builder with custom domain support. The DNS work is straightforward, but the most common error is leaving old records in place from a previous host.

3. Pointing a domain through a CDN or proxy

If you use hosting with CDN or place a reverse proxy in front of your site, DNS may point to the CDN instead of your origin server.

• Set the A, AAAA, or CNAME records to the CDN target as instructed.
• Confirm that the CDN knows your origin server details and that SSL is configured correctly on both the edge and the origin.
• Make sure the CDN or proxy status is intentional. Some providers let you toggle between DNS-only and proxied traffic.
• If your site serves static assets from a separate hostname, document that mapping clearly.

DNS and caching often get mixed together. DNS decides where requests go; cache settings decide how responses are stored and served. If you are tuning speed after the domain is connected, see CDN Cache Settings Explained: TTL, Purge, and Cache-Control for Faster Sites.

4. Setting up email without breaking the website

Mail setup is where many otherwise correct DNS changes go wrong. Website DNS and email DNS often live in the same zone, but they serve different systems.

• Add the MX records exactly as your mail provider specifies, including priorities.
• Add any required TXT records for SPF, DKIM, and DMARC.
• Do not delete existing MX or TXT records until you are certain you are replacing that mail system.
• Keep website records and mail records separate in your notes so a web hosting change does not accidentally remove email settings.

MX record basics: MX records should point to mail server hostnames, not raw IP addresses. Priorities matter; lower numbers are typically preferred first.

TXT record basics:

• SPF helps define which systems may send mail for your domain.
• DKIM publishes a public key used to verify signed mail.
• DMARC tells receivers how to handle messages that fail alignment and where to send reports.

For many businesses, reliable mail is as important as website uptime. Treat MX and TXT changes with the same caution you would use for production hosting.

5. Verifying a domain for SSL, apps, and external services

Many services ask you to prove domain ownership before they enable features. This might be a cloud hosting platform, search tool, analytics product, support platform, or certificate workflow.

• Add the required TXT record exactly as shown.
• If the service uses a specific host, such as _acme-challenge or a vendor token hostname, keep that name exact.
• Leave the verification record in place if the provider recommends it for ongoing trust or renewal.
• Document what each TXT record is for; TXT sprawl is common over time.

For security-conscious environments, consider a CAA record to limit which certificate authorities may issue certificates for your domain. This is optional, but it can reduce accidental or unwanted issuance if managed carefully.

6. Delegating a subdomain to another platform

Sometimes you want your main site on one platform and a subdomain like app.example.com or docs.example.com on another.

• For a simple connection, use an A, AAAA, or CNAME on the subdomain.
• For full delegated control, create NS records for that subdomain pointing to the other provider’s nameservers.
• Do not delegate the entire root domain unless you intend to move all DNS management.

This pattern is common for developer tools, separate applications, status pages, and documentation sites.

What to double-check

Before you save records, and again after changes propagate, run through this short review. It prevents most avoidable outages.

Record-level checks

• Hostname correctness: Are you editing @, www, or a subdomain? Small naming mistakes are common.
• No conflicting records: A hostname should not usually have both a CNAME and other record types at the same label.
• Target correctness: IP addresses must match your host exactly. CNAME and MX targets should be hostnames, spelled exactly.
• Priority values: For MX records, confirm the intended order.
• TTL choice: Use a shorter TTL before planned changes if you want faster rollback behavior later, then raise it after the move if desired.

System-level checks

• Nameserver location: Confirm which provider is authoritative. Editing the wrong DNS panel is more common than it should be.
• Canonical hostname: Decide whether the primary site lives on the root or www, and configure redirects accordingly.
• SSL readiness: Make sure the host or CDN can issue and renew certificates after DNS points correctly.
• Email continuity: Reconfirm that MX, SPF, DKIM, and DMARC remain intact after web changes.
• Monitoring: After a DNS cutover, watch site availability and mail flow instead of assuming success. A basic runbook helps, especially for business-critical sites. For a practical companion checklist, see Website Uptime Monitoring Checklist for Cloud-Hosted Sites.

Change-management checks

• Export or screenshot the previous zone before editing.
• Change one thing at a time when possible.
• Label records in your internal documentation with the service that depends on them.
• Keep a rollback note with the old values and the reason for the change.

If you are building from scratch rather than updating a live site, it helps to review the broader setup sequence in Domain, DNS, and Hosting Setup Checklist for New Websites.

Common mistakes

Most DNS failures are not caused by obscure protocol behavior. They come from a small set of repeatable mistakes.

Mixing old and new hosting records

When connecting a domain to website hosting, people often add the new A record but leave an old A, AAAA, or CNAME in place for the same hostname. The result can be inconsistent resolution or traffic going to the wrong place. Clean up old records once you have confirmed the intended configuration.

Using CNAME where it does not belong

A CNAME is useful, but it should not coexist with other record types at the same hostname. This becomes a problem when someone creates a CNAME on a host that already has TXT or MX records, or when they try to force an apex CNAME in a DNS environment that does not support the necessary flattening behavior.

Breaking email during a web migration

A hosting move should not require deleting MX records unless you are also changing email providers. Many teams lose mail because they replace the whole zone from a website platform template without preserving email entries.

Forgetting the root versus www decision

If both hostnames load but neither redirects, users and crawlers may see duplicate content or inconsistent certificates. Pick one canonical hostname and make the redirect explicit.

Editing DNS in the wrong panel

Your registrar is not always your DNS host. If nameservers point elsewhere, registrar DNS edits do nothing. Always check the authoritative nameservers first.

Assuming propagation means only waiting

Propagation delays are real, but many apparent propagation issues are actually configuration errors, local caching, or SSL not being completed at the destination. Waiting is not a substitute for verification.

Leaving TXT records undocumented

TXT records accumulate quickly: mail authentication, search verification, SSL validation, external SaaS checks, and internal tooling. Without notes, it becomes hard to know what can be removed safely.

When to revisit

DNS is not a one-time setup. Revisit it whenever the systems behind your domain change, and schedule a lightweight review before busy periods or planned infrastructure work.

Revisit your DNS setup when:

• You move to new cloud hosting, managed cloud hosting, or a new website builder.
• You add a CDN, proxy, staging environment, or application subdomain.
• You change email providers or tighten mail authentication.
• You issue new SSL workflows or add certificate restrictions such as CAA.
• You consolidate vendors to reduce fragmented tooling.
• You prepare for seasonal traffic, product launches, or migration windows.

Practical recurring checklist:

1. List every active hostname: root, www, app, blog, docs, mail-related selectors, and verification hosts.
2. Match each record to an owner and service: hosting, CDN, email, SSL, analytics, support, or developer tool.
3. Remove records that are clearly obsolete only after confirming nothing depends on them.
4. Verify that your site still resolves to the intended platform and that your redirect logic is still correct.
5. Test email receipt and outbound authentication after any related change.
6. Review TTL values before planned changes so future updates are easier to control.
7. Store the current zone in your infrastructure notes or password manager attachments.

A final practical rule: treat DNS changes like production changes. Even a small edit can affect availability, deliverability, and trust. If your environment is growing, pair DNS documentation with your broader hosting, backup, and recovery process. That becomes especially important for sites that depend on website hosting with backups, object storage, or multiple delivery layers. Related planning resources on storages.cloud include Managed Cloud Hosting vs VPS vs Shared Hosting: Which Is Best for Growth?, Cloud Hosting Cost Breakdown for Small Business Websites, and Website Restore Time Benchmarks: What a Good Backup System Should Deliver.

If you return to this guide before each domain change, you will usually catch the issues that matter most: conflicting records, missing mail settings, unclear canonical hosts, and undocumented verifications. That is what makes DNS manageable over time.