DNS Records Explained: A, CNAME, MX and TXT

The Domain Name System (DNS) is one of the internet's essential building blocks. It translates human-readable domain names into the information computers need to locate websites, deliver email and verify domain ownership.

When DNS is configured correctly, visitors can access your website and customers can send messages to your business email addresses without thinking about the underlying infrastructure. When a record is incorrect, however, a website may become inaccessible, email may stop arriving or a third-party service may fail domain verification.

Understanding four common DNS record types — A, CNAME, MX and TXT — will help you manage your domain more confidently.

This guide explains what each record does, when to use it and how to avoid common configuration mistakes.

1. What Is a DNS Record?

A DNS record is an entry that associates a domain name or hostname with specific information. Depending on the record type, that information may be an IP address, another hostname, a mail server or a text-based policy or verification value.

For example, a domain might use:

• An A record to direct its website hostname to a server's IPv4 address.

• A CNAME record to make a subdomain point to another hostname.

• An MX record to identify the servers responsible for receiving email.

• A TXT record to publish email authentication policies or prove domain ownership.

DNS records are managed through the authoritative DNS service for your domain. This may be provided by your hosting company, domain registrar or a separate DNS provider.

Before making changes, confirm which provider manages your domain's DNS. Editing records in the wrong control panel will not change the records published by the authoritative nameservers.

2. A Records: Point a Hostname to an IPv4 Address

An A record maps a hostname to an IPv4 address.

For example:

FieldExample valueTypeANamewwwValue192.0.2.10TTL300 seconds

The IP address 192.0.2.10 is reserved for documentation and is used here as an example, not as a real hosting server address.

If the DNS provider uses the root symbol @ to represent the domain itself, an A record for @ can point the root domain to the same or a different IPv4 address.

When should you use an A record?

An A record is appropriate when you want a hostname to resolve directly to an IPv4 address.

Common uses include:

• Pointing example.com to a web server.

• Pointing www.example.com directly to a server.

• Directing a subdomain to a specific server.

• Updating a website's destination during a hosting migration.

How do you change an A record?

1. Sign in to your authoritative DNS management panel.

2. Find the relevant hostname.

3. Edit its A record or create one if it does not exist.

4. Enter the correct IPv4 address supplied by your hosting provider.

5. Save the change.

6. Check the published record using an independent DNS lookup tool.

Before changing an existing record, check whether other services depend on that hostname.

Important: An A record points to an IPv4 address. For an IPv6 address, use an AAAA record instead.

3. CNAME Records: Point One Hostname to Another

A CNAME record, or Canonical Name record, makes one hostname an alias of another hostname.

For example:

FieldExample valueTypeCNAMENameshopValuestore.example.netTTL300 seconds

In this example, shop.example.com follows the DNS resolution of store.example.net. The target hostname can resolve to an IP address through its own DNS records.

CNAME records are useful when a service provider gives you a hostname instead of a fixed IP address.

Common uses for CNAME records

• Connecting a subdomain to a hosted storefront.

• Pointing a subdomain to a service managed by another provider.

• Setting up certain verification or service hostnames.

• Allowing a subdomain to follow changes made to its target hostname.

What is the main CNAME restriction?

A CNAME generally cannot coexist with other ordinary DNS records at the same hostname. For example, you should not configure a CNAME at shop.example.com while also publishing an A record or MX record at that exact name.

The domain root, such as example.com, also commonly needs records such as MX and TXT. Traditional DNS therefore does not allow a standard CNAME at the root alongside those records.

Some DNS providers offer special features, such as CNAME flattening or ALIAS/ANAME records, to support root-domain routing. These are provider-specific features rather than standard CNAME behaviour.

Practical tip: Use a CNAME when you need a hostname to follow another hostname. Use an A record when you need to point directly to a known IPv4 address.

4. MX Records: Control Where Your Email Is Delivered

MX stands for Mail Exchange. An MX record identifies the mail servers responsible for receiving email sent to your domain.

For example:

FieldExample valueTypeMXName@Mail servermail.example.netPriority10TTL3600 seconds

The hostname and priority shown above are illustrative. Your email provider must supply the actual server names and priority values.

How MX priority works

When a domain has multiple MX records, the preference value determines which server is preferred. A lower numerical preference value represents a higher priority.

For example, an MX record with priority 10 is preferred over one with priority 20. If the preferred server cannot accept mail, sending systems may attempt another eligible server according to their delivery behaviour.

Multiple MX records do not automatically provide a functioning backup system. The servers must be configured to accept and handle mail correctly.

When should you update MX records?

You may need to change MX records when:

• Moving email to a new hosting provider.

• Setting up a new business email service.

• Changing your organisation's mail routing.

• Correcting a domain that sends incoming email to the wrong server.

Common MX record mistakes

Leaving the old provider's MX records in place: Incoming messages may continue routing to the previous mail service.

Using the wrong mail server hostname: Messages may fail to arrive if the hostname is incorrect or cannot be resolved.

Deleting records before preparing the new service: The new mailboxes may not be ready when delivery begins.

Assuming website hosting and email hosting must be the same: They can be provided by different companies. Changing your website's A record does not automatically require changing your MX records.

Before changing MX records, create the required mailboxes with the destination provider and confirm its migration instructions.

You can use a DNS lookup service to inspect published MX records and help diagnose email delivery problems.

5. TXT Records: Publish Verification and Email Policies

TXT records store text-based information associated with a domain or hostname. They are widely used for email authentication, domain verification and service configuration.

Common examples include SPF, DKIM and DMARC records.

SPF records

Sender Policy Framework (SPF) identifies which mail servers and services are authorised to send email using your domain.

A simplified illustrative SPF record might look like this:

v=spf1 ip4:192.0.2.10 -all

The example authorises the documentation-only IPv4 address 192.0.2.10 and specifies a fail result for other senders. It should not be copied into a live domain.

Use the SPF record supplied or recommended by your email provider. If you send mail through several services, ensure all legitimate sending sources are accounted for in one valid SPF policy at the relevant hostname.

Publishing multiple SPF records at the same hostname can cause SPF evaluation to fail.

DKIM records

DomainKeys Identified Mail (DKIM) allows an email service to sign outgoing messages cryptographically. Receiving systems can use the published public key to verify the signature.

Your provider will typically give you a selector and the required DNS record name and value. Depending on the service, the key may be published as a TXT record or through another supported DNS record format.

Copy the supplied values accurately. Missing characters, incorrect hostnames or an outdated key can prevent successful verification.

DMARC records

Domain-based Message Authentication, Reporting and Conformance (DMARC) builds on SPF and DKIM. It lets a domain owner specify how receiving systems should handle messages that fail DMARC checks and can enable reports about authentication activity.

A simplified example is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This example requests monitoring without a quarantine or rejection policy and specifies a reporting address. The reporting mailbox must be configured appropriately, and reporting support varies by receiving provider.

A monitoring policy can help you identify legitimate senders that have not been configured correctly before moving to a stricter policy.

Domain verification

Some services ask you to add a TXT record to prove that you control a domain. The provider supplies a unique verification value, which you publish in DNS.

Once the record is visible, the service can check it and confirm domain ownership.

Important: TXT records can serve different purposes at different hostnames. Follow the service's exact instructions rather than assuming every TXT record belongs at the domain root.

6. Understanding TTL and DNS Propagation

TTL stands for Time to Live. It tells DNS resolvers how long a record may be cached before they should query again.

For example, a TTL of 300 seconds represents five minutes.

A lower TTL can help resolvers refresh a record sooner after its cached value expires. A higher TTL can reduce repeated DNS queries but may cause changes to remain cached for longer.

Should you lower TTL before a migration?

If you are planning a hosting migration, lowering the TTL in advance can reduce how long some resolvers continue using an old cached value.

A common planning approach is to reduce the relevant record's TTL to around 300 seconds before the change, provided the DNS provider supports it.

However, changing the TTL immediately before changing the record does not erase values already cached under the previous TTL. Plan ahead and allow time for the old cache entries to expire.

DNS changes also do not necessarily become visible everywhere at exactly the same time. Resolver caching, provider behaviour and the record being changed can affect the transition.

A safe DNS migration sequence

1. Identify the records that need to change.

2. Confirm the destination server or service is ready.

3. Reduce the relevant TTL in advance, where appropriate.

4. Wait for the previous TTL period to expire.

5. Update the necessary DNS records.

6. Check the result using multiple resolvers or an independent lookup tool.

7. Test website access or email delivery.

8. Restore a longer TTL later if that suits your operational requirements.

Do not change unrelated DNS records during a migration unless necessary.

7. How to Check Your DNS Records

After making changes, verify the records published by your authoritative DNS service rather than relying only on what appears in the control panel.

On Windows, open Command Prompt and run:

nslookup -type=A example.com
nslookup -type=CNAME www.example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com

Replace example.com with your domain. The CNAME command is most useful for a hostname configured as a CNAME; a hostname configured with an A record will not return a CNAME record.

On Linux or macOS, you can use dig:

dig example.com A
dig www.example.com CNAME
dig example.com MX
dig example.com TXT

To query a specific resolver, add its address to the command. For example:

dig @1.1.1.1 example.com MX

You can also query your domain's authoritative nameserver directly, provided you know its hostname.

When troubleshooting, compare results from the authoritative server and one or more public resolvers. This can help distinguish an incorrect DNS configuration from cached information.

8. Common DNS Problems and How to Troubleshoot Them

SymptomPossible causeWhat to checkWebsite does not loadIncorrect A or AAAA recordConfirm the destination IP addresswww works but the root domain does notMissing or incorrect root-domain recordCheck the root A/AAAA record and redirectsRoot domain works but www does notMissing or incorrect www recordCheck its A or CNAME configurationIncoming email stopsIncorrect or outdated MX recordsCompare published MX records with provider instructionsMessages fail authenticationIncorrect SPF, DKIM or DMARC configurationCheck record names, values and alignmentDomain verification failsMissing or incorrect TXT recordCopy the exact hostname and verification valueSome users see the old destinationCached DNS responsesCheck TTLs and compare multiple resolvers

DNS is not the only possible cause of these symptoms. Website server configuration, SSL certificates, firewalls, mail server settings and application errors can produce similar problems.

Use DNS lookups to establish what is being published, then investigate the relevant service if the records are correct.

9. DNS Management Best Practices

A few disciplined habits can prevent avoidable downtime.

• Document important records. Keep a record of why each non-obvious entry exists and which service depends on it.

• Save the original values. Before changing a record, record its current value and TTL so you can restore it if necessary.

• Make one change at a time. This makes it easier to identify the cause if something stops working.

• Verify after every important change. Check published DNS values and test the affected service.

• Protect access to DNS management. Use strong passwords and multi-factor authentication where available.

• Avoid deleting unfamiliar records. They may support email authentication, verification, subdomains or other business services.

• Review records during migrations. Confirm that the website, email and third-party integrations are still configured correctly.

• Keep an eye on domain renewal. An expired domain can disrupt the services that depend on it.

Frequently Asked Questions

What is the difference between an A record and a CNAME record?

An A record maps a hostname directly to an IPv4 address. A CNAME maps one hostname to another hostname, which is then resolved through DNS.

Does changing an A record affect email?

Not necessarily. Website routing and email routing are usually controlled by different DNS records. Changing an A record does not automatically change MX records, although services that share a hostname may need additional checks.

What happens if I delete an MX record?

If no valid MX records remain, mail delivery may be affected. SMTP has fallback behaviour in certain circumstances, but you should not rely on it as a substitute for correct MX configuration. Confirm the mail provider's requirements before removing a record.

Can I have multiple MX records?

Yes. Multiple MX records can provide preferred and alternate mail destinations, provided the mail servers are configured to handle the domain correctly.

How long does DNS propagation take?

There is no fixed time that applies to every change. Visibility depends on cached records, TTLs, authoritative DNS behaviour and the resolvers involved. A low TTL can help, but it does not guarantee immediate global updates.

Are SPF, DKIM and DMARC all TXT records?

They are commonly published using TXT records, although DKIM can also use other DNS record formats supported by the relevant service. Use the exact record type and values specified by your provider.

Where should I manage my DNS records?

Manage DNS through the provider hosting your domain's authoritative nameservers. If your registrar delegates DNS to a separate service, changes made only at the registrar may not affect the published records.

Conclusion

Understanding A, CNAME, MX and TXT records gives you a solid foundation for managing your domain. A records direct hostnames to IPv4 addresses, CNAME records point hostnames to other hostnames, MX records control incoming email routing, and TXT records publish authentication policies and verification information.

Before making DNS changes, confirm which provider manages your records, save the existing values and verify the result independently. During migrations, plan around TTLs and test the affected service instead of assuming that a saved change has already taken effect everywhere.

For more information about managing your online presence, explore SteboHost hosting plans, domain services and the available domain lookup tools.