Common DNS records

Last updated: 5 April 2021

Each domain should have a number of DNS records that define, among others, how website and email traffic are routed. This article looks at the most common DNS records.

NS (Name Server) records

Name Server (NS) records point to where DNS records for a domain are hosted. You can not change your domain’s name servers via your hosting control panel. Instead, name servers are defined in the control panel for your domain registration. If we are the registrar for your domain then you can change the name servers via your billing account:

• Select Domains
• Click or tap on the wrench icon to the right of your domain name
• Select Nameservers from the Manage menu

Image: the Nameservers page in our billing account.

In the above example, the name servers for the domain example.net are pointing to ns5.catalyst2.net and ns6.catalyst2.net (which are the name servers for our shared Linux servers). When a resolver tries to find the IP address for example.net it will obtain these name servers, and the resolver then knows that it can find more DNS records for the domain at that address.

Note: Like all DNS changes, it can take up to 24 hours for a change of name servers to fully propagate.

A and AAAA records

The DNS records we will discuss next can all be viewed and edited via your hosting control panel. In cPanel, you can manage the DNS records for your domain as follows:

• Select the Zone Editor
• Click or tap on the Manage link to the right of the domain name

Image: cPanel’s Zone Editor

The first record shown in the above image is the main A record for the domain example.net:

example.net.                 A         84.18.206.207

A and AAAA records map a domain name to an IP address. The above record defines the host name (example.net.), the type of record (A) and a value (84.18.206.207). In other words, it tells resolvers that website traffic for the domain example.net should be routed to the IP address 84.18.206.207.

A records are used for IPv4 addresses. For IPv6 addresses there is an AAAA record. It is likely that your website only has an IPv4 address. In that case there isn’t an AAAA record in your DNS zone.

A records for subdomains

As an eagle-eyed reader you may have noticed that there is full stop at the end of the domain name (“example.net.”). The trailing dot indicates that the name is a “fully qualified domain name”. This is the opposite of a “relative” domain name, which we will look at now.

If you look at the DNS zone for your domain you are likely to see more than one A record. For instance, there may also be A records for cpanel and webmail.

example.net.                 A         84.18.206.207
cpanel                       A         84.18.206.207
webmail                      A         84.18.206.207

Notice that the entries for cpanel and webmail don’t have a trailing dot. Both are relative names and the host name (“example.net.”) is implied. In other words, the host name “example.net.” is appended automatically if there is no trailing dot.

It is usually easier to enter the full domain. The following records are in effect identical to the records in the previous example:

example.net.                 A         84.18.206.207
cpanel.example.net.          A         84.18.206.207
webmail.example.net          A         84.18.206.207

CNAME (Canonical Name) records

Canonical name (CNAME) records define an alias (they point a domain to another domain). This is useful if you got lots of A records pointing to the same IP address.

In the last example we had three A records that all pointed to the IP address 84.18.206.207. We can make our DNS zone a little tidier by converting A records for subdomains to CNAME records:

example.net.                 A         84.18.206.207
cpanel.example.net.          CNAME     example.net.
webmail.example.net.         CNAME     example.net.
mail.example.net.            CNAME     example.net.
www.example.net.             CNAME     example.net.

Here, all four CNAME records resolve to 84.18.206.207. This works because the CNAME records point to the main A record, which in turn points to 84.18.206.207.

CNAME records can also point to an external domain. This is commonly used by third-party services. The below example shows three CNAME records used by Office 365 (note: this is purely an example – the actual Office 365 records you need to add may be different):

autodiscover.example.net.    CNAME     autodiscover.outlook.com.
lyncdiscover.example.net.    CNAME     webdir.online.lync.com.
sip.example.net.             CNAME     sipdir.online.lync.com.

MX (Mail Exchange) records

Mail exchange (MX) records define where mail for your domain should be routed to. In the following example the MX record is much like the CNAME records we created for our subdomains:

example.net.                 A         84.18.206.207
example.net.                 MX        example.net. (0)

The MX record for example.net simply points to example.net, which means that both the website and email are hosted at 84.18.206.207.

MX records have a priority field. In the above example the priority of our mail server is “0” (zero). As we have defined only one MX record the priority of the record doesn’t really matter, but the priority is important if you have more than one MX record.

You don’t need more than one MX record but it is useful to have multiple records. It is commonly used for load balancing and as a fall-back solution. If you got a Linux hosting package with us you probably have two MX records:

example.net.                 A         84.18.206.207
example.net.                 MX        example.net. (0)
example.net.                 MX        backuk-dmx01.active-ns.com. (100)

The second MX record in the above example points to one of our fall-back servers. The MX record has a higher priority number which, confusingly, means that it has a lower priority.

In other words, email for example.net are delivered to 84.18.206.207. If the email can’t be delivered to the primary mail server then it is routed to the fall-back server instead. The fall-back server then queues the email and tries to deliver it to the primary mail server at a later time.

External MX records

Your website and email don’t have to be hosted on the same server. For instance, the fall-back server we defined in the previous example points to an external server. If you are using our advanced spam filter then your MX records also point to an external server:

example.net.                 MX        st2.mx.email-filter.net. (10)
example.net.                 MX        st3.mx.email-filter.net. (10)

Incoming emails for example.net are now routed to the spam filter (which in turn delivers emails that are not marked as spam to your inbox).

In the above example both MX records have the same priority (10). This is an example of load balancing: because the priority values are equal incoming emails may be routed to either mail server, which spreads the work load.

Similarly, if you use G Suite for your email your MX records should be be as follows:

example.net.                 MX        aspmx.l.google.com. (1)
example.net.                 MX        alt1.aspmx.l.google.com. (5)
example.net.                 MX        alt2.aspmx.l.google.com. (5)
example.net.                 MX        alt3.aspmx.l.google.com. (10)
example.net.                 MX        alt4.aspmx.l.google.com. (10)

The Email Router

If your email is hosted elsewhere you may need to check if your domain’s email router is set up correctly. You find this option in cPanel by selecting Email Routing.

Image: cPanel’s Email Routing page.

By default, the router is set to Automatically Detect Configuration. This is usually fine, but it can cause issues. In particular, if both the DNS and mail for your domain are managed elsewhere then it is important that the email router is set to “remote”. Of course, we are happy to troubleshoot any mail delivery issues you may encounter.

TXT (Text) records

TXT records provide arbitrary text values for your domain name. If you got one of our hosting plans then you should see at least two TXT records: an SPF and DKIM record. Both are used to prevent email spoofing and make it less likely that your emails are marked as spam. You can learn more about these records on the SPF Records and DKIM records pages.

TXT records are also commonly used by third party services that need to verify if you control a domain name. Such services may ask you to add records like these:

example.net.                 TXT        verification_code=234u39fd989098d983900d9d933d0d0d
verifycode.example.net.      TXT        234u39fd989098d983900d9d933d0d0d

In the first example we added a TXT record for example.net and in the second we added a record for verifycode.example.net. It is worth noting that the ‘verifycode’ subdomain doesn’t have to exist – the value of the TXT record can still be retrieved via a DNS query.