DNS Records Guide: Configure A, AAAA, CNAME, MX, TXT, and CAA Records Without Breaking a Domain

Overview

The Domain Name System (DNS) connects human-readable names such as example.com to services on the internet. A DNS record tells resolvers what to do when someone looks up a domain or subdomain. The correct record depends on the service you are connecting and the value supplied by that service.

Before editing DNS, identify two separate systems:

• Your DNS host: the provider whose nameservers are authoritative for the domain. This may be your registrar, hosting provider, CDN, or a dedicated DNS service.
• The destination service: the website host, mail provider, verification platform, or other system asking you to add a record.

Changing records at a registrar does not necessarily change the live DNS if another provider hosts the zone. Confirm which nameservers are active before making an edit.

DNS records explained

Record names and form fields vary slightly between DNS providers. A provider may show separate fields for name, type, value, priority, and TTL, or combine some of them in a compact editor. Follow the destination service's exact hostname and value instructions rather than translating them from memory.

A record versus CNAME

Use an A record when the destination gives you an IPv4 address. Use an AAAA record when it gives you an IPv6 address. Use a CNAME record when the destination gives you a hostname, such as app.hosting.example.

An A or AAAA record contains an address that can change when infrastructure changes. A CNAME lets the destination service manage the underlying address through its hostname. However, DNS providers may handle CNAMEs at the root or apex domain differently. If you need to point example.com to a hostname, check whether your provider supports an apex alias, flattening, or another provider-specific feature. Do not create a CNAME at a name that already has conflicting records.

Checklist by scenario

Launching or moving a website

1. Confirm whether the host supplied an IPv4 address, IPv6 address, hostname, or more than one of these.
2. Choose A for IPv4, AAAA for IPv6, or CNAME for a hostname.
3. Set the record name to the required host. The root may appear as @, a blank field, or the full domain, while a subdomain usually uses only its label, such as www or app.
4. Remove or update obsolete records only after confirming what currently serves the domain.
5. Repeat the setup for every hostname the application uses, such as the root domain and www.
6. Test both HTTP and HTTPS after DNS resolves. DNS pointing alone does not prove that the host is configured to serve the right domain or certificate.

For a migration, document the existing records before changing them. Keeping a copy of the old values makes rollback easier and helps distinguish a DNS problem from a hosting or application problem.

Setting up email with MX records

1. Obtain the complete MX record list from the mail provider, including each server hostname and priority.
2. Enter the mail domain in the name field, commonly represented by @ for the root domain.
3. Add each MX record separately when multiple mail servers are provided.
4. Enter the numeric priority exactly. Lower numbers generally indicate preference over higher numbers when a sender selects among records.
5. Remove old MX records only when you are certain the previous mail service is no longer needed.
6. Add any requested TXT records for SPF, DKIM, or DMARC according to the provider's instructions.

Do not put an IP address in an MX value unless the provider explicitly documents a special workflow; MX values normally identify mail hostnames. Also, SPF is published as a TXT record, not as an MX record. Because email authentication values are easy to damage by duplication or incorrect quoting, copy them carefully and verify them after DNS updates.

Adding TXT record verification

Services use TXT records to confirm control of a domain or subdomain. Copy the complete string, including its label and punctuation. The host field may be the root domain, a service-specific name such as _acme-challenge, or another value supplied by the service.

Some DNS dashboards add quotation marks automatically, while others expect you to enter the value without them. Use the dashboard's instructions and check the resulting record with a DNS lookup. If the value is long, the provider may display it across multiple quoted segments; do not manually alter the content unless the service tells you to.

Adding a CAA record

CAA records help express which certificate authorities are permitted to issue certificates for a domain. Add one only when you understand the certificate workflow and have the exact issuer value required by your certificate provider. A typical CAA entry includes a flag, a tag such as issue, and an issuer value.

Before adding CAA restrictions, check for existing CAA records at the relevant domain and understand whether the certificate authority needs permission for issuance, wildcard issuance, or both. A restrictive record can prevent an otherwise valid certificate request if the issuing authority is not included. Treat CAA changes as part of certificate management, not as a general website redirect setting.

Redirecting a domain

DNS does not perform an HTTP redirect. A DNS record can direct a hostname to infrastructure, but the web server, hosting platform, CDN, or registrar forwarding feature must return the redirect response. If you need example.com to send visitors to another URL, configure the redirect in the web-serving system and ensure the domain still resolves to that system.

What to double-check

Names, trailing dots, and host fields

DNS interfaces differ in how they interpret names. A field labeled Name, Host, or Label may expect only blog, the full name blog.example.com, or a special root symbol such as @. Entering the full domain into a field that automatically appends the domain can create an unintended name such as blog.example.com.example.com.

Destination hostnames may be shown with a trailing dot, for example mail.example.net.. That dot represents a fully qualified DNS name. Many dashboards accept either form, but do not add extra punctuation or spaces beyond what the provider requests.

TTL and propagation

TTL, or time to live, tells recursive resolvers how long they may cache a response. A lower TTL can make planned changes easier to roll out, while a higher TTL can reduce repeated lookups. Changing TTL does not erase cached answers immediately; resolvers may continue using an earlier response until its previous TTL expires.

Propagation is therefore not a single global event. Different networks, devices, and resolvers can show different results while caches expire. When troubleshooting, record the time of the change, the previous TTL if known, and the exact resolver or network producing the unexpected result.

Use targeted lookups

Check the exact record type and hostname you changed. An A lookup cannot confirm an MX or TXT record, and checking www does not confirm the root domain. Compare results from more than one resolver or network when practical, but remember that a lookup result only shows DNS data; it does not confirm that the destination service is healthy.

For an application deployment, combine DNS checks with a direct request to the hostname, certificate inspection, and an application-level test. For email, check MX and authentication records separately. For a TXT verification task, confirm the exact host and complete value.

Common mistakes

• Editing the wrong DNS zone: The domain's active nameservers point somewhere else, so the change has no effect.
• Creating duplicate records: A leftover A, CNAME, or MX record conflicts with the new configuration or produces unpredictable results.
• Using a CNAME where other records already exist: A hostname generally cannot combine a CNAME with records such as A, AAAA, MX, or TXT at the same name.
• Entering a URL instead of a hostname: DNS values do not include https://, paths, query strings, or trailing page names.
• Forgetting subdomains: Configuring the root domain does not automatically configure www, api, mail, or other labels.
• Replacing all TXT records: Multiple services may rely on separate TXT entries. Update the requested entry without deleting unrelated verification or email-policy records.
• Assuming DNS controls redirects: A record changes where a name resolves; an HTTP redirect must be configured by the service receiving the request.
• Testing too soon: A local cached answer can make a correct change appear broken, while a DNS result alone may hide a hosting or certificate issue.

Keep a simple change log with the date, hostname, record type, old value, new value, reason, and rollback plan. This is particularly useful during domain migrations and email changes, where several records may be edited in sequence.

When to revisit

Use this DNS configuration guide again before a domain migration, new subdomain launch, email-provider change, certificate setup, CDN change, or verification request. Revisit it when a hosting platform changes the hostname or address it provides, when an application is moved between environments, or when a certificate renewal workflow begins failing.

Before planned maintenance, lower TTL only if you have a reason and enough time for the lower value to be observed before the change. After the change, restore the intended TTL once the configuration is stable. Review DNS records periodically for abandoned services, old verification values, unused subdomains, and mail records belonging to systems that no longer operate.

For your next change, use this short sequence:

1. Identify the active DNS provider and export or record the current zone values.
2. Write down the destination service's exact hostname, address, priority, or TXT content.
3. Choose the record type from the service's supplied value, not from the desired outcome alone.
4. Check for conflicts at the same hostname before saving.
5. Apply the change with an appropriate TTL and note the time.
6. Verify the specific record from more than one network or resolver when practical.
7. Test the complete service: page delivery, HTTPS, email flow, or verification—not just DNS resolution.

When a change still fails after caches should have expired, compare the authoritative zone with public lookup results and then inspect the destination service. This separates a DNS configuration error from a hosting, certificate, application, or email-policy issue.