<p><strong>Short answer:</strong> if Google Workspace is the only service that sends email for your domain, publish one TXT record on the root domain (host <code>@</code>) with the value <code>v=spf1 include:_spf.google.com ~all</code>. That is the exact value in Google's own setup guide. If anything else also sends mail as your domain, such as a newsletter tool, a help desk or your website's contact form, you do not add a second SPF record. You merge every sender into that one record. This guide shows the exact syntax, how to merge it with other services without breaking the 10-lookup limit, and how to confirm that Gmail actually sees <code>spf=pass</code>.</p>

<h2>The exact record to add</h2>
<p>At the company that hosts your DNS (the provider your <a href="/blog/how-to-check-domain-nameservers">nameservers</a> point to, which is not always your registrar), create this record:</p>
<table>
<thead><tr><th>Field</th><th>Value</th></tr></thead>
<tbody>
<tr><td>Type</td><td>TXT</td></tr>
<tr><td>Host / Name</td><td><code>@</code> (the root domain; some panels want the bare domain name or leave it blank)</td></tr>
<tr><td>Value</td><td><code>v=spf1 include:_spf.google.com ~all</code></td></tr>
<tr><td>TTL</td><td>Default, or 3600 seconds</td></tr>
</tbody>
</table>
<p>Read it left to right: <code>v=spf1</code> says this is an SPF policy, <code>include:_spf.google.com</code> authorises the servers Google publishes for Workspace mail, and <code>~all</code> asks receivers to treat mail from any other server as a soft fail, which usually means extra scrutiny or the spam folder rather than an outright rejection. Some DNS panels add the surrounding quotation marks for you and some expect you to type them, so check how existing TXT records in the same panel look before saving.</p>
<p>Google notes two cases where you may not need to do anything: domains that already have SPF set up by default, and domains bought from a Google partner during Workspace sign-up. Check first with a TXT lookup, because adding a second record on top of an existing one is the most common way to break SPF.</p>

<h2>~all or -all for Google Workspace?</h2>
<p>Google's setup guide recommends <code>~all</code>. Hard fail (<code>-all</code>) tells receivers to reject anything not listed, which sounds stricter and better, but it punishes you for every sender you forgot: an invoicing tool, a CRM, a printer that emails scans. In practice the policy that stops spoofing is DMARC, which looks at SPF and DKIM together and lets you move from monitoring to rejection with reports to guide you. Keep SPF at <code>~all</code>, add DKIM and DMARC, and let DMARC do the enforcing. Our <a href="/blog/spf-dkim-dmarc-setup-guide">SPF, DKIM and DMARC setup guide</a> covers that rollout.</p>

<h2>Merging Google Workspace with other senders</h2>
<p>A domain may publish only one SPF record. RFC 7208 says that if a receiver finds more than one record starting with <code>v=spf1</code>, the result is a permanent error, so the check fails for every message, including genuine Workspace mail. When you add a service, edit the existing record and insert its mechanism before the <code>all</code> at the end. Google's help page lists ready-made combinations; these are the most common:</p>
<ul>
<li><strong>Workspace + Microsoft 365:</strong> <code>v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all</code></li>
<li><strong>Workspace + Mailchimp:</strong> <code>v=spf1 include:_spf.google.com include:servers.mcsv.net ~all</code></li>
<li><strong>Workspace + Amazon SES:</strong> <code>v=spf1 include:_spf.google.com include:amazonses.com ~all</code></li>
<li><strong>Workspace + Zendesk:</strong> <code>v=spf1 include:_spf.google.com include:mail.zendesk.com ~all</code></li>
<li><strong>Workspace + your own server:</strong> <code>v=spf1 include:_spf.google.com ip4:192.0.2.25 ~all</code>, using the server's real public IP in place of the documentation address.</li>
</ul>
<p>Always copy the include value from the sending service's current documentation rather than from an old blog post, because providers do change them. One example from our own checks on 21 October 2026: <code>shops.shopify.com</code>, still listed in many guides, published only <code>v=spf1 ~all</code>, meaning it authorised no servers at all. Including it costs you a lookup and adds nothing. Services that send from their own return-path domain, as many newsletter and store platforms now do, often need a DKIM or CNAME record from you rather than an SPF include.</p>

<h2>Stay under the 10 DNS lookup limit</h2>
<p>RFC 7208 caps an SPF evaluation at 10 mechanisms that need extra DNS queries: <code>include</code>, <code>a</code>, <code>mx</code>, <code>ptr</code>, <code>exists</code> and the <code>redirect</code> modifier. Includes inside includes count too. Plain <code>ip4</code> and <code>ip6</code> entries cost nothing. Go over 10 and the result is a permanent error, which looks the same to Gmail as having no valid SPF at all.</p>
<p>Here is what common includes cost, based on the records each one published when we queried them on 21 October 2026:</p>
<table>
<thead><tr><th>Include</th><th>Lookups used</th><th>Why</th></tr></thead>
<tbody>
<tr><td><code>_spf.google.com</code></td><td>1</td><td>A flat list of Google IPv4 and IPv6 ranges, no nested includes</td></tr>
<tr><td><code>spf.protection.outlook.com</code></td><td>1</td><td>Flat list of Microsoft ranges</td></tr>
<tr><td><code>servers.mcsv.net</code></td><td>1</td><td>Three Mailchimp IPv4 ranges</td></tr>
<tr><td><code>amazonses.com</code></td><td>1</td><td>Flat list of SES ranges</td></tr>
<tr><td><code>sendgrid.net</code></td><td>2</td><td>Nests <code>include:ab.sendgrid.net</code></td></tr>
<tr><td><code>_spf.salesforce.com</code></td><td>2</td><td>Uses an <code>exists</code> mechanism</td></tr>
<tr><td><code>secureserver.net</code></td><td>2 or more</td><td>Nests a further GoDaddy include</td></tr>
</tbody>
</table>
<p>So Workspace plus two or three typical services is nowhere near the limit. Trouble starts when a record collects years of trials: an <code>a</code> and an <code>mx</code> mechanism nobody needs any more (with Workspace, <code>mx</code> points at Google's inbound mail servers and authorises nothing you need), plus includes for tools you cancelled. Remove what you no longer use before trying tricks such as SPF flattening services, which swap includes for IP lists that silently go stale when the provider changes ranges.</p>

<h2>Mistakes that break Google Workspace SPF</h2>
<ul>
<li><strong>A second record instead of a merged one.</strong> Typically your web host or old email provider left <code>v=spf1 a mx ~all</code> in place and you added the Google one beside it. Delete the old one after merging anything still needed into the new record.</li>
<li><strong>Outdated include values.</strong> Older tutorials used <code>include:aspmx.googlemail.com</code>, and some people try <code>include:gmail.com</code>. Use <code>include:_spf.google.com</code> as Google documents today.</li>
<li><strong>The record on the wrong host.</strong> SPF is checked on the domain in the envelope sender (the return path). For <code>you@example.com</code> that is <code>example.com</code>, so the record goes on <code>@</code>, not on <code>www</code> or <code>mail</code>. If you also send as <code>you@team.example.com</code>, that subdomain needs its own SPF record, because SPF is not inherited.</li>
<li><strong>Typing the domain into the host field.</strong> Some panels append the domain automatically, turning <code>example.com</code> into <code>example.com.example.com</code>. Look up the result to be sure.</li>
<li><strong>Using the old SPF record type.</strong> A few panels still offer a record type called SPF. RFC 7208 retired it; publish SPF as TXT only.</li>
<li><strong>Expecting SPF alone to fix spam placement.</strong> Since February 2024, Google requires SPF or DKIM for all senders to Gmail, and SPF, DKIM and DMARC for anyone sending more than 5,000 messages a day to Gmail accounts. Turn on DKIM in the Admin console as well.</li>
</ul>

<h2>How to check that it works</h2>
<p>First confirm the record is published and that there is exactly one. On macOS or Linux run <code>dig example.com TXT +short</code> and look for a single line starting with <code>v=spf1</code>, or use our <a href="/dns-lookup">DNS Lookup tool</a> and choose TXT. If you just changed the record and still see the old value, the previous answer is cached until its TTL runs out; our guide to <a href="/blog/dns-propagation-explained">DNS propagation</a> explains the wait, and Google says SPF can take up to 48 hours to start working.</p>
<p>Then test with a real message. Send an email from your Workspace account to a personal Gmail address, open it, choose <strong>Show original</strong> from the three-dot menu and read the summary at the top. You want <strong>SPF: PASS</strong> with your domain and Google's sending IP. <code>softfail</code> means the sending server is not in your record; <code>permerror</code> usually means two records or more than 10 lookups. If messages still land in spam once SPF passes, check DKIM and DMARC next and look at our guide to <a href="/blog/email-deliverability-and-dns-records">email deliverability and DNS records</a>. It is also worth checking the sending IP against public block lists with our <a href="/blacklist-checker">Blacklist Checker</a>.</p>

<h2>FAQ</h2>
<h3>Do I need an SPF record if I only receive email with Google Workspace?</h3>
<p>Receiving mail depends on your <a href="/blog/how-to-set-up-mx-records-for-email">MX records</a>, not SPF. You still want SPF the moment anyone sends from the domain, and without it others can more easily send mail that pretends to be you. If a domain never sends mail at all, publish <code>v=spf1 -all</code> on it instead.</p>
<h3>Can I have one SPF record for Google and another for Microsoft 365?</h3>
<p>No. Two SPF records on the same name is a permanent error under RFC 7208. Combine them: <code>v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all</code>.</p>
<h3>Does the order of includes matter?</h3>
<p>Not for the result. Receivers stop at the first mechanism that matches, so putting your main sender first can save a query or two, but the pass or fail outcome is the same. What matters is that <code>~all</code> stays at the very end, because anything after it is ignored.</p>

<p><em>Sources: Google Workspace Admin Help "Set up SPF" (checked 21 October 2026) and "Email sender guidelines"; RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1; live TXT lookups of each listed include on 21 October 2026. Example addresses use the reserved documentation range 192.0.2.0/24 and the example.com domain.</em></p>

The SPF record for Google Workspace is v=spf1 include:_spf.google.com ~all. Where to add it, how to merge other senders, the 10-lookup limit and how to test it.

SPF Record for Google Workspace: The Exact Value and How to Merge It

<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.

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

SPF Record for Google Workspace: The Exact Value and How to Merge It

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

How to Check What Nameservers a Domain Is Using