Understanding DNS Records: A, CNAME, and MX Explained

Overview

DNS records are the instructions that tell the internet where to send traffic for your domain. When someone types your domain into a browser, DNS records are what route that request to the right server. When your email stops delivering, nine times out of ten a DNS record is either missing, wrong, or hasn’t finished propagating yet.

This article focuses on the three record types you’ll deal with most often: A records, CNAME records, and MX records. Each has a specific job, and mixing them up is a very common cause of broken websites and email. I’ll explain what each one does, when to use it, and what to watch out for during DNS setup.

Whether you’re pointing a new domain to a Host & Tech Shared Hosting account, setting up a subdomain for a staging environment, or configuring email delivery for your business, you’ll need a solid understanding of these records before you touch anything in your DNS zone.

Prerequisites

• Access to your domain registrar’s DNS management panel, or your hosting control panel (cPanel, Plesk, or WHM)
• Your server’s IP address (for A records) — find this in your hosting welcome email or control panel dashboard
• Your mail server hostname (for MX records) — provided by your email host or listed in cPanel under Email Routing
• An understanding that DNS changes are not instant — allow up to 48 hours for full propagation, though most changes resolve within 1–4 hours
• Editor access to the DNS zone — registrar-level access if your nameservers point externally, or cPanel/WHM access if you’re using Host & Tech nameservers

A Records

An A record (Address record) maps a hostname to an IPv4 address. It’s the most fundamental DNS record type. When someone visits example.com, their browser queries the A record to find out which IP address to connect to.

A records are also how you point subdomains to specific servers. A staging environment, a separate app server, or a dedicated mail server — all of these typically get their own A records.

Example A Records

example.com.        A    192.0.2.10
www.example.com.    A    192.0.2.10
staging.example.com A    192.0.2.55

The first two records point the root domain and www subdomain to the same server. The third points a staging subdomain to a different IP entirely — a common setup when running a separate dev environment on a VPS.

📝 Note: If your domain uses an IPv6 address, that’s handled by an AAAA record, not an A record. They work the same way but for IPv6 addresses. Don’t delete your A record just because you’ve added an AAAA record — most networks still rely on IPv4.

Setting an A Record in cPanel

1. Log in to cPanel and go to Domains > Zone Editor.
2. Click Manage next to the domain you want to edit.
3. Click + Add Record and select A from the type dropdown.
4. In the Name field, enter the hostname (e.g. staging — cPanel will append the domain automatically).
5. In the Address field, enter the IPv4 address.
6. Set the TTL. The default of 14400 (4 hours) is fine for most setups. If you’re expecting to change the record again soon, drop it to 300 first so propagation is faster.
7. Click Add Record to save.

⚠ Warning: If you edit the A record for your root domain (@ or example.com) and enter the wrong IP, your entire site goes down. Double-check the IP before saving. You can verify the correct IP using ping example.com before making changes so you have the current value noted somewhere.

CNAME Records

A CNAME record (Canonical Name record) is an alias. Instead of pointing a hostname to an IP address, it points it to another hostname. The DNS resolver then looks up that target hostname to find the actual IP.

The most common use case: pointing www.example.com to example.com, so both work without maintaining two separate A records. Another very common use case is third-party service verification — Google Search Console, Mailchimp, Zendesk, and many others ask you to add a CNAME record to prove domain ownership or activate a feature.

Example CNAME Record

www.example.com.   CNAME   example.com.
shop.example.com.  CNAME   stores.shopify.com.

The second example is how a Shopify storefront gets connected to a custom subdomain. The CNAME points to Shopify’s infrastructure, and Shopify handles everything from there.

⚠ Warning: You cannot use a CNAME record on your root domain (also called the zone apex — i.e. example.com with no subdomain prefix). The DNS spec doesn’t allow it. Some DNS providers offer a workaround called CNAME flattening or ALIAS records, but standard CNAME records on the root domain will cause problems. Always use an A record for the root domain.

📝 Note: You also can’t have a CNAME record on a hostname that has other record types. For example, if mail.example.com already has an A record, you can’t also add a CNAME for it. Remove the conflicting record first.

Setting a CNAME Record in cPanel

1. In Zone Editor, click Manage next to your domain.
2. Click + Add Record and select CNAME.
3. In the Name field, enter the subdomain (e.g. www or shop).
4. In the CNAME field, enter the target hostname. Make sure to include the trailing dot if your DNS editor requires fully qualified domain names — e.g. stores.shopify.com. — though cPanel handles this automatically.
5. Click Add Record.

MX Records

MX records (Mail Exchanger records) tell other mail servers where to deliver email for your domain. Without correct MX records, email sent to you@example.com has nowhere to go.

MX records always point to a hostname, never to an IP address directly. That hostname then needs its own A record. This is a detail a lot of people get wrong — setting the MX record to an IP address won’t work and will silently fail for many sending servers.

MX records also include a priority value (lower number = higher priority). If you have a backup mail server, you’d set it with a higher priority number so mail only goes there if the primary is unavailable.

Example MX Records

example.com.   MX   10   mail.example.com.
example.com.   MX   20   mail2.example.com.

If you’re using Google Workspace, your MX records will look different — Google provides its own set of hostnames and priority values during setup. Same goes for Microsoft 365. Always use the exact values your email provider gives you.

Setting an MX Record in cPanel

1. In Zone Editor, click Manage next to your domain.
2. Click + Add Record and select MX.
3. In the Priority field, enter the numeric priority (e.g. 10).
4. In the Destination field, enter the mail server hostname provided by your email host.
5. Click Add Record.
6. If you’re migrating email to a new provider, remove the old MX records after adding the new ones. Leaving multiple conflicting MX records in place causes unpredictable delivery.

⚠ Warning: In cPanel, also check Email > Email Routing and make sure it’s set to Remote Mail Exchanger if your email is hosted externally (e.g. Google Workspace, Microsoft 365). If it’s left on Local Mail Exchanger, cPanel will try to deliver mail locally and it’ll never reach Google or Microsoft’s servers. This catches a lot of people off guard.

Common Issues & Troubleshooting

Site Not Loading After Changing A Record

Cause: DNS propagation delay, or your local machine is still caching the old record.

Fix: First, check if the new record has propagated globally using a tool like dnschecker.org. If it shows the new IP elsewhere but not on your machine, flush your local DNS cache. On Windows: ipconfig /flushdns. On macOS (Sonoma/Ventura/Monterey): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux (systemd-resolved): sudo systemd-resolve --flush-caches. That command clears the OS-level DNS cache, which is the actual cause of the stale result you’re seeing.

Email Not Delivering After Switching to Google Workspace or Microsoft 365

Cause: MX records updated but cPanel’s Email Routing is still set to Local Mail Exchanger, so the server intercepts inbound mail before it ever reaches Google or Microsoft.

Fix: In cPanel, go to Email > Email Routing, select your domain, and switch it to Remote Mail Exchanger. Save. This is separate from the DNS zone and is a step the official migration guides for both Google and Microsoft tend to bury or skip entirely.

CNAME Record Not Working for Root Domain

Cause: You’ve tried to add a CNAME record for the root domain (example.com with no subdomain), which the DNS specification does not permit at the zone apex.

Fix: Use an A record for the root domain pointing to the target server’s IP. If you need CNAME-like behaviour at the root (common when using CDNs like Cloudflare or load balancers), use a DNS provider that supports CNAME flattening or ALIAS records.

MX Record Pointing to an IP Address Instead of a Hostname

Cause: Someone entered an IP directly in the MX destination field. This is invalid per RFC 5321.

Fix: Create an A record for a mail hostname (e.g. mail.example.com pointing to your mail server IP), then set your MX record destination to that hostname (mail.example.com). Delete the MX record with the raw IP.

DNS Changes Not Taking Effect Even After 48 Hours

Cause: The domain’s nameservers are still pointing to the old registrar or DNS provider, so your updated records are never actually being served.

Fix: Run whois example.com or check your registrar panel to confirm which nameservers the domain is using. If they’re not pointing to your current hosting provider’s nameservers, the records you’re editing have no effect. Update the nameservers at your registrar first, then make DNS changes. Nameserver propagation can itself take up to 48 hours.

FAQ