How to Set Up Custom DNS Records on Any Hosting Control Panel
To set up DNS records on any hosting control panel, you open the DNS editor, choose a record type, and paste the name, TTL, and value that your provider gave you. The mechanics are identical whether you use cPanel, Plesk, or your domain registrar, because they all edit the same underlying zone file. This guide walks you through A, CNAME, MX, and TXT records, with the exact commands to verify your work from a terminal.
How to set up DNS records: the zone file is the source of truth
Every domain on the internet resolves through a zone file, a plain text file that maps names to values. Your control panel renders this file as a table, but the logic is the same. When you add an A record, the panel appends a line like example.com. 3600 IN A 203.0.113.10. The TTL, here 3600 seconds, tells recursive resolvers how long to cache the answer. Lower TTLs mean faster propagation when you change records, but more queries to your authoritative server. For testing, set TTL to 300; for stable production records, leave it at the panel default, often 14400.
The critical rule is that you never edit the zone file by hand unless you are using the panel's raw editor, which cPanel exposes as Zone Editor and Plesk hides under DNS Settings. Most panels give you a form, not a text box. That form prevents syntax errors, but it also hides the trailing dot. In DNS, fully qualified names end with a dot. If your provider gives you a target like target.example.net, the panel will often add the dot for you. If you paste it into a raw editor, you must write target.example.net. or the record will be interpreted as relative to your domain.
Adding A and CNAME records without breaking your site
The A record maps a hostname to an IPv4 address. To add one in cPanel, navigate to Zone Editor, select your domain, click Add Record, and type www in the Name field and 203.0.113.10 in the Address field. In Plesk, go to Domains, your domain, DNS Settings, then Add Record. The registrar's interface, often under Advanced DNS, works the same way. The name field accepts a bare label like www or a full name like www.example.com. Either is fine; the panel normalizes it.
CNAME records are subtler. A CNAME cannot coexist with other records on the same name. You cannot have a CNAME for www and also an MX record for www, because the CNAME replaces the entire name. Practically, this means you use CNAME for subdomains that point elsewhere, like blog.example.com to your-provider.example.net, but you never put a CNAME on the bare domain (example.com) because that would block your MX records for email. If you need the bare domain to point to a host, use an A record with the IP address.
Here is how you verify an A record you just added. From any machine with dig installed, run:
dig A www.example.com +short
203.0.113.10
The output shows the IP. If you see nothing, the record has not propagated or you mistyped the name. Wait five minutes and retry, because your local resolver may cache the negative answer. For a CNAME, the output will show the target name, not an IP:
dig CNAME blog.example.com +short
your-provider.example.net.
Editing MX records without losing email
MX records tell other mail servers where to deliver email for your domain. The record has two parts: a priority number and a hostname. Lower numbers win. If you have two mail servers, 10 mail.primary.example.net and 20 mail.secondary.example.net, the primary is tried first. When you switch email providers, you replace the entire MX set. Never add a new MX while leaving the old one, because mail will split between the two, and you will lose messages.
In cPanel, the MX editor is under Zone Editor, then Manage for your domain. You will see a list of existing MX records. Delete all but the one you are replacing, then add the new hostname with priority 10. In Plesk, the same list appears under DNS Settings. At a registrar, look for Mail Exchanger or MX Records. The hostname in an MX record must be a domain, not an IP address. If your provider gives you an IP, ask for a hostname, because many mail servers reject MX records pointing directly at IPs.
Verify your MX setup with this command:
dig MX example.com +short
10 mail.primary.example.net.
20 mail.secondary.example.net.
Check that the priority numbers match what you intended. A common mistake is leaving the old provider's MX at priority 5, which will keep stealing your mail. If you see an unexpected entry, edit the zone again and remove it.
Adding TXT records for SPF and verification tokens
TXT records are free-form text strings attached to a name. Their most common uses are SPF, which declares which servers may send mail for your domain, and domain verification tokens from services like Google or Microsoft. An SPF record on the bare domain looks like v=spf1 include:_spf.provider.net ~all. The include directive pulls in the provider's published list of sending IPs, and ~all tells receivers to soft-fail mail from other sources. You only have one SPF record per domain. If you add a second one, both are ignored and mail fails authentication.
In cPanel, TXT records go through the same Zone Editor. For Plesk, use DNS Settings. The value field takes the full string in quotes, but the panel adds the quotes for you, so paste it without them. For a verification token, the name is often @ for the bare domain or a long subdomain like _dmarc for DMARC. Follow the provider's instructions exactly, because the token is case sensitive and must match character for character.
Test a TXT record with:
dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:[email protected]"
For SPF on the bare domain, run dig TXT example.com +short and confirm you see exactly one v=spf1 line. If you see two, delete the duplicate immediately.
Deleting records safely and checking for conflicts
Deletion is where most damage happens. Before you delete any record, write down what it was. In the panel, find the record, click the delete or remove icon, and confirm the action. The panel will not warn you that a CNAME deletion breaks a linked subdomain, or that removing an MX record stops all inbound mail. To avoid surprises, make a backup of the zone file first. In cPanel, use the Backup feature under Zone Editor to download the file. In Plesk, use the Export DNS button. At a registrar, copy the entire record list into a text file.
After any change, run a full query against your authoritative nameserver, not just the cached response. Use dig @ns1.provider.net example.com ANY to see the raw zone. The ANY query returns all record types, but many resolvers block it, so query specific types instead. The important check is that your new record coexists with existing ones. For example, if you added a CNAME for mail.example.com, confirm no A record remains on that same name, because the two conflict and the CNAME will be ignored.
Finally, remember that DNS propagation is not a single event. Different resolvers cache for different lengths of time. Your own machine may see the new record immediately while a colleague on another network still sees the old one. Plan for a transition window of up to 48 hours for TTLs of 14400 seconds, and shorten TTLs a day before a planned change to make the switch faster. After you set up your records, verify email delivery from an external account, check that your website loads over HTTPS, and then move on to configuring DMARC and monitoring your zone with a service that alerts you on changes.
