DNS Records Explained: A, CNAME, MX and TXT for Business Domains

DNS records are the entries in your domain's zone that tell the internet where your website, email and other services live. An A record points a name at an IPv4 address, a CNAME makes one name an alias for another, an MX record names the servers that accept your email, and a TXT record holds text that services read, such as SPF and domain verification values. Most business setups need only a handful of each.

Who this is for

This guide is for business owners and part-time administrators who manage a domain at a registrar or DNS host and need to point it at a website or an email service without breaking either. By the end you will be able to read a zone, add the right record type for each job, and check the result from the command line.

All examples use the placeholder domain contoso.com and the documentation address range 192.0.2.0/24, which is reserved for examples. Replace them with your own values.

The record types at a glance

The original DNS specification, RFC 1035, defines these as follows. The A record maps a host name to a 32-bit Internet address. The NS record names a host that should be authoritative for a domain. The CNAME record makes the owner name an alias for a canonical name. The MX record identifies a mail exchange host with a preference, a 16-bit integer, where lower values are preferred. The TXT record holds descriptive text, and its meaning depends on the domain where it appears.

Every record also has a TTL, the time to live. RFC 1034 describes it as a time limit on how long a record can be kept in a cache.

A and AAAA records

Use an A record when a name should resolve to a fixed IPv4 address, for example your web server or hosting provider's address.

Name              Type   Value          TTL
contoso.com       A      192.0.2.10     3600
www.contoso.com   A      192.0.2.10     3600

If your host also gives you an IPv6 address, add an AAAA record with the same names. Visitors with IPv6 connectivity will use it, so make sure the server really answers on that address before you publish it.

If the provider may change the address and gives you a host name instead, use a CNAME for the www name, not an A record.

CNAME records

A CNAME makes one name an alias for another. Resolvers then look up the target name instead.

Name                       Type    Value                      TTL
www.contoso.com            CNAME   contoso-site.example.net   3600
autodiscover.contoso.com   CNAME   <value from the admin center>   3600

The most important rule comes from RFC 1034: if a CNAME record is present at a name, no other data should be present at that name. Consequences:

• You cannot have a CNAME and an MX or TXT record on the same name.
• The root of your domain (contoso.com) must hold other data such as NS records, so a CNAME at the root is not valid in standard DNS. Some DNS providers offer a proprietary alias or flattening feature for this purpose. That is a provider feature rather than a standard record type, so check its documentation.
• Alias targets are host names, never IP addresses.

Microsoft's guidance for connecting a domain to Microsoft 365 uses CNAME records for services such as autodiscover, for the DKIM selectors (selector1._domainkey and selector2._domainkey) and for Intune enrollment, where the documented examples are enterpriseregistration and enterpriseenrollment. In each case you copy the target value shown in the admin center rather than typing it from memory, because the exact values depend on your tenant.

MX records

An MX record tells senders which servers accept email for the domain. Each record has a preference number, and lower numbers are tried first.

For Microsoft 365, the documentation says the MX record is required, uses the host name @ (the root), and that you copy the value from the Add DNS records page in the admin center. It also says to set the priority to the highest value available, typically 0, and the TTL to 3600. Exchange Online only supports TTL values less than 6 hours (21,600 seconds).

For Google Workspace, the setup page gives the value smtp.google.com with priority 1, host name left blank or @, and says accounts that started before 2023 may have MX values beginning with aspmx, which remain supported. It advises removing any other MX records, because leftover records can cause mail problems.

Name           Type   Priority   Value                             TTL
contoso.com    MX     0          <value from the admin center>     3600

Changing email providers

Both vendors stress sequencing. Microsoft says to add users and mailboxes before you change the MX record, because once you update it all new email for the domain goes to the new service. Existing mail stays at the old host unless you migrate it. If an MX record for the previous provider exists, either remove it or give it a lower priority, meaning a higher number, than the new record. Because lower numbers win, an old record with a lower number keeps delivering mail to the old provider.

TXT records

TXT records carry text. For business domains they usually hold three things.

The SPF example is the value Microsoft documents for Exchange Online. Two rules matter:

1. Only one SPF record. Microsoft's guidance says that if an SPF record already exists you must not create a second one, and should add the new include to the existing record, producing a single record that covers the old provider and Microsoft 365. RFC 7208 agrees: a domain must not have multiple records that would cause an authorization check to select more than one, and when more than one is found the result is permerror.
2. Ten lookups at most. RFC 7208 requires that SPF implementations limit the DNS-querying terms to 10, counting include, a, mx, ptr and exists and the redirect modifier. Exceeding it returns permerror. Every extra service you add with an include uses part of this budget.

For the complete email-authentication setup see SPF, DKIM and DMARC for Microsoft 365, and for DKIM selector problems see the DKIM CNAME fix.

NS records and where DNS is hosted

NS records name the authoritative servers for the zone. They are set at the registrar when you choose where DNS is hosted. Records you add in the wrong place have no effect. If your registrar lists name servers belonging to a different provider, edit the zone at that provider. Microsoft notes that the area for managing DNS settings goes by different names at different registrars, such as Zone File Settings, Manage Domains, Domain Manager or DNS Manager.

Microsoft also notes that some registrars support Domain Connect, which allows Microsoft 365 to confirm ownership and add the required records automatically. If yours does not, you add them by hand.

A typical small-business zone

contoso.com                       A       192.0.2.10
www.contoso.com                   CNAME   contoso.com.
contoso.com                       MX      0   <value from the admin center>
contoso.com                       TXT     "v=spf1 include:spf.protection.outlook.com -all"
autodiscover.contoso.com          CNAME   <value from the admin center>
selector1._domainkey.contoso.com  CNAME   <value from the admin center>
selector2._domainkey.contoso.com  CNAME   <value from the admin center>
_dmarc.contoso.com                TXT     "<your DMARC policy>"

Notice that no name carries a CNAME together with another record type.

Checking your records

From Windows PowerShell:

Resolve-DnsName -Name contoso.com -Type MX
Resolve-DnsName -Name contoso.com -Type TXT
Resolve-DnsName -Name www.contoso.com -Type CNAME

From a command prompt or Linux shell:

nslookup -type=MX contoso.com
nslookup -type=TXT contoso.com
nslookup -type=A www.contoso.com 8.8.8.8

Querying a public resolver such as 8.8.8.8, as in the last command, shows what the outside world sees. Remember that your own resolver may still hold the old value until its cache expires.

Troubleshooting

Email still goes to the old provider

Check for an old MX record with a lower preference number, or a record you did not remove. Remove or demote it, as Microsoft and Google both advise. Then wait for the previous TTL to pass.

The registrar will not accept a CNAME at the root

This is expected. Use an A record, or your provider's alias feature if it has one, for the root name.

SPF shows permerror or two records

List your TXT records and look for more than one beginning with v=spf1. Merge them. Then count the includes: more than 10 DNS-querying terms causes permerror.

A change does not appear

Compare the TTL with the time elapsed. Google's page notes changes can take up to 72 hours. For planned changes, lower the TTL a day or two earlier, then raise it again afterwards.

A record works for some users but not others

Different resolvers cache for different times. Test with several public resolvers and confirm you edited the zone at the provider named in your NS records.

A trailing dot problem

Some registrars require a trailing dot on host names in the value field, for example smtp.google.com., and Microsoft's examples include trailing dots for CNAME targets. Check your registrar's requirement. Without the dot, some interfaces append your domain name to the target.

Safe change checklist

• Export or screenshot the existing zone before changing anything.
• Know where DNS is hosted by checking the NS records.
• Lower TTLs before planned changes.
• Add new records first, remove old ones after verification.
• Keep one SPF record and stay within the lookup limit.
• Avoid CNAMEs on names that need other record types.
• Verify with Resolve-DnsName or nslookup against a public resolver.
• Record every change with date and reason.

References

• Microsoft 365: connect your domain by adding DNS records: https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider
• Google Workspace: set up MX records: https://knowledge.workspace.google.com/admin/domains/set-up-mx-records-for-google-workspace
• RFC 1034, Domain names - concepts and facilities: https://datatracker.ietf.org/doc/html/rfc1034
• RFC 1035, Domain names - implementation and specification: https://datatracker.ietf.org/doc/html/rfc1035
• RFC 7208, Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208