DNS Records: How to Configure A, AAAA, CNAME, MX, and TXT Correctly

DNS is almost invisible while it works. One incorrect character, an outdated nameserver, or a deleted MX record can make the website, business email, and third-party verification fail at the same time.

Safe domain management does not require memorising every DNS standard. It requires understanding three layers: where the domain is delegated, which DNS zone is authoritative, and which records inside that zone control the website, email, and other services.

This guide explains the essential record types, common configurations, and a controlled process for changing infrastructure without avoidable downtime.

What is DNS?

The Domain Name System is a distributed system that connects human-readable domain names to technical addresses and services. When a visitor enters example.com, a DNS resolver locates the authoritative answer and returns an IP address or another requested record.

A simplified lookup path:

1. the browser or operating system checks its local cache;
2. a recursive resolver searches for the answer;
3. root and TLD servers identify the authoritative nameservers;
4. an authoritative server returns data from the DNS zone;
5. the resolver caches the answer for the record's TTL.

Use the BB STUDIO DNS Lookup to inspect the records currently visible on the internet. Before editing anything, still confirm which provider hosts the authoritative zone.

Domain, nameserver, and DNS zone are different

A registrar maintains domain registration and delegation. A nameserver answers for a DNS zone. The DNS zone contains A, MX, TXT, and other resource records.

For example, a domain can be registered with one company, use Cloudflare DNS, host the website elsewhere, and receive email through Google Workspace or Microsoft 365. That is a normal architecture.

A common mistake is editing records at the registrar even though the domain delegates to another DNS provider. The interface accepts the changes, but the public internet never sees them.

Before starting, record:

• the current authoritative NS set;
• the provider hosting the active DNS zone;
• a full export or screenshot of the zone;
• old and new server IP addresses;
• every service that relies on the domain;
• access to the registrar, DNS provider, and hosting account.

Essential DNS record types

A — a hostname to an IPv4 address

An A record maps a name to an IPv4 address.

Type: A
Name: @
Value: 192.0.2.10
TTL: 300

In many dashboards, @ represents the zone apex: example.com. For a subdomain, the Name field might contain shop or api.

Do not copy the documentation IP into production. Use the address supplied by the host or administrator. If a provider changes server IPs without preserving them, a direct A record may require manual maintenance.

AAAA — a hostname to an IPv6 address

AAAA performs the equivalent function for IPv6.

Type: AAAA
Name: @
Value: 2001:db8::10
TTL: 300

Do not add AAAA merely for completeness if the server does not serve the site over IPv6. Some clients may prefer IPv6 and receive an error while IPv4 continues to work.

CNAME — an alias to another name

A CNAME points to another hostname instead of an IP address.

Type: CNAME
Name: www
Target: example.com
TTL: 300

It is commonly used for www, a CDN, SaaS platforms, and technical subdomains. A CNAME should not coexist with conflicting records at the same owner name.

A conventional CNAME is usually unsuitable at the zone apex because the apex also needs SOA and NS data. DNS providers solve this with features named ALIAS, ANAME, or CNAME flattening. Follow the provider's documented apex method rather than creating an invalid combination.

MX — business email routing

MX records identify the servers that receive email for a domain. Each value contains a mail hostname and a priority.

Type: MX
Name: @
Priority: 10
Target: mail.example.net
TTL: 3600

A lower number represents a higher preference. If the email provider supplies several MX values, enter every one exactly as instructed. An MX target should be a hostname rather than a direct IP, and it should not point to a name that resolves only through CNAME.

Moving the website does not automatically require an MX change. Preserve the existing mail records when email is hosted separately.

TXT — policies and ownership verification

TXT records commonly carry:

• domain ownership verification;
• SPF sender policy;
• a DKIM public key;
• DMARC policy and reporting instructions;
• verification tokens for search, advertising, and SaaS platforms.

A domain can have multiple TXT records, especially at different names. However, two independent SPF policies at the apex create an SPF evaluation error. All authorised sources should be combined into one valid policy.

Use the SPF generator and DMARC generator to prepare the syntax, then compare every value with the current documentation of the email provider.

NS — delegation

NS records identify authoritative nameservers. At the registrar level, they delegate the entire domain. Inside a zone, they can delegate an individual subdomain.

Do not change nameservers as a routine way to “connect hosting.” Replacing NS moves responsibility for the entire zone. If the new zone omits MX, TXT, CAA, or service subdomains, those services disappear from public DNS.

CAA — authorised certificate issuers

CAA can restrict which certificate authorities may issue certificates for a domain. It improves control, but an incorrect policy may prevent automatic SSL issuance or renewal.

Confirm which certificate authority the hosting platform or CDN actually uses. 

SRV — a service hostname and port

SRV describes the target hostname, port, priority, and weight for a network service. It is used by VoIP, chat, enterprise tools, and other protocols. Copy the supplied values exactly, including underscores in the service and protocol labels.

Name, value, priority, and TTL

DNS does not route to a page path. https://example.com/catalog/ is not a valid A or CNAME target. Redirecting visitors to a particular URL is handled by the web server or application.

TTL and DNS propagation

TTL tells a recursive resolver how long it may cache an answer. If the previous record had a TTL of 86,400 seconds, some users may continue receiving the old address for up to a day after a change.

A practical migration sequence:

1. reduce the TTL of affected records 24–48 hours in advance, for example to 300 seconds;
2. wait for the previous higher TTL to expire;
3. prepare and test the new server before public DNS changes;
4. switch the required records;
5. keep the old server available during the transition;
6. return TTL to a normal operating value after validation.

Propagation is not one global process with a completion button. Authoritative servers may return the new value immediately while recursive resolvers continue using cached data.

Common configurations

Website on one server

@      A       192.0.2.10
www    CNAME   example.com

The web server must recognise both hostnames, and the certificate should cover both example.com and www.example.com.

Website and email with different providers

@      A       192.0.2.10
www    CNAME   example.com
@      MX 10   mail.provider.example
@      TXT     v=spf1 include:provider.example -all

Changing the A record affects the website but should not remove MX or TXT. This is why clearing the entire zone during a hosting migration is dangerous.

Subdomain connected to a platform

shop   CNAME   shops.platform.example

The platform must also know about shop.example.com, verify it, and issue SSL. A DNS record alone does not configure the application.

How to connect a domain to hosting

A dependable order of work:

1. add the domain to the new hosting account;
2. upload the site and database;
3. configure environment variables, scheduled tasks, outgoing mail, and caching;
4. test through a temporary address or a local hosts-file override;
5. obtain the exact A, AAAA, or CNAME values from the host;
6. change only the required DNS records;
7. issue or validate SSL;
8. test pages, forms, payments, and mail;
9. keep the old server online during the transition.

If the infrastructure has not been selected, compare the requirements and formats of website hosting. During website development, document every production domain, subdomain, and third-party integration before launch.

Moving DNS without downtime

Changing nameservers requires more preparation than updating one A record.

Before the NS change

• build the new zone with every current record;
• compare A, AAAA, CNAME, MX, TXT, CAA, and SRV;
• include operational subdomains;
• copy SPF, DKIM, and DMARC;
• reduce TTL in the old zone in advance;
• ensure that DNSSEC will not leave a stale DS record.

During the change

• update NS at the registrar;
• keep the old DNS zone active;
• query several independent resolvers;
• monitor the website, email, and certificates separately.

After the change

• ensure all authoritative servers give consistent answers;
• send and receive test messages;
• test forms, payments, webhooks, and APIs;
• retire the old infrastructure only after the transition is stable.

DNS and business email

MX controls inbound delivery. SPF, DKIM, and DMARC normally support sender authentication and spoofing protection.

• SPF declares permitted sending infrastructure;
• DKIM adds a cryptographic signature, with its public key published in DNS;
• DMARC establishes policy and reporting based on aligned authentication.

Do not invent these values. Copy MX hosts, DKIM selectors, and SPF include mechanisms from the provider. Begin DMARC with monitoring, review the reports, and only then strengthen enforcement so legitimate marketing and transactional senders are not blocked.

DNS, HTTPS, and search indexing

After an IP change, the web server must return the intended site for every production hostname. If the new server shows a placeholder, redirect loop, or wrong certificate, DNS may already be correct and the fault may be at the HTTP layer.

Test:

• HTTP and HTTPS;
• apex and www;
• every language version;
• canonical tags and sitemap;
• robots.txt;
• 200, 301, 404, and 5xx responses;
• Search Console after the move.

How to verify DNS changes

Browser-based lookup

Inspect A, AAAA, CNAME, MX, TXT, NS, and CAA. Check the authoritative servers and TTL, not only the presence of one expected value.

Command line

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

With dig:

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

For deeper diagnosis, query an authoritative nameserver directly and compare the answer with public recursive resolvers. Running ipconfig /flushdns clears the local Windows cache; it does not purge ISP or global resolver caches.

Common DNS mistakes

1. Records are edited outside the authoritative zone.
2. The dashboard appends the domain twice in Name.
3. A full https:// URL is entered as CNAME or MX target.
4. CNAME conflicts with another record at the same name.
5. AAAA points to a server without functional IPv6.
6. MX, SPF, DKIM, or DMARC disappears during migration.
7. Two independent SPF records are published.
8. MX points to an IP or a CNAME alias.
9. Nameservers change without a complete zone copy.
10. TTL is reduced only after the switch.
11. The old server is shut down immediately.
12. DNSSEC remains linked to the old provider.
13. A wildcard is used instead of explicit subdomains without a reason.
14. SSL, forms, and email are not tested after DNS.

DNS security

• enable multi-factor authentication at the registrar and DNS provider;
• use individual accounts and least privilege;
• lock domain transfers;
• keep zone backups;
• maintain a change log;
• remove obsolete verification TXT records;
• find dangling CNAME records pointing to abandoned third-party resources;
• deploy DNSSEC only with a controlled DNSKEY and DS process;
• monitor registration expiry and ownership contacts.

A dangling CNAME deserves particular attention. If a subdomain points to a deleted SaaS resource, another party may be able to claim that resource and take control of the subdomain.

Pre-change checklist

• the authoritative DNS provider is known;
• the current zone has been backed up;
• the record type matches the service documentation;
• Name does not duplicate the domain;
• Value contains no unnecessary protocol or path;
• the IP or hostname has been verified;
• TTL suits the migration plan;
• MX and mail-related TXT records remain intact;
• CNAME has no conflicting records;
• AAAA is used only with working IPv6;
• SSL can cover the new hostname;
• verification and rollback steps are documented;
• the old server remains online during the transition.

Conclusion

Safe DNS work begins with a map of domain dependencies, not with the Add record button. A and AAAA point to addresses, CNAME creates an alias, MX controls inbound mail, TXT carries policies and verification, and NS determines where the authoritative zone is hosted.

Change only what is required, lower TTL in advance, preserve email records, and test the website, HTTPS, and mail separately. For a safe migration, zone audit, or unavailable website, use BB STUDIO website support or contact the team.