DNS Records Explained: A, AAAA, CNAME, MX, TXT, and SRV Records With Examples

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into service locations that browsers, mail servers, and applications can use. Your domain registrar may provide DNS management, or you may manage the zone through a separate DNS provider. In either case, the records follow the same basic logic.

A DNS record usually includes a type, a name or host, a value, and a TTL. The type describes the record’s purpose. The name identifies the domain or subdomain. The value points to an IP address, another hostname, or a text instruction. TTL, or time to live, indicates how long resolvers may cache the response.

Use this simplified model when reviewing a zone:

• A: points a hostname to an IPv4 address.
• AAAA: points a hostname to an IPv6 address.
• CNAME: points a hostname to another hostname.
• MX: identifies mail servers for a domain.
• TXT: stores text used for verification, email policies, and other instructions.
• SRV: identifies the host and port for a named service.

DNS changes are not the same as changes to your web server or hosting account. Adding an A record does not deploy a website, and adding an MX record does not create a mailbox. DNS only directs requests; the destination service must also be configured and working.

Checklist by scenario

Hosting a website on a cloud server

1. Confirm the public IPv4 address of the server.
2. Create an A record for the root domain, using the host format required by your DNS provider. Some providers represent the root as @; others leave the name field blank.
3. Create an A record for www if you want the www version to reach the same server.
4. If the server has a usable IPv6 address, add an AAAA record for the same hostname. Do not add an AAAA record with an address that is not configured or reachable.
5. Configure the web server to respond to the domain and its preferred variant, such as the root domain or www.
6. Complete the SSL setup after DNS points to the correct server. DNS alone does not issue or install a certificate.

Example records:

@      A       203.0.113.20
www    CNAME   example.com.

The IP address above is an example address. Replace it with the address assigned to your own hosting environment. A CNAME is often useful for a subdomain because it follows the target hostname if the target’s address changes. Follow your provider’s instructions for whether the final dot is required; many dashboards add it automatically.

Connecting a subdomain to another service

Use a CNAME when a provider gives you a hostname rather than a fixed IP address. For example:

docs     CNAME   project.docs-provider.example.
status   CNAME   status-page.example.

This can be appropriate for documentation, a status page, an application platform, or a hosted landing page. Do not create a CNAME and another conflicting record for the same hostname. A CNAME generally cannot coexist with an A, AAAA, or other standard data at that exact name.

Setting up domain email

Mail delivery uses MX records. An MX record contains a priority number and a mail-server hostname; lower numbers normally represent higher delivery preference.

@      MX      10 mail1.mail-provider.example.
@      MX      20 mail2.mail-provider.example.

Use the exact hostnames and priorities supplied by your email provider. The MX target should be a hostname, not an IP address. If the provider also supplies SPF, DKIM, or DMARC instructions, add those records as directed. SPF is commonly stored as a TXT record at the root domain, while DKIM is usually published at a selector subdomain such as selector1._domainkey. DMARC is commonly placed at _dmarc.

Verifying ownership of a domain

Many platforms verify control of a domain by asking you to publish a TXT record:

@      TXT     "provider-verification=unique-token"

Copy the value exactly, including punctuation where required. Some dashboards automatically add quotation marks; others expect you to enter the text without them. Verification records can often remain in place, but remove obsolete records when a provider specifically asks you to do so or when they are no longer needed.

Configuring a service with a nonstandard port

SRV records are used by services that need a hostname, port, priority, and weight. A typical format is:

_service._tcp   SRV   10 5 443 service.example.com.

Here, 10 is the priority, 5 is the weight, 443 is the port, and the final field is the target hostname. The exact service label, protocol, and values must come from the application’s documentation. An SRV record does not replace the A or AAAA record needed to resolve its target hostname.

What to double-check

• Authoritative nameservers: Make sure you are editing the DNS provider whose nameservers are delegated at the registrar. Editing the wrong dashboard will not change the active zone.
• Root versus subdomain names: A record for @ affects the root domain, while www, app, and mail affect separate hostnames.
• Record conflicts: Check for duplicate A, AAAA, MX, or TXT values and for a CNAME combined with another record at the same name.
• Mail priorities: Confirm that MX records point to the intended provider and that old mail servers have been removed when a migration is complete.
• IPv6 behavior: An incorrect AAAA record can cause some users to reach the wrong destination even when the A record is correct.
• TXT formatting: Preserve spaces, punctuation, selector names, and long-record segmentation exactly as the receiving service specifies.
• TTL and timing: Record changes may appear at different times because resolvers cache answers. Avoid repeatedly changing values while waiting for a prior change to become visible.
• Application configuration: Confirm that the hosting platform, reverse proxy, website, mail service, and SSL certificate all recognize the domain after DNS is updated.

For a website launch, test the root domain, www version, important subdomains, and HTTPS separately. For email, test both inbound and outbound delivery and review the provider’s domain-authentication status rather than relying only on the presence of TXT records.

Common mistakes

Using an IP address in a CNAME: CNAME records require a hostname. Use an A or AAAA record for an IP address.

Adding a trailing domain twice: Some DNS interfaces treat an unqualified name as relative to the zone. Entering www.example.com in a field that automatically appends example.com can produce an unintended name. Check how the interface formats the saved record.

Leaving old MX records active: During an email migration, old and new records can split delivery or send messages to an inactive service. Keep only the records required by the current configuration.

Publishing multiple unrelated SPF records: SPF is normally represented as one policy at a given hostname. If several services need authorization, combine their mechanisms according to the provider instructions instead of creating competing SPF TXT records.

Expecting DNS to redirect visitors: DNS can point a hostname to a destination, but an HTTP redirect must be configured by the web server or hosting platform.

Changing nameservers without copying records: Moving DNS providers changes the authoritative zone. Recreate website, email, verification, and service records before or during the move so that important services are not omitted.

When to revisit

Review DNS whenever a domain, hosting environment, email provider, or third-party service changes. Revisit it before a website launch, cloud server migration, domain transfer, email migration, SSL setup, or staging-to-production switch. It is also useful to review records before seasonal planning cycles if campaigns, landing pages, or temporary services are likely to change.

Keep a current inventory of domains, subdomains, record purposes, service owners, and the date of the last change. Before editing, export or document the existing zone where your provider allows it. After editing, verify the authoritative answer, test the affected service, and remove temporary verification records or obsolete destinations when they are no longer required.

Use this short action list before closing a DNS task:

1. Identify the authoritative DNS provider.
2. Write down the exact hostname and record type required.
3. Confirm the destination, priority, port, or text value from the service documentation.
4. Check for conflicts with existing records.
5. Save the change and allow for caching.
6. Test from the affected service, not only from the DNS dashboard.
7. Document the final configuration and remove records that are no longer needed.

This checklist keeps DNS management deliberate and recoverable, whether you are connecting a custom domain to cloud hosting, configuring business email, or adding a developer service to an existing domain.