On this page
An Introduction to DNS Record Types
A plain-language guide to the most common DNS record types, from A and MX records through to SRV and CAA.
DNS records are the instructions that tell the internet where to send traffic for your domain - whether that is web visitors, email, or third-party services. Each record type has a specific job, and knowing what they do makes working in cPanel's Zone Editor much less daunting.
Where to make DNS changes
Before editing any record, you need to know where your DNS is hosted. If your domain's nameservers point to Kualo (they will look something like the nameservers listed for your account type), you manage DNS records in cPanel's Zone Editor. If your nameservers point to an external provider such as Cloudflare or another registrar, you must make changes there instead - edits in cPanel will have no effect.
Not sure which applies to you? Check the article on which nameservers you should use, or see our guide on how to add or manage DNS records in cPanel's Zone Editor.
A records
An A record maps a domain name or subdomain to an IPv4 address. It is the most fundamental record type - without it, browsers do not know which server to load your website from.
Example
yourdomain.com. 3600 IN A 203.0.113.10
www.yourdomain.com. 3600 IN A 203.0.113.10
When would I use this? Any time you want a domain or subdomain to point to a specific server. The most common case is pointing your domain to your Kualo hosting server when you first set things up.
AAAA records
An AAAA record does the same job as an A record but for IPv6 addresses. IPv6 uses a longer address format and is becoming more common, though on shared hosting you are unlikely to need one unless a specific service asks for it.
Example
yourdomain.com. 3600 IN AAAA 2001:db8::1
When would I use this? Rarely on shared hosting. Some third-party services or CDN providers may ask you to add one as part of their setup.
CNAME records
A CNAME (Canonical Name) record creates an alias that points one hostname to another hostname rather than directly to an IP address. When a browser looks up the alias, it follows the chain to find the final IP.
Example
www.yourdomain.com. 3600 IN CNAME yourdomain.com.
mail.yourdomain.com. 3600 IN CNAME mail.example-provider.com.
When would I use this? Common uses include pointing www to your root domain, and verifying ownership of your domain with third-party services such as Google Search Console or Microsoft 365.
A CNAME record cannot be placed on a bare (root) domain - for example, you cannot set a CNAME on yourdomain.com itself, only on subdomains such as www.yourdomain.com. This is a hard rule in the DNS standard. Additionally, a CNAME cannot share a name with any other record type - if a name already has an A or MX record, you cannot add a CNAME to the same name.
MX records
An MX (Mail Exchanger) record tells other mail servers where to deliver email for your domain. Without a correct MX record, email sent to your domain will not arrive.
Each MX record has a priority value - a lower number means higher priority. If you have two MX records with priorities of 10 and 20, mail servers try the priority-10 server first and only fall back to the priority-20 server if the first is unavailable.
Example
yourdomain.com. 3600 IN MX 10 mail.yourdomain.com.
yourdomain.com. 3600 IN MX 20 mail2.yourdomain.com.
MX records must point to a hostname, never directly to an IP address. Pointing an MX record at an IP is a common mistake that will cause mail delivery to fail.
When would I use this? If you switch your email to a provider such as Google Workspace or Microsoft 365, they will give you new MX records to add. Changing MX records affects all incoming mail for your domain, so double-check the values before saving. See also our guide on how to add an MX entry in cPanel.
TXT records
A TXT record holds free-form text associated with a domain. In practice, TXT records are used for three main purposes.
SPF - sender authorisation
An SPF record lists the mail servers that are authorised to send email on behalf of your domain. Receiving mail servers check this record to decide whether to trust a message.
yourdomain.com. 3600 IN TXT "v=spf1 include:mailserver.example.com ~all"
DKIM - email signing verification
A DKIM record publishes a public key that receiving servers use to verify the cryptographic signature on outgoing messages. It is usually added as a subdomain of your domain.
default._domainkey.yourdomain.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
Domain ownership verification
Many third-party services - Google Search Console, Microsoft 365, and others - ask you to add a TXT record to prove you control the domain. The value is unique to your account with that service.
yourdomain.com. 3600 IN TXT "google-site-verification=abc123xyz"
When would I use this? You will almost certainly need TXT records for SPF and DKIM if you send email from your domain. For a full walkthrough of setting these up, see our guide on authenticating your domain with SPF, DKIM and DMARC.
NS records
NS (Name Server) records delegate authority for a DNS zone to a set of nameservers. They tell the rest of the internet which servers hold the authoritative DNS records for your domain.
Example
yourdomain.com. 3600 IN NS ns1.kualo.net.
yourdomain.com. 3600 IN NS ns2.kualo.net.
When your NS records point to Kualo's nameservers, we serve your DNS zone and changes you make in cPanel's Zone Editor take effect. When they point elsewhere, that provider is in control of your DNS.
If you are on shared hosting, please contact our support team before changing NS records at the zone level. Incorrect NS changes can take your entire domain offline and are difficult to reverse quickly.
When would I use this? NS records are usually set at your domain registrar, not in Zone Editor. You might update them when updating nameservers at Kualo or when moving DNS management to an external provider.
SRV records
An SRV (Service) record tells clients how to find a specific service running on your domain. It includes several fields that together describe the service location.
| Field | What it means |
|---|---|
| Service | The name of the service, e.g. _sipfederationtls |
| Protocol | Usually _tcp or _udp |
| Priority | Lower value = higher priority (same logic as MX) |
| Weight | Used to load-balance between targets with equal priority |
| Port | The TCP or UDP port the service listens on |
| Target | The hostname of the server providing the service |
Example (Microsoft Teams/Skype for Business federation)
_sipfederationtls._tcp.yourdomain.com. 3600 IN SRV 100 1 5061 sipfed.online.lync.com.
When would I use this? SRV records are rarely needed on everyday shared hosting, but you will encounter them when following setup guides for Microsoft 365, VoIP systems, or some chat platforms. Copy the values exactly from the provider's documentation.
CAA records
A CAA (Certification Authority Authorisation) record controls which certificate authorities (CAs) are permitted to issue SSL certificates for your domain. If no CAA record exists, any CA can issue a certificate - adding one restricts issuance to the authorities you name.
Example
yourdomain.com. 3600 IN CAA 0 issue "letsencrypt.org"
yourdomain.com. 3600 IN CAA 0 issue "sectigo.com"
The 0 is a flags field (almost always zero). The tag issue permits the named CA to issue standard certificates; issuewild covers wildcard certificates; iodef specifies an email or URL for violation reports.
When would I use this? Most shared hosting customers do not need to add a CAA record - omitting it means any CA can issue, which is fine for most sites. You might add one if your security policy requires you to restrict certificate issuance, or if a compliance requirement demands it. If you add a CAA record, make sure it includes the CA that issues your current SSL certificate, otherwise renewals will fail.
A note on TTL
Every DNS record has a TTL (Time to Live) value - the number in seconds shown in the examples above. TTL controls how long resolvers around the internet cache your record before checking for an update. A TTL of 3600 means one hour. If you are planning a DNS change where timing matters - such as moving to a new server - it is good practice to lower the TTL to a smaller value (such as 300 seconds) a day or two beforehand, then restore it after the change is complete. For more on this, see our article on DNS propagation and how long it takes.