Each domain should have a number of DNS records that define, among others, how website and email traffic should be 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. 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 screenshot is the main A record for the domain example.net:
example.net. A 18.104.22.168
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 (22.214.171.124). In other words, it tells resolvers that website traffic for the domain example.net should be routed to the IP address 126.96.36.199.
A records are used for IPv4 addresses. For IPv6 addresses there is an AAAA record. It is likely that your domain will only have an IPv4 address, in which case there won’t be 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 we entered 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 188.8.131.52 cpanel A 184.108.40.206 webmail A 220.127.116.11
Notice that in the above example 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.” will be 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 18.104.22.168 cpanel.example.net. A 22.214.171.124 webmail.example.net A 126.96.36.199
Canonical name (CNAME) records define an alias (they point a domain to another domain). This is useful if you got lots of A records that point to the same IP address.
In the last example we had three A records that all pointed to the IP address 188.8.131.52. If we got lots of A records pointing to the same IP address then we can make our DNS records a little tidier by converting A records for subdomains to CNAME records:
example.net. A 184.108.40.206 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 220.127.116.11. This works because the CNAME records point to the main A record, which in turn points to 18.104.22.168.
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 emails 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 22.214.171.124 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 126.96.36.199.
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 188.8.131.52 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, when an email arrives it will be routed to 184.108.40.206 by default. If, for whatever reason, mail can’t be delivered to the primary mail server the email will be routed to the fall-back server instead. The fall-back server will then queue the email and try to deliver it to the main 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 will also point to an external server:
example.net. MX st2.mx.email-filter.net. (10) example.net. MX st3.mx.email-filter.net. (10)
With these records incoming emails are routed to the spam filter (which will then route 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 would 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 means that cPanel will look at the MX records for you domain and figure out whether or not your email is hosted on the server. This setting should never cause any issues but if you find that emails are not being delivered after you changed your MX records then it is worth checking the Email Routing setting. Of course, we are also happy to troubleshoot any mail delivery issues you may encounter.
TXT records are used to provide arbitrary text values for your domain name. If you got one of our hosting packages you should see at least two TXT records: an SPF and DKIM record. Both records are used to prevent email spoofing and to make it more likely that your emails are delivered correctly. 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.