DNS records sit between a domain name and the website hosting behind it. When someone types a URL into a browser, DNS records translate that name into the actual server address where the WordPress site lives. Most website owners only think about DNS when something breaks — a new domain that won’t connect, email that stops delivering, a verification code with nowhere obvious to paste it. The biggest DNS mistakes tend to happen when people rush the process or aren’t sure which record type actually needs changing. Understanding how to point a domain to web hosting first gives useful context for what each record below actually controls.
DNS records are entries in a domain’s zone file, each with a type, a name, and a value, together telling the internet how to handle requests for that domain. Changes can take anywhere from a few minutes to 48 hours to propagate globally, depending on each record’s TTL (time to live). The IANA domains registry is the authoritative source on how the DNS root system itself is structured.
Where They Actually Live
For most WordPress sites, DNS records live at the domain registrar (GoDaddy, Namecheap, Porkbun, wherever the domain was bought) or the web hosting control panel, if the domain’s nameservers were pointed there. If nameservers moved to a hosting provider — common with cPanel hosting — look for a DNS Zone Editor in the host’s control panel; otherwise the registrar is where the records actually sit. A domain transfer to a new registrar brings the DNS records along with it.
The Record Types Worth Actually Knowing
The A record points a domain to an IPv4 address — the physical server the WordPress site is hosted on, and the most fundamental record of all: name @ for the root domain, value the server’s IP, a typical TTL of 3600 seconds (one hour). Less commonly mentioned but worth knowing exists: the AAAA record does the identical job for IPv6 addresses — increasingly relevant as more hosts and networks run dual-stack IPv4/IPv6, and worth adding alongside the A record if the host provides an IPv6 address, rather than leaving IPv6 traffic unhandled by default.
CNAME records point one domain name to another rather than to an IP address directly — used for subdomains, like pointing www.yourdomain.com to yourdomain.com. A CNAME can’t be set on the root domain (@) itself; that’s what the A record is for. MX records direct email for the domain to the correct mail server — Google Workspace or Microsoft 365 provide the specific values to add, each with a priority number where lower is preferred when multiple MX records exist. TXT records store plain text, used for domain verification (Search Console’s ownership check) and email authentication via SPF, DKIM, and DMARC — purely informational, they don’t affect how the site itself loads. NS records point to the authoritative nameservers for the domain and are rarely changed directly at the individual-record level — when a new host says “update your nameservers,” this is the record type actually being changed.
One more worth adding to the usual list: CAA records (Certificate Authority Authorization) specify which certificate authorities are allowed to issue an SSL/TLS certificate for the domain at all. Without one, any CA can technically issue a certificate for it; with a CAA record restricting issuance to, say, Let’s Encrypt, an attempt by any other CA to issue a certificate for the domain gets rejected outright — a real, low-effort security hardening step against a certificate being mis-issued by a compromised or careless CA. Most domains don’t have one set by default, and most registrars support adding it as a standard TXT-adjacent record type.
Editing Safely
Log into the registrar or hosting control panel, navigate to DNS Management/DNS Zone Editor/Advanced DNS, identify the exact record by type and name, and note the current value before changing anything — a real backup in case something needs reverting. Make the change, save, and check the TTL: a lower value (300 seconds, say) means changes propagate faster the next time this record needs editing, worth setting deliberately ahead of a planned migration rather than discovering it’s set to a slow default mid-change.
Moving an entire site to a new host: updating NS records at the registrar to point to the new host’s nameservers is the cleanest approach, transferring all DNS management at once. Making one specific change — an email record, a verification, a subdomain — means editing that individual record and leaving nameservers alone entirely. For domain verification specifically (Search Console and similar), copy the TXT value exactly as provided, set the name to @ or as specified, and wait for propagation before triggering verification inside the service. Setting up business email typically needs MX records for incoming mail, TXT records for SPF/DKIM, and sometimes a CNAME for DKIM signing — the email provider supplies exact values, worth copying precisely including any trailing dots shown.
Never delete NS records — it takes the domain entirely offline. Most registrars expect just “www” in a name field, not the full “www.yourdomain.com” — a common formatting mistake. DNS changes genuinely take time to propagate; clear the local DNS cache and test in an incognito window to see the actual current live state rather than a cached one. Check for existing records of the same type and name before adding new ones, since duplicates cause real conflicts, and always note existing values before editing anything as the simplest possible rollback plan.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.