DNS is a tricky part about hosting your website. I often say that DNS is a bit like an onion: There’s many layers to it, and it’s very likely that you’ll cry if you try to get through them all. We’ll leave the bulk of how DNS works for another time, but this guide will help you with the remarkably easy (albeit daunting) task of updating, adding, or removing DNS records for your domain in Plesk.
First, we’ll need to log in to Plesk, after which we’ll be taken to the Websites and Domains screen. Click on “DNS Settings” for the domain you wish to edit.
Now you have several options; you can add, edit, or remove a DNS record, or even turn off the DNS service / switch it to slave mode; in this guide we will only cover adding a record.
To add a new DNS entry, click the “Add Record” button and you’ll be taken to the following page:
There is a “Record type” drop-down which allows you to select the type of DNS entry to add. There are many options available; select the type of record below to see the individual processes in more detail:
The “A” record is the most common type of record for DNS – it links a domain name (or subdomain) to an IPv4 Address. An IPv4 address is the 12-digit number you often see when dealing with websites or even your own home network. It is in the format: xxx.xxx.xxx.xxx
When adding an A record there are two input boxes; the subdomain and the IP address. If you input “testing” in the subdomain box, and a corresponding IP address in the IP address box, you will have created a subdomain “testing.yourdomain.com” pointing at that IP address. Enter the information and click “OK”.
This process is the exact same as above, however the “AAAA” indicates that it is an IPv6 address. These addresses appear in the following example format: 2002:7b7b:7b7b::1
A CNAME record is an alias; when a visitor goes to the listed subdomain, they will be forwarded to the given “canonical” domain.
Enter the subdomain (or leave blank to apply a CNAME for the entire domain) and put the target for the alias in the “Canonical domain” field.
The MX (Mail eXchange) record is incredibly important; this record tells email servers where to send mail sent to your domain. In our default setup it is pointed to “mail.yourdomain.com”, which is set up as your mail server. This may need to be changed if you are using Office 365 or Google Apps for Business for your email.
The MX DNS screen has three fields:
- The domain (or subdomain) to receive mail for.
- This should be left blank to configure mail on the main domain
- The destination mail server.
- In our cases, this is mail.yourdomain.com
- The priority of the mail exchange server.
Priority is an entirely new concept for us here; it’s used in the case of having backup mail servers – as you would if you used Google Apps for Business. It basically says “Send mail here, if it fails there, try this one. If that fails, try this one.” If you’re configuring a MX, the instructions you’re following should also give you examples of what the priorities should be.
This section is woefully blank as PTR records do not work with our setup; if you have a dedicated IP address with Websavers and want a rDNS configured, please reach out to us directly.
The TXT Record is one of the most commonly edited records for new webmasters. Why is this? Because it’s invaluable for verifying domain ownership for companies such as Google, Microsoft, GoDaddy, and other online service providers.
In most cases you do not require to have an entry for the domain portion of this; Google, for example, wants this section left blank. In the TXT field, the second field on the screen, you enter the verification string provided to you.
This is the SRV screen. It is the most daunting of all the DNS entries, and is generally only needed for advanced users. If you’re setting up an auto discover service for Office 365, or Skype for Business, or another service that requires a SRV record: Don’t panic! It’s not quite as bad as you may think.
Often, a SRV record is displayed in the following format:
This format, when broken down, means:
Service name: sip
Protocol name: tcp
Domain name: example.com
So, if you’re presented with something like this:
_autodiscover._tcp.yourdomain.com priority 100, weight 1, port 443, yourdomain.autodiscover.outlook.com
That just means that in the above fields, you would put in:
Service name: autodiscover
Protocol name: tcp
Domain: (leave blank)
Priority: 100 (Plesk maxes out at 50, go ahead and use 50)
Weight: 5 (Plesk goes from 0 to 5 before increasing further)
Target port: 443
Target host: yourdomain.autodiscover.outlook.com
With this information, a mail client – for example – trying to auto detect settings, checks out your domain, it will see that for an “autodiscover” request, it should connect to yourdomain.autodiscover.outlook.com on port 443 to get the information – pretty clever!