DNS Record Setup Guide: A, AAAA, CNAME, MX, TXT, SRV and When to Use Them

Overview

If you manage domain and hosting, DNS is the control layer that tells the internet where your services live. A domain can point a website to a server, route email to a provider, prove ownership of a service, or direct traffic to app-specific endpoints. Most problems happen not because DNS is obscure, but because one small detail was missed: the wrong hostname, a missing trailing dot in some panels, an old TTL, or a conflicting record already in place.

Here is the simplest way to think about the main dns record types:

• 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 mail systems where to deliver email for a domain.
• TXT record: stores text-based data, usually for verification, email authentication, or policy.
• SRV record: defines the hostname and port for specific services that support SRV lookups.

A few baseline rules make DNS configuration much safer:

• Know whether you are editing the authoritative DNS zone, not just a cached view in a registrar dashboard.
• Confirm the exact hostname you are updating: root domain, www, a subdomain, or a service-specific label.
• Check whether a record type can coexist with another at the same name.
• Lower TTL ahead of planned migrations if you want faster changeover.
• Wait for propagation and caching behavior before assuming a change failed.

If you are still deciding on domain choices or broader ownership settings, related reading on domain extensions, WHOIS privacy, and renewal pricing can help you avoid surprises before DNS becomes part of the workflow.

A record

Use an A record when you need a hostname to resolve directly to an IPv4 address, such as a web server, reverse proxy, load balancer, or appliance with a fixed public IP.

Typical use cases:

• Pointing the root domain to a hosting server
• Pointing a subdomain like app.example.com to a specific server
• Directing traffic to a firewall or edge service with a documented IPv4 endpoint

Example: example.com → 203.0.113.10

An A record is often the cleanest choice when your provider gives you a stable IP. It is also common at the root domain, where some DNS providers historically handled aliases differently.

AAAA record

Use an AAAA record when you need a hostname to resolve to an IPv6 address. If your hosting environment supports IPv6, this can improve reachability for networks that prefer it.

Typical use cases:

• Publishing IPv6 connectivity for a website or application
• Running dual-stack service with both A and AAAA records
• Supporting modern infrastructure where IPv6 is part of the expected network path

Example: example.com → 2001:db8::10

If you publish AAAA records, make sure the service is actually reachable over IPv6. A broken AAAA record can create intermittent or location-specific failures that are harder to diagnose than a missing one.

CNAME record

Use a CNAME when one hostname should be an alias of another hostname. This is common for subdomains that point to SaaS platforms, CDNs, managed app endpoints, or platform-specific targets that may change behind the scenes.

Typical use cases:

• www.example.com → hosting-provider.example.net
• docs.example.com → docs-host.vendor.net
• shop.example.com → stores.platform.net

A record vs CNAME is one of the most common points of confusion. Use an A record when you have an IP address. Use a CNAME when you are aliasing to another hostname. In many DNS systems, a CNAME cannot coexist with other records at the same exact name, which matters for mail, verification, and service combinations.

MX record

Use MX records to define where inbound email should be delivered for a domain. MX records do not point users to webmail; they tell other mail servers which mail hosts are responsible for your domain.

Typical use cases:

• Connecting a domain to a business email provider
• Migrating mail from one provider to another
• Running backup or multiple-priority mail routes where supported

Example:

• Priority 10 → mail1.provider.net
• Priority 20 → mail2.provider.net

When you change MX records, also review related TXT records for SPF, DKIM, and sometimes DMARC. Mail routing and mail authentication usually need to be aligned.

TXT record

TXT records are flexible and widely used. They often carry domain verification strings, email authentication policies, security-related settings, and service ownership proofs.

Typical use cases:

• Search engine or SaaS domain verification
• SPF policy for outbound mail authorization
• DMARC policy publication
• Human-readable notes in limited internal setups, though this is less common for public DNS

TXT record verification issues often come down to placing the record at the wrong label. Some providers want the token at the root domain, others at a subdomain like _acme-challenge or selector._domainkey.

SRV record

Use SRV records when a protocol supports service discovery via DNS and needs more than just a hostname. SRV can define service, protocol, priority, weight, port, and target.

Typical use cases:

• SIP and VoIP services
• XMPP and some messaging systems
• Internal or specialized applications that query SRV records

Example structure: _service._protocol.example.com → priority, weight, port, target

SRV is less common in basic website launches, but it appears often in unified communications and service discovery workflows.

Checklist by scenario

Use this section as the reusable checklist before you make DNS changes. The right record depends on the service you are connecting.

1. Point a domain to a website or hosting server

• If the host gives you an IPv4 address, create or update an A record.
• If the host gives you an IPv6 address and supports it properly, add an AAAA record.
• If the host gives you a target hostname, use a CNAME for the subdomain they specify.
• Confirm whether the root domain and www should resolve separately or one should redirect to the other.
• Check whether your platform requires proxying, flattening, or an ALIAS-style feature at the root.

This is the basic answer to how to point a domain to hosting. If the site is moving between providers, lower TTL first and keep the old environment available until traffic has fully shifted.

2. Connect a domain to WordPress hosting

• Identify whether your WordPress host wants an IP address or a canonical hostname.
• Set the root domain with an A or provider-supported alias method.
• Set www with a CNAME if the provider recommends it.
• Make sure the WordPress site URL matches the final hostname plan.
• Verify SSL after DNS resolves to the new host.

If you are working through how to connect domain to WordPress, keep in mind that DNS can be correct while the site still redirects incorrectly because of application-level URL settings.

3. Set up business email hosting

• Add the provider’s required MX records exactly as documented.
• Add the required TXT records for SPF and any verification tokens.
• Add DKIM records if the provider uses TXT or CNAME-based selectors.
• Publish DMARC if you are ready to monitor or enforce mail policy.
• Remove obsolete MX records from the old provider after cutover is complete.

MX record setup should be treated carefully during migrations. Old and new records can overlap in ways that cause split delivery or inconsistent routing.

4. Verify a domain with a third-party service

• Use the exact host label requested by the service.
• Add the verification token as a TXT record.
• Do not replace an existing unrelated TXT record unless the provider explicitly says to merge values or add another entry.
• Wait for DNS propagation before retrying verification.

This is a common use case for analytics tools, certificate automation, SaaS admin consoles, and developer platforms.

5. Configure a subdomain for a SaaS product

• Use a CNAME when the vendor provides a hostname target.
• Confirm whether they want app.example.com, help.example.com, or another specific subdomain.
• Check whether SSL is managed by the provider or requires extra validation.
• Make sure no conflicting A, AAAA, or TXT records already exist at that same hostname.

This pattern is common for documentation portals, storefronts, support centers, and external app front ends.

6. Publish IPv6 without breaking reachability

• Add AAAA only if the service listens correctly over IPv6.
• Test the hostname from an IPv6-capable network.
• Confirm firewall rules, reverse proxy config, and origin binding.
• Keep the A record in place unless you deliberately want IPv6-only resolution.

Dual-stack DNS often works well, but only if both network paths are truly functional.

7. Set up a service that requires SRV

• Confirm the exact service and protocol labels, such as _sip._tcp.
• Enter priority, weight, port, and target exactly as specified.
• Check whether a supporting A or AAAA record is also needed on the target host.
• Test with a client or service-specific lookup tool after publishing.

SRV entries are structured and easy to mistype. Small formatting errors can be enough to break discovery.

What to double-check

Before and after any DNS change, run through these checks. They prevent most production mistakes.

• Authoritative DNS location: Are you editing DNS at the registrar, a DNS host, or a CDN provider? The visible dashboard is not always the live authority.
• Correct hostname: @, blank, root, and full hostname fields are handled differently across interfaces.
• Conflicting records: A CNAME usually cannot live beside other records at the same name.
• TTL settings: Long TTLs slow migrations; very short TTLs are useful during planned changes but not always necessary long term.
• Provider formatting: Some panels append the zone automatically, others want the full name.
• Mail dependencies: Changing MX without reviewing SPF, DKIM, and DMARC can create mail delivery or trust issues.
• IPv6 readiness: AAAA should only be published when the service path actually works.
• Old records: Clean up outdated entries after the new setup is stable.

For migrations, this is especially important if you are moving domain and hosting or shifting DNS between providers. A companion resource on domain transfer without downtime or email breakage is worth reviewing before major changes.

Common mistakes

Most DNS outages are not caused by advanced edge cases. They come from a small set of repeat mistakes.

Using a CNAME at the wrong place

A CNAME is useful, but it is often misapplied. If the same hostname also needs MX, TXT, or other records, a CNAME may create a conflict. This is a common source of verification and mail issues.

Changing MX but forgetting authentication records

Mail can appear partially functional while SPF or DKIM is still pointed at the old provider. The result may be failed delivery, spam placement, or inconsistent outbound trust.

Publishing AAAA before IPv6 works

If the app, reverse proxy, origin server, or firewall is not ready for IPv6, users on some networks may get failures even when IPv4 is healthy.

Editing the wrong DNS zone

This happens after registrar changes, CDN setup, or nameserver changes. You update a zone that looks correct, but the domain is delegated elsewhere.

Not planning around TTL during migrations

If you keep a long TTL until the moment of cutover, caches may hold old answers longer than you expect. For website migration without downtime, lower TTL in advance, not after the move.

Putting verification tokens on the wrong label

Many TXT verifications fail because the token was added to the root when the service expected a subdomain, or vice versa.

Assuming propagation means uniform behavior everywhere

Some resolvers refresh faster than others. One location seeing the new answer does not mean every client is updated yet. A good DNS propagation checker guide mindset is to compare multiple resolvers and also query the authoritative nameservers directly.

When to revisit

DNS is not a one-time task. Revisit your records whenever infrastructure, providers, or business requirements change. Use this action list as a maintenance routine:

• Before a hosting migration: Review A, AAAA, CNAME targets, lower TTL, and verify the rollback path.
• Before moving email providers: Inventory MX, SPF, DKIM, and DMARC records and decide the cutover order.
• Before launching a new service: Confirm whether it needs CNAME, TXT verification, or SRV.
• After a domain transfer: Check nameservers, zone integrity, and service-specific records. If you are comparing providers, this also relates to broader choices around domain registration and DNS management.
• During quarterly maintenance: Remove stale records, review TTL choices, and validate mail and web endpoints.
• When workflows or tools change: New platforms often change their preferred DNS method or verification model.

A simple recurring checklist helps:

1. List every hostname in active use.
2. Map each hostname to its intended service owner.
3. Verify the record type matches the service requirement.
4. Remove records with no clear owner or purpose.
5. Test web, mail, and verification paths after changes.

If you want one habit to keep, make it this: do not change DNS from memory. Open the provider instructions, confirm the live zone, note the existing records, and make one deliberate change at a time. That approach is slower by a few minutes, but it prevents most of the avoidable downtime people associate with DNS complexity.

Used well, DNS is not just a setup step. It is part of your reliability layer. A clear record plan makes site launches smoother, email more dependable, migrations safer, and troubleshooting much faster the next time something needs to change.