DNS Records Explained: A Practical Setup Guide for Websites and Email

Overview

The Domain Name System, or DNS, translates names such as www.example.com into destinations that browsers, mail servers, and other services can use. Your domain registrar may provide DNS hosting, or your records may be managed through a separate DNS hosting provider, website host, cloud platform, or email vendor.

A DNS record normally has a name, a type, a value, and a time to live (TTL). The name identifies the domain or subdomain, the type describes the purpose, and the value tells DNS where to send the request or what information to publish. TTL controls how long resolvers may cache the answer; it is not a guarantee that every network will update at the same moment.

Use the following table as a starting reference. Exact field names vary between managed DNS dashboards, and some providers ask you to enter only the hostname rather than the full domain.

DNS is separate from domain registration and web hosting. A domain registrar holds the registration, DNS hosting publishes records, and web hosting serves the site. One company can provide all three, but changing one service does not automatically change the others.

Checklist by scenario

For a basic website

1. Confirm which DNS provider is authoritative by checking the domain's NS records or the registrar's DNS settings.
2. Obtain the website host's exact instructions. The destination may be an IPv4 address, an IPv6 address, a hostname, or a provider-specific combination.
3. Create an A record for the root domain, often shown as @, if the host supplies an IPv4 address.
4. Create an AAAA record only when the host supplies a working IPv6 address and the site is configured to serve traffic over IPv6.
5. Create a CNAME for www when the host instructs you to point that subdomain to a hostname.
6. Check whether the hosting platform requires a separate domain verification record before it will issue SSL certificates or accept traffic.
7. Test both the root domain and www over HTTPS after the change. A DNS response alone does not prove that the web server, certificate, or redirect is configured correctly.

An A record versus a CNAME is not simply a matter of preference. An A record points directly to an IP address, while a CNAME points to another hostname that can be managed by the destination provider. Follow the hosting platform's instructions, particularly for the root domain, where some DNS systems handle aliases differently.

For business email

1. Record the current MX records before making changes. Include each hostname and its priority.
2. Get the complete MX instructions from the email provider, including whether old MX records must be removed.
3. Add the provider's MX records with the requested priorities. Lower numeric values commonly indicate higher delivery preference, but use the provider's stated format.
4. Publish SPF as a TXT record if the provider supplies an SPF policy. Keep one consolidated SPF record for the domain rather than creating several separate SPF records.
5. Publish DKIM records exactly as supplied. These are often TXT records under a selector such as selector1._domainkey, although the provider may use a CNAME instead.
6. Publish a DMARC TXT record after reviewing the domain's sending services and rollout plan. Start with a policy appropriate to your monitoring and enforcement stage.
7. Send a test message to an external mailbox and inspect authentication results. Also test replies, forwarding workflows, contact forms, and shared mailboxes that matter to the business.

For a deeper email-specific workflow, see SPF, DKIM, and DMARC for Business Domains. Do not remove existing MX records merely because a new provider supplied replacement values; first confirm whether the migration is complete and whether any secondary mail service still depends on them.

For a subdomain or application

1. Define the exact hostname, such as portal.example.com, status.example.com, or staging.example.com.
2. Choose an A, AAAA, or CNAME record based on the application provider's instructions.
3. Confirm whether the subdomain needs a separate SSL certificate, application-level verification, access restriction, or redirect.
4. Document the owner, purpose, destination, and expiry or review date. This prevents an abandoned subdomain from remaining connected to an old service.
5. Test the subdomain from an external network and verify that it does not expose a staging system, admin panel, or outdated application unintentionally.

For verification and third-party services

Many analytics, advertising, support, recruitment, and cloud tools verify domain ownership with a TXT record. Copy the value precisely, including punctuation, capitalization where relevant, quotation marks if the dashboard requires them, and any underscores in the record name. Some services use a CNAME or a file-based verification method instead. Keep verification records that are still in use, and remove obsolete ones only after confirming that no active integration depends on them.

What to double-check before and after a DNS change

Use this change-planning worksheet before editing a production domain:

• Change owner: Who is making the change and who can approve a rollback?
• Authoritative provider: Which account actually publishes the domain's records?
• Record inventory: What are the current A, AAAA, CNAME, MX, TXT, NS, and CAA records?
• Business dependencies: Which website, email, payment, form, monitoring, VPN, or SaaS service uses the domain?
• Desired result: What should resolve differently, and what must remain unchanged?
• Rollback: What are the previous values, and how will they be restored?
• Validation: Which browsers, mailboxes, subdomains, and external DNS checks will be tested?

Before a planned migration, lower the TTL only if your DNS provider and change plan support that approach and you have enough time for the lower value to be observed by resolvers. Do not assume that lowering TTL immediately clears caches created under the previous value.

After saving a record, query it from more than one resolver or use a DNS propagation checker. Then test the actual service: load the website, complete a form, send and receive email, renew or inspect the SSL certificate, and check application logs where available. DNS tools can confirm what is published, but only an end-to-end test confirms that the service works.

For larger changes, pair DNS testing with an uptime and incident plan. The Website Uptime Planning guide provides a useful structure for monitoring, alerts, and response ownership.

Common mistakes

• Editing the wrong DNS zone: A domain may be registered with one company while its authoritative DNS is hosted elsewhere.
• Leaving conflicting records: Two A records may intentionally support distribution, but an old address left beside a new one can send visitors to inconsistent destinations.
• Using a CNAME at the wrong level: A CNAME generally cannot coexist with other records at the same name. Check the provider's rules before adding one to a hostname that already has MX, TXT, or other data.
• Replacing all TXT records: A domain can have multiple TXT records for unrelated services. Add or edit the relevant value instead of deleting the complete set.
• Publishing multiple SPF records: Combine authorized senders according to the email provider's instructions rather than creating separate SPF policies.
• Changing MX before the mailbox migration is ready: Website changes and email changes may be independent. Treat mail as a separate production dependency.
• Assuming propagation is the only problem: A correct DNS response cannot fix an incorrect web server binding, missing certificate, blocked port, or application configuration.
• Forgetting IPv6: An outdated AAAA record can direct some visitors to a server that no longer hosts the site. Review A and AAAA records together.
• Failing to document ownership: Record who controls the DNS account, where recovery credentials are stored, and which services depend on each record.

When to revisit your DNS records

DNS should be treated as an operating record for the business, not a one-time setup task. Review it before a hosting or email migration, when adding a subdomain, when onboarding a verification service, and before renewing or transferring a domain. Recheck it before seasonal planning cycles if the website, marketing stack, payment flow, or support systems change during those periods.

Schedule a periodic inventory even when nothing appears broken. Compare published records with the services the business still uses, remove clearly obsolete destinations through a controlled change, and confirm that more than one responsible person can access the DNS account. Review CAA, certificate, and email authentication settings when security requirements or providers change.

When a workflow or tool changes, update the checklist rather than relying on an old screenshot or copied record. Provider instructions can change, and a record that was correct for one hosting platform may be wrong for another. For a full infrastructure move, use the Website Hosting Migration Checklist and keep a tested rollback plan.

Practical next step: export or copy your current DNS records, label each one by business purpose, and mark any record whose owner or destination is unclear. Resolve those unknowns before the next website, email, or domain change. A small, current inventory makes DNS troubleshooting faster and reduces the chance that a routine update disrupts traffic or mail.