DNS is a directory, not the website itself
The Domain Name System helps software find the network destinations associated with human-readable names. A business may own example.com, host its website on one service and receive email through another. DNS records describe how those services are found; they do not contain the website pages or the contents of a mailbox. A domain registration, authoritative DNS service, web server and mail provider can be four separate commercial relationships. Before changing anything, identify which company manages each layer. A correct DNS record is necessary for many connections, but it cannot repair a failed application or an unpaid hosting account.
Start with the authoritative nameservers
The registrar holds the domain registration and delegates its DNS through nameserver settings. The authoritative DNS provider is the place where the live zone records are published. If the registrar points to Cloudflare nameservers, editing a separate zone in an old cPanel account may have no public effect. Conversely, if the registrar still delegates to a hosting provider, records typed into an unused Cloudflare zone will not answer ordinary queries. Verify the actual nameservers first, then use the corresponding DNS management interface. Record the previous configuration before making a change, because switching nameservers can affect both website and email resolution.
A records connect names to IPv4 addresses
An A record maps a hostname to an IPv4 address. A business might use one A record for the root domain and another for a specific subdomain, depending on the hosting architecture. The record value must be the correct destination supplied by the hosting provider, not an address guessed from a browser screenshot. When a website moves servers, the A record may need updating after the new server is prepared and tested. An A record does not by itself enable HTTPS, configure the application or create an email mailbox. Verify the resulting address from an external DNS lookup and then test the actual service.
AAAA records handle IPv6 destinations
An AAAA record serves a similar purpose to an A record but supplies an IPv6 address. Some hosting platforms support both IPv4 and IPv6, while others provide only one address family. Adding an AAAA record merely because it seems modern can cause inconsistent connectivity if the destination does not actually serve the website. Ask the provider whether IPv6 is supported and which address should be published. When troubleshooting, compare A and AAAA answers separately; a browser may choose either path. If one family reaches an old server, users can see different results even when the root domain appears correctly configured.
CNAME records point one hostname to another
A CNAME record identifies another hostname as the canonical target for a name. It is often used for www, verification subdomains or services whose provider may change underlying IP addresses. The target must be a hostname, not an IP address. A conventional CNAME also has compatibility rules with other records at the same name; providers may implement special flattening for root domains. Do not replace an MX or TXT record with a CNAME merely because the destination looks similar. Copy the exact name and target from the service's instructions and confirm whether the DNS provider supports the intended arrangement.
MX records determine incoming mail destinations
Mail Exchange records identify servers that receive email for a domain. They include priorities and hostnames rather than the content of mailboxes. A company using Microsoft 365, Google Workspace or cPanel email needs MX values appropriate to its actual mail provider. Do not copy a generic example into a production zone; provider-specific values and priorities can differ. Changing MX records without a migration plan can send new messages to the wrong system while old mail remains elsewhere. Before a cutover, inventory existing records, confirm target mailboxes, plan testing and establish how undelivered or delayed messages will be investigated.
MX priority is not a performance ranking
MX records can list more than one destination with numerical preferences. The sending mail system uses those preferences according to mail delivery rules; a smaller number generally indicates a more preferred exchanger. The numbers are not customer ratings, service speeds or guarantees of automatic mailbox replication. Some providers require several MX entries for resilience, while others specify a single destination. Follow the exact provider documentation, including whether multiple entries are needed. If two unrelated mail services are mixed into the same MX set without design, messages may be delivered inconsistently. Test the intended primary and fallback behaviour where applicable.
TXT records carry verification and policy text
A TXT record stores text that other services can query through DNS. Providers commonly use TXT values to verify control of a domain before enabling email, analytics or certificate-related features. Email authentication mechanisms also use DNS text records, but the exact names and contents differ. A TXT entry is not a secret storage system: DNS answers can be queried publicly. Do not place passwords, API keys or customer data inside TXT records. When a provider gives a verification token, add it to the specified hostname and retain the required value only as instructed. Check whether older verification entries can be safely removed before deleting them.
SPF, DKIM and DMARC have different jobs
SPF helps identify authorised sending infrastructure, DKIM provides cryptographic message signing, and DMARC specifies how receivers should evaluate alignment and handle failures. These mechanisms often depend on TXT records, although DKIM selectors may be published through CNAMEs in some provider setups. They do not replace MX records, which control incoming mail routing. Copying another company's SPF policy can break legitimate sending or authorise an unintended service. Inventory every system that sends on behalf of the domain, including billing and newsletter platforms, before changing authentication. Test and monitor results rather than immediately applying an aggressive policy without evidence.
TTL controls caching, not a universal countdown
Time to Live tells DNS resolvers how long they may cache an answer before asking again. A shorter TTL can help planned changes become visible sooner, but it does not guarantee every user sees a new record at the exact same second. Local caches, provider behaviour and previous TTL values can still affect observations. Cloudflare documents different TTL options for proxied and DNS-only records. Before a scheduled migration, record the current values and plan any appropriate TTL adjustment early enough to matter. After the change, compare authoritative answers with several recursive resolvers rather than treating a single browser refresh as complete propagation proof.
Cloudflare proxy settings are not universal
Cloudflare can proxy eligible web-facing A, AAAA and CNAME records, but ordinary mail protocols do not pass through its standard HTTP proxy. An MX record is DNS-only, and a mail hostname used by SMTP, IMAP or POP3 normally needs to resolve directly to the mail service. Cloudflare's official troubleshooting guidance warns that proxying a mail hostname can prevent client connections. Do not toggle the orange-cloud setting on every record to make the zone look consistent. Identify which hostnames serve websites and which serve email, then follow the provider's instructions. A proxy change can alter traffic paths without changing the underlying mail subscription.
cPanel Zone Editor may not be authoritative
cPanel's Zone Editor can create and edit DNS records when the hosting account and provider configuration permit it. However, its existence in a dashboard does not prove that the public domain delegates to that server. The registrar's nameserver settings determine which authoritative zone the internet queries. If DNS is hosted elsewhere, a cPanel edit may remain local and invisible to customers. Before using Zone Editor, verify delegation and inspect the provider's feature permissions. Export or record existing A, CNAME, MX and TXT entries first. cPanel also warns that resetting a zone can erase modifications, so a reset is not a safe troubleshooting shortcut.
Root domain and www may need separate entries
Customers may type both example.com and www.example.com, but DNS treats those names separately. A business might publish an A record for the root and a CNAME for www, or use another arrangement recommended by its hosting platform. DNS alone does not determine which URL should be canonical for search engines; web server redirects and page metadata handle that separately. Test both addresses over HTTPS and confirm the expected redirect or content behaviour. If a provider supports special root-domain CNAME flattening, understand that this is provider-specific rather than a general rule for every DNS host. Keep the chosen architecture documented for future migrations.
Subdomains have independent DNS requirements
A business can use mail.example.com, shop.example.com or support.example.com for different services. Each hostname needs the records or delegation appropriate to its function. An A record for the root domain does not automatically create every subdomain. A wildcard record may cover some otherwise undefined names, but it can introduce unexpected routing and should not replace deliberate service configuration. When adding a subdomain, identify its owner, target service, TLS requirements and whether email authentication or verification records are needed. Test the exact hostname, not only the main website. Remove obsolete records only after checking that no active service still depends on them.
Plan a website migration without breaking mail
When moving a website to a new host, it may be sufficient to change a web-facing A or CNAME record while keeping MX and mail authentication records unchanged. The correct plan depends on whether the DNS host itself is also moving. Before cutover, capture the complete existing zone, prepare the destination, test the website on a staging hostname and document rollback values. Check whether the new provider expects any verification TXT records. Schedule changes when the responsible team can observe results. Never replace the entire DNS zone with a default hosting template without comparing every record; that can silently disconnect business email.
Diagnose DNS errors with evidence
If a website or mailbox stops working after a change, separate the symptoms. Check whether the domain is registered and active, whether nameservers are correct, whether authoritative DNS returns the intended records and whether the target server actually responds. A correct MX answer does not prove the mail server accepts messages; a correct A answer does not prove HTTPS works. Cloudflare recommends checking MX resolution against the email provider's expected values when diagnosing mail issues. Record query results, timestamps and error messages before further edits. Repeatedly changing unrelated records without a hypothesis makes the original cause harder to identify.
Keep an inventory of records and their owners
A useful DNS inventory records the hostname, type, value, TTL, provider, business purpose, service owner and last verified date. Label entries that support email, the main website, verification, certificates or external applications. Store the record history in a controlled location so that a new technician can understand why an unfamiliar TXT token exists. Avoid copying sensitive account credentials into DNS documentation. Review entries during supplier changes and staff departures, but do not delete a record merely because its purpose is unclear. First identify the associated service and confirm whether removal is safe. This small discipline reduces accidental outages during routine maintenance.
A hypothetical DNS change for a small company
Imagine a Malaysian consultancy moving its website from one hosting company to another while retaining Microsoft 365 email. The technician confirms the authoritative nameservers, copies the current zone and identifies the web A record, www CNAME, Microsoft MX and email authentication entries. After preparing and testing the new website, only the necessary web destination is changed. The team then checks both website hostnames, incoming mail, outgoing mail and certificate behaviour. This is a hypothetical decision process, not a universal record template: the exact values must come from each provider's current instructions. Keeping the mail records untouched is intentional, not an omission.
The safe change checklist
Before saving a DNS edit, confirm the domain and authoritative provider, the requested hostname, record type, exact value, TTL and intended service. Identify who authorised the change and what other records might depend on it. Capture a backup or export of the existing zone and specify the rollback value. After saving, verify the authoritative answer and then test the application or mail flow from an independent connection. Record the result and leave unrelated records alone. A DNS edit is implemented when the provider accepts it, but it is verified only when the intended service behaves correctly; those are distinct checkpoints for a business owner.