<p><strong>Short answer:</strong> a website needs surprisingly few DNS records to work. At minimum you need working <strong>nameservers</strong> (set at your registrar), an <strong>A record</strong> for the root domain that points to your web server's IPv4 address, and a record for <strong>www</strong>, usually a CNAME or a second A record. Add an <strong>AAAA record</strong> if your host supports IPv6. Everything else depends on what the domain does: email needs <strong>MX, SPF, DKIM and DMARC</strong>, and a few optional records such as <strong>CAA</strong> and verification <strong>TXT</strong> records harden or extend the setup. This guide walks through each record, shows a complete minimal zone you can adapt, and lists the mistakes that most often break a new site.</p>

<h2>The minimum set at a glance</h2>
<ul>
<li><strong>Required:</strong> NS delegation, SOA (created by your DNS host), and an A record (or ALIAS/flattened record) on the root domain.</li>
<li><strong>Strongly recommended:</strong> a www record, plus AAAA if the server really answers on IPv6.</li>
<li><strong>Only for email:</strong> MX, SPF, DKIM and DMARC, or a "no mail" set if the domain never sends email.</li>
<li><strong>Optional:</strong> CAA, verification TXT records and DNSSEC.</li>
</ul>

<h2>1. Nameservers: the record that makes everything else visible</h2>
<p>None of your other records matter until the domain is delegated to a DNS provider. You set nameservers at your registrar, and the registry for the TLD publishes them as NS records in the parent zone. Your DNS provider publishes matching NS records inside your own zone. If the two lists disagree, some resolvers will see your records and others will not, which is one of the hardest problems to debug.</p>
<p>Use at least two nameservers. RFC 1034 requires every zone to be available on at least two servers, and most providers assign two to four. You can confirm what the world currently sees with our <a href="/nameserver-lookup">Nameserver Lookup tool</a>, or follow our guide on <a href="/blog/how-to-check-domain-nameservers">how to check what nameservers a domain is using</a>. If you need to move the domain to a new DNS host first, see <a href="/blog/how-to-change-nameservers-step-by-step">how to change nameservers</a>.</p>

<h2>2. SOA: created for you, worth understanding</h2>
<p>Every zone has one SOA (Start of Authority) record naming the primary nameserver, a contact mailbox, a serial number and several timers. Managed DNS providers maintain it for you. One detail is worth knowing: the last SOA value helps set how long resolvers cache a "this name does not exist" answer (RFC 2308), which is why a brand-new subdomain that someone looked up too early can seem slow to appear.</p>

<h2>3. A and AAAA records for the root domain</h2>
<p>The A record maps your bare domain to an IPv4 address, for example <code>example.com. A 192.0.2.10</code>. Your hosting provider gives you this address. Some platforms give you several addresses for redundancy, in which case you add one A record per address.</p>
<p>The AAAA record does the same for IPv6. Add it only when your host confirms the site is reachable over IPv6. A wrong or stale AAAA record is worse than none: devices on IPv6-capable networks may try it first and then stall or fail to connect, while IPv4-only testers see nothing wrong. Our <a href="/blog/ipv6-dns-configuration-guide">IPv6 DNS configuration guide</a> covers how to test both paths.</p>

<h2>4. The www record, and why the root cannot be a CNAME</h2>
<p>For <code>www</code> the usual choice is a CNAME pointing to the root domain or to a hostname your platform gives you, such as a CDN or site-builder target. A CNAME means "this name is an alias; look up that other name instead", so when the host changes its IP addresses you do not have to touch anything.</p>
<p>The root domain is different. A CNAME cannot coexist with any other record at the same name (RFC 1912, section 2.4), and the root always carries SOA and NS records, so a plain CNAME is not allowed there. If your platform asks you to point the root at a hostname, use your DNS provider's workaround: <strong>CNAME flattening</strong>, <strong>ALIAS</strong> or <strong>ANAME</strong> records. These resolve the target behind the scenes and answer with ordinary A and AAAA records. Cloudflare, for example, documents CNAME flattening as the feature that lets you use a CNAME at the zone apex. Our comparison of <a href="/blog/a-record-vs-cname-when-to-use-which">A records and CNAMEs</a> explains the trade-offs in more detail.</p>
<p>DNS does not redirect visitors. Pointing both names at the same server only makes both reachable; sending one to the other is an HTTP 301 redirect on the server or CDN.</p>

<h2>5. Email records: only if the domain handles mail</h2>
<p>If you use the domain for email, four records do the work:</p>
<ul>
<li><strong>MX</strong> tells other servers where to deliver mail for your domain. Your email provider gives you the exact values. For Google Workspace, for instance, the MX value is <code>smtp.google.com</code>. See our guide to <a href="/blog/how-to-set-up-mx-records-for-email">setting up MX records</a>.</li>
<li><strong>SPF</strong> is a TXT record on the root domain listing which servers may send mail as you, such as <code>v=spf1 include:_spf.google.com ~all</code>. Publish exactly one SPF record per name. Two separate SPF records cause a permanent error under RFC 7208, so merge all your senders into one.</li>
<li><strong>DKIM</strong> is a TXT (or CNAME) record at a selector name such as <code>google._domainkey.example.com</code>, holding the public key your provider generates.</li>
<li><strong>DMARC</strong> is a TXT record at <code>_dmarc.example.com</code>, for example <code>v=DMARC1; p=none; rua=mailto:dmarc@example.com</code>. Start with <code>p=none</code> to collect reports, then move to <code>quarantine</code> or <code>reject</code> once your legitimate mail passes.</li>
</ul>
<p>For anyone sending to Gmail these are not optional: Google's sender guidelines require every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts need SPF, DKIM and DMARC. Our <a href="/blog/spf-dkim-dmarc-setup-guide">SPF, DKIM and DMARC setup guide</a> walks through each record step by step.</p>

<h2>6. If the domain never sends email, say so</h2>
<p>Domains used only for a website are popular targets for spoofing, because nothing stops someone from forging their address. Three small records close the gap:</p>
<pre>example.com.         MX   0 .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject"</pre>
<p>The first is a "null MX" (RFC 7505), which announces that the domain accepts no mail, so senders stop trying to deliver to your web server's address. The SPF record says no server may send as you, and the DMARC policy tells receivers to reject mail that claims otherwise.</p>

<h2>7. Optional records worth adding</h2>
<ul>
<li><strong>CAA</strong> lists which certificate authorities may issue SSL certificates for your domain (RFC 8659), for example <code>example.com. CAA 0 issue "letsencrypt.org"</code>. Check which CA your host or CDN uses first: a CAA record that leaves it out will block automatic certificate renewal. You can verify your certificate afterwards with our <a href="/ssl-checker">SSL Checker</a>.</li>
<li><strong>Verification TXT records</strong> prove domain ownership to services such as Google Search Console or an email provider. They are harmless to keep while the service is in use.</li>
<li><strong>DNSSEC</strong> signs your zone so resolvers can detect forged answers. It needs a DS record at the registrar, so enable it only when both your DNS host and registrar support it. See <a href="/blog/dns-security-dnssec-explained">DNSSEC explained</a>.</li>
</ul>

<h2>A complete minimal zone you can adapt</h2>
<p>Here is what a small business site with Google Workspace email typically needs, using documentation-only addresses (replace them with your own values):</p>
<pre>example.com.         NS     ns1.dnsprovider.example.
example.com.         NS     ns2.dnsprovider.example.
example.com.         A      192.0.2.10
example.com.         AAAA   2001:db8::10
www.example.com.     CNAME  example.com.
example.com.         MX     1 smtp.google.com.
example.com.         TXT    "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=(your key)"
_dmarc.example.com.  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
example.com.         CAA    0 issue "letsencrypt.org"</pre>
<p>The SOA record is not shown because your DNS host manages it. Drop the AAAA line if your server has no IPv6, and drop the CAA line if you are unsure which CA your host uses.</p>

<h2>Records most websites do not need</h2>
<p><strong>PTR (reverse DNS)</strong> records live in the zone of whoever owns the IP address, usually your hosting provider, and matter for mail servers rather than websites (see our <a href="/blog/reverse-dns-lookup-uses">reverse DNS guide</a>). <strong>SRV</strong> records are needed only when a service such as a VoIP or chat system asks for them, and <strong>wildcard</strong> records (<code>*.example.com</code>) should be added only on purpose, because they make every mistyped subdomain resolve.</p>

<h2>How to check your records and avoid common mistakes</h2>
<p>After saving your records, look them up from outside your own network. On macOS or Linux, <code>dig example.com A +short</code>, <code>dig www.example.com +short</code> and <code>dig example.com MX +short</code> show the live answers, or use our <a href="/dns-lookup">DNS Lookup tool</a> to check each record type in the browser. The mistakes we see most often:</p>
<ul>
<li>Adding a CNAME on the root domain, which many DNS hosts reject and which breaks MX and TXT records where it is accepted.</li>
<li>Two SPF records after adding a second email service, instead of one merged record.</li>
<li>An old A record left behind after moving hosts, so some visitors still reach the previous server.</li>
<li>Forgetting the www record, so <code>www.example.com</code> fails while the bare domain works.</li>
<li>Making changes with a long TTL. Lower the TTL to around 300 seconds a day before a planned move, then raise it again once things are stable. Our article on <a href="/blog/dns-propagation-explained">DNS propagation</a> explains why changes take time, and <a href="/blog/common-dns-errors-and-fixes">common DNS errors and fixes</a> helps if something still fails.</li>
</ul>

<h2>FAQ</h2>
<h3>Does a website need an MX record?</h3>
<p>No. A website loads without one. You need MX only to receive email at the domain. If you do not use email there, publishing a null MX is better than leaving it empty, because senders then stop trying to deliver to your web server.</p>
<h3>Where do I add these records?</h3>
<p>At whichever company your nameservers point to. That is often your registrar, but if you moved DNS to a host or CDN such as Cloudflare, records added at the registrar are ignored. Check your nameservers first so you know which dashboard is live.</p>

<p><em>Sources: RFC 1034 (Domain Names: Concepts and Facilities), RFC 1912 (Common DNS Operational and Configuration Errors), RFC 2308 (Negative Caching of DNS Queries), RFC 7208 (SPF), RFC 7505 (Null MX), RFC 8659 (CAA); Google Workspace Help "Set up MX records for Google Workspace" and "Email sender guidelines"; Let's Encrypt documentation on CAA; Cloudflare documentation on CNAME flattening. Example values use the reserved documentation ranges 192.0.2.0/24 and 2001:db8::/32.</em></p>

What DNS records does a website need? The minimum set (NS, A, www), when to add AAAA, the email records (MX, SPF, DKIM, DMARC) and optional CAA, with an example zone.

What DNS Records Does a Website Need? The Minimum Set Explained

<p><strong>Short answer:</strong> the fastest way to see which nameservers a domain is using is to run <code>dig NS yourdomain.com +short</code> on macOS or Linux, <code>nslookup -type=NS yourdomain.com</code> on Windows, or paste the domain into our free <a href="/nameserver-lookup">Nameserver Lookup tool</a>. If you need the answer straight from the registry (for example, right after you changed nameservers at your registrar), query the TLD servers directly or check the WHOIS/RDAP record. The four methods below cover every situation, and the section on conflicting results explains why two tools can show different nameservers for the same domain.</p>

<h2>Two places nameservers are listed (and why it matters)</h2>
<p>Nameservers for a domain are published in two places, and most confusion comes from mixing them up:</p>
<ul>
<li><strong>The delegation at the registry (parent zone).</strong> When you set nameservers at your registrar, the registrar sends them to the registry for the TLD, such as Verisign for .com. The registry's servers then tell the rest of the internet where your domain's DNS lives. This is the list that actually controls where traffic goes.</li>
<li><strong>The NS records inside your own zone (child zone).</strong> Your DNS provider also publishes NS records in the zone it hosts. Normally they match the delegation exactly, but they do not have to. RFC 1034 expects the two sets to agree, and when they drift apart you get hard-to-debug problems.</li>
</ul>
<p>A normal lookup through a public resolver usually shows you the child zone's NS records (or a cached copy). A WHOIS check or a direct query to the TLD servers shows you the delegation. When you troubleshoot, check both.</p>

<h2>Method 1: Use an online nameserver checker</h2>
<p>If you only need a quick answer, use a web tool. Open the <a href="/nameserver-lookup">Nameserver Lookup</a> page, type the bare domain (for example <code>yourdomain.com</code>, without <code>https://</code> or <code>www</code>) and run the check. You will get the list of NS hostnames the domain currently resolves to.</p>
<p>This is the right method for support staff and site owners who are not comfortable with a terminal. Two tips:</p>
<ul>
<li>Always check the <strong>root domain</strong>. Subdomains such as <code>shop.yourdomain.com</code> usually have no NS records of their own unless they are delegated separately.</li>
<li>If the result looks wrong right after a change, it may be cached. Compare it with Method 4, which skips caches.</li>
</ul>

<h2>Method 2: Check nameservers from the command line</h2>
<h3>macOS and Linux: dig</h3>
<p><code>dig</code> is installed on macOS by default and is part of the <code>dnsutils</code> or <code>bind-utils</code> package on most Linux distributions.</p>
<pre><code>dig NS yourdomain.com +short</code></pre>
<p>The output is one nameserver per line, each ending in a dot, for example:</p>
<pre><code>ns1.exampledns.net.
ns2.exampledns.net.</code></pre>
<p>Drop <code>+short</code> to see the full answer, including the TTL (how many seconds resolvers may cache the result). To ask a specific public resolver instead of your local one, add it with <code>@</code>:</p>
<pre><code>dig NS yourdomain.com @1.1.1.1 +short
dig NS yourdomain.com @8.8.8.8 +short</code></pre>
<h3>Windows: nslookup or PowerShell</h3>
<p>In Command Prompt:</p>
<pre><code>nslookup -type=NS yourdomain.com</code></pre>
<p>Look for lines that read <code>nameserver = ...</code>. The "Non-authoritative answer" label only means the reply came from a resolver's cache rather than from the domain's own nameservers. That is normal.</p>
<p>In PowerShell, the built-in <code>Resolve-DnsName</code> cmdlet gives cleaner output:</p>
<pre><code>Resolve-DnsName -Name yourdomain.com -Type NS</code></pre>
<p>The <code>NameHost</code> column lists the nameservers.</p>

<h2>Method 3: Look up the WHOIS or RDAP record</h2>
<p>The registration record shows the nameservers your registrar has on file with the registry, which is the delegation described above. Use our <a href="/whois-lookup">WHOIS Lookup</a>, ICANN's official lookup service at lookup.icann.org (RDAP), or the terminal:</p>
<pre><code>whois yourdomain.com | grep -i "name server"</code></pre>
<p>You should see lines such as <code>Name Server: NS1.EXAMPLEDNS.NET</code>. Uppercase is normal, because DNS names are not case-sensitive. WHOIS is especially useful when the domain does not resolve at all, because it still shows which nameservers the registry has been told to use. Some country-code TLDs publish limited WHOIS data. If the nameserver lines are missing, use Method 4.</p>

<h2>Method 4: Ask the TLD servers directly (no caching)</h2>
<p>This is the method professionals use right after a nameserver change, because it reads the delegation straight from the registry instead of from any resolver cache. For .com and .net domains, Verisign's servers are named <code>a.gtld-servers.net</code> through <code>m.gtld-servers.net</code>:</p>
<pre><code>dig NS yourdomain.com @a.gtld-servers.net +norecurse</code></pre>
<p>The nameservers appear in the <strong>AUTHORITY SECTION</strong> of the output (not the ANSWER section), because the TLD server is referring you onward rather than answering for your zone. For any other TLD, first find its servers, then query one of them:</p>
<pre><code>dig NS org +short
dig NS yourdomain.org @&lt;one of the servers listed&gt; +norecurse</code></pre>
<p>Or let <code>dig</code> walk the entire chain from the root servers down, which shows every referral on the way:</p>
<pre><code>dig +trace NS yourdomain.com</code></pre>

<h2>How to read the result: which DNS provider is it?</h2>
<p>Nameserver hostnames usually reveal who hosts the DNS zone, which tells you where to edit records:</p>
<ul>
<li><strong>Cloudflare:</strong> two names in the form <code>name.ns.cloudflare.com</code></li>
<li><strong>Amazon Route 53:</strong> four names like <code>ns-123.awsdns-45.com</code> spread across .com, .net, .org and .co.uk</li>
<li><strong>Google Cloud DNS:</strong> names like <code>ns-cloud-a1.googledomains.com</code></li>
<li><strong>GoDaddy:</strong> names like <code>ns01.domaincontrol.com</code></li>
<li><strong>Namecheap (default DNS):</strong> <code>dns1.registrar-servers.com</code> and <code>dns2.registrar-servers.com</code></li>
</ul>
<p>If you see your web host's own hostnames, such as <code>ns1.yourhost.com</code>, then DNS records are managed in that host's control panel. Edits made at your registrar will have no effect until the nameservers point back there. Our <a href="/blog/how-to-change-nameservers-step-by-step">step-by-step guide to changing nameservers</a> covers the switch itself.</p>

<h2>Why different tools show different nameservers</h2>
<p>If two checks disagree, it is almost always one of these four causes:</p>
<ol>
<li><strong>A recent change is still cached.</strong> The .com registry publishes NS delegations with a TTL of 172,800 seconds (48 hours), so some resolvers can keep showing the old nameservers for up to two days. Method 4 shows the new value immediately. See <a href="/blog/dns-propagation-explained">DNS propagation explained</a> for what is happening in between.</li>
<li><strong>The registrar and the zone disagree.</strong> WHOIS shows one set and <code>dig NS</code> shows another. Fix the registrar setting if it is wrong, or update the NS records inside the zone so they match the delegation.</li>
<li><strong>One listed nameserver is not authoritative (a "lame delegation").</strong> Test each server on its own with <code>dig yourdomain.com SOA @ns1.exampledns.net</code>. A server that returns REFUSED or SERVFAIL, or does not answer, has not been set up for your zone.</li>
<li><strong>DNSSEC is broken after a move.</strong> If you changed DNS providers but left the old DS record at the registrar, validating resolvers return SERVFAIL even though the nameservers look right. Remove or update the DS record. Our <a href="/blog/dns-security-dnssec-explained">DNSSEC explainer</a> shows how the chain of trust works.</li>
</ol>

<h2>A 60-second troubleshooting checklist</h2>
<ol>
<li>Run <code>whois yourdomain.com | grep -i "name server"</code> and note the delegated nameservers.</li>
<li>Run <code>dig NS yourdomain.com @a.gtld-servers.net +norecurse</code> (or the matching TLD server) and confirm the registry list matches.</li>
<li>Run <code>dig NS yourdomain.com @1.1.1.1 +short</code> and compare it with what resolvers see.</li>
<li>Query each nameserver directly for the SOA record to confirm that it answers authoritatively.</li>
<li>Then check the records you actually care about, such as A, MX or TXT, with the <a href="/dns-lookup">DNS Lookup tool</a>. For common error messages, see <a href="/blog/common-dns-errors-and-fixes">common DNS errors and how to fix them</a>.</li>
</ol>

<h2>FAQ</h2>
<h3>Can I find a domain's nameservers without access to the account?</h3>
<p>Yes. Nameservers are public by design. Anyone can see them with any of the methods above, and no login is needed. What you cannot see publicly is which registrar account controls the domain.</p>
<h3>How many nameservers should a domain have?</h3>
<p>At least two, and ideally on separate networks, so the domain keeps resolving if one server fails. Most managed DNS providers assign two to four.</p>
<h3>Do subdomains have their own nameservers?</h3>
<p>Only if they have been delegated on purpose with NS records in the parent zone. Otherwise a subdomain uses the root domain's nameservers, and checking <code>NS</code> for it returns nothing useful. New to the basics? Start with <a href="/blog/what-are-nameservers-and-how-they-work">what nameservers are and how they work</a>.</p>

<p><em>Sources: RFC 1034 (Domain Names: Concepts and Facilities), ICANN Registration Data Lookup (lookup.icann.org), Microsoft Learn documentation for Resolve-DnsName, and the providers' own published nameserver naming. Command output above uses placeholder names. Run the commands against your own domain to see real values.</em></p>

How to check what nameservers a domain is using: dig, nslookup, PowerShell, WHOIS/RDAP and direct TLD queries, plus how to read and fix conflicting results.

How to Check What Nameservers a Domain Is Using

<p>Every time you type a website address into your browser, a remarkable process kicks off behind the scenes. That process starts with <strong>nameservers</strong> — the fundamental building blocks of the Domain Name System (DNS).</p>

<h2>What Is a Nameserver?</h2>
<p>A nameserver is a specialized server that stores DNS records for a domain and responds to queries about those records. Think of it as a phone book for the internet: when someone asks "where is example.com?", the nameserver answers with the correct IP address.</p>

<h2>How DNS Resolution Works</h2>
<p>When you visit a website, your browser doesn't immediately know where to find it. Here's the step-by-step process:</p>
<ol>
<li><strong>Browser cache check</strong> — Your browser first checks if it already knows the IP address from a recent visit.</li>
<li><strong>OS resolver</strong> — If not cached, the request goes to your operating system's DNS resolver.</li>
<li><strong>Recursive resolver</strong> — Your ISP's recursive resolver takes over. It starts the lookup process by querying the root nameservers.</li>
<li><strong>Root nameservers</strong> — These 13 root server clusters direct the query to the correct Top-Level Domain (TLD) nameserver (e.g., .com, .org).</li>
<li><strong>TLD nameservers</strong> — The TLD nameserver points to the authoritative nameserver for the specific domain.</li>
<li><strong>Authoritative nameserver</strong> — This server holds the actual DNS records and returns the IP address.</li>
</ol>

<h2>Types of Nameservers</h2>
<p>There are several types of nameservers, each playing a different role:</p>
<ul>
<li><strong>Root nameservers</strong> — The top of the DNS hierarchy. There are 13 root server addresses (labeled A through M), each operated by a different organization.</li>
<li><strong>TLD nameservers</strong> — Managed by domain registries, these handle queries for specific top-level domains like .com or .net.</li>
<li><strong>Authoritative nameservers</strong> — These are the nameservers you configure for your domain. They hold your DNS records (A, CNAME, MX, etc.).</li>
<li><strong>Recursive resolvers</strong> — Operated by ISPs or services like Google (8.8.8.8) and Cloudflare (1.1.1.1), these do the heavy lifting of querying the chain on your behalf.</li>
</ul>

<h2>Why Nameservers Matter</h2>
<p>Your choice of nameservers directly impacts your website's performance and reliability. Premium DNS providers like Cloudflare and AWS Route 53 offer faster response times, better uptime, and advanced features like DDoS protection and geographic routing.</p>

<p>When you register a domain, your registrar assigns default nameservers. You can change these to point to a different DNS provider — which is exactly what many site owners do to get better performance or more control over their DNS records.</p>

<h2>How to Find Your Nameservers</h2>
<p>You can look up nameservers for any domain using our <strong>Nameserver Lookup Tool</strong> at the top of this site. You can also use command-line tools:</p>
<pre><code>nslookup -type=NS example.com
dig NS example.com</code></pre>

<p>Understanding nameservers is the first step to taking control of your domain's DNS configuration. Whether you're setting up a new website or troubleshooting connectivity issues, knowing how nameservers work gives you the foundation to manage your online presence effectively.</p>

Learn what nameservers are, how DNS resolution works step by step, the different types of nameservers, and why they matter for your website performance.

Free DNS & Network Tools

All Tools

Nameserver Lookup

DNS Lookup

WHOIS Lookup

IP Lookup

SSL Checker

HTTP Headers

Speed Test

Domain Availability

Blacklist Checker

Email Validator

Latest Posts

What DNS Records Does a Website Need? The Minimum Set Explained

How to Check What Nameservers a Domain Is Using

What Are Nameservers and How Do They Work?

Stay in the loop