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.
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:
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.
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:
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 184.108.40.206
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 (220.127.116.11). In other words, it tells resolvers that website traffic for the domain example.net should be routed to the IP address 18.104.22.168.
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.
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 22.214.171.124 cpanel A 126.96.36.199 webmail A 188.8.131.52
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 184.108.40.206 cpanel.example.net. A 220.127.116.11 webmail.example.net A 18.104.22.168
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 22.214.171.124. We can make our DNS zone a little tidier by converting A records for subdomains to CNAME records:
example.net. A 126.96.36.199 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 188.8.131.52. This works because the CNAME records point to the main A record, which in turn points to 184.108.40.206.
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.
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 220.127.116.11 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 18.104.22.168.
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 22.214.171.124 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 126.96.36.199. 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.
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)
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 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.