<p><strong>Short answer:</strong> put the server after the name. <code>nslookup example.com 8.8.8.8</code> asks Google Public DNS instead of the resolver your computer normally uses, and <code>nslookup -type=mx example.com 1.1.1.1</code> does the same for a specific record type. With dig the server comes first, after an @ sign: <code>dig @1.1.1.1 example.com MX</code>. In Windows PowerShell the equivalent is <code>Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1</code>. The rest of this guide covers which server to ask for which question, how to query a domain's own authoritative nameserver, and how to read what comes back.</p>

<h2>Why query a specific DNS server at all?</h2>
<p>By default nslookup and dig ask whatever resolver your operating system is configured with: usually your router, your ISP, a company DNS server or a VPN's resolver. That resolver caches each answer for as long as the record's TTL allows. So right after you change a record, your default resolver may still hand out the old value, and a plain lookup tells you about that cache rather than about your DNS zone.</p>
<p>Sending the query to a server you choose answers three different questions:</p>
<ul>
<li><strong>Is my local resolver the problem?</strong> Compare your default resolver with a public one. If 8.8.8.8 returns the new value and your router does not, the change is live and you are looking at a stale cache.</li>
<li><strong>What does the source of truth say?</strong> Ask the domain's authoritative nameserver. Its answer is what every resolver will see once the old cached copies expire.</li>
<li><strong>What do people on other networks see?</strong> Public resolvers fill their caches at different moments, which is most of what people mean by <a href="/blog/dns-propagation-explained">DNS propagation</a>.</li>
</ul>

<h2>nslookup: the server goes last</h2>
<p>nslookup ships with Windows, macOS and most Linux distributions. In one-line (non-interactive) mode the pattern is <code>nslookup [options] name [server]</code>:</p>
<pre><code>nslookup example.com 8.8.8.8
nslookup -type=mx example.com 1.1.1.1
nslookup -type=ns example.com 9.9.9.9
nslookup -type=txt example.com 8.8.4.4</code></pre>
<p>This is the first command as we ran it on 22 October 2026:</p>
<pre><code>Server:    8.8.8.8
Address:   8.8.8.8#53

Non-authoritative answer:
Name:      example.com
Address:   172.66.147.243
Name:      example.com
Address:   104.20.23.154</code></pre>
<p>The <strong>Server</strong> line confirms who answered. If it shows your router's address instead of the one you typed, the server argument was not picked up, and the usual cause is putting the server before the name. Windows prints the resolver's hostname above its address and shows <em>UnKnown</em> when that resolver has no <a href="/blog/reverse-dns-lookup-uses">reverse DNS</a> name. That is cosmetic; the lookup still worked.</p>
<p><strong>Non-authoritative answer</strong> means the reply came from a recursive resolver (from its cache or from a lookup it made on your behalf), not from a nameserver that hosts the zone. For public resolvers that is normal, not an error.</p>

<h3>Interactive mode: switch servers mid-session</h3>
<p>Run <code>nslookup</code> on its own to get a <code>&gt;</code> prompt. <code>server 1.1.1.1</code> changes the server for every query that follows, and <code>set type=</code> changes the record type:</p>
<pre><code>nslookup
&gt; server 1.1.1.1
&gt; set type=ns
&gt; example.com
&gt; set type=a
&gt; www.example.com
&gt; exit</code></pre>
<p>Microsoft's reference also lists <code>lserver</code>. It makes the same switch but looks up the new server's name using your original default server, which helps when the server you switch to cannot resolve names for you, such as an authoritative-only nameserver.</p>

<h3>nslookup options worth knowing</h3>
<table>
<thead><tr><th>Option</th><th>What it does</th></tr></thead>
<tbody>
<tr><td><code>-type=mx</code> (or <code>-query=mx</code>)</td><td>Record type to ask for: a, aaaa, mx, ns, txt, cname, soa, ptr</td></tr>
<tr><td><code>-port=5353</code></td><td>Query a server listening on a non-standard port</td></tr>
<tr><td><code>-timeout=10</code></td><td>Seconds to wait for a reply before retrying</td></tr>
<tr><td><code>-vc</code></td><td>Use TCP instead of UDP, useful when a firewall drops large UDP replies</td></tr>
<tr><td><code>-debug</code></td><td>Print the full response, including each record's TTL</td></tr>
</tbody>
</table>

<h2>dig: the server goes first, after @</h2>
<p>dig is the tool most DNS engineers reach for, because it prints the whole DNS response, flags and TTLs included. It is preinstalled on macOS. On Debian and Ubuntu it comes in the <code>dnsutils</code> package (<code>bind9-dnsutils</code> on newer releases), and on Fedora and RHEL in <code>bind-utils</code>. The pattern is <code>dig @server name type</code>:</p>
<pre><code>dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com MX +short
dig @9.9.9.9 example.com TXT
dig @2606:4700:4700::1111 example.com AAAA</code></pre>
<p><code>+short</code> prints only the values. Leave it off when you need the detail. The header shows the status (NOERROR, NXDOMAIN, SERVFAIL) and the footer names the server that replied and how long it took:</p>
<pre><code>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; Query time: 17 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)</code></pre>
<p>The flags tell you what kind of server answered. <code>ra</code> (recursion available) marks a resolver, <code>aa</code> (authoritative answer) marks a server that hosts the zone, and <code>ad</code> means the resolver validated the answer with <a href="/blog/dns-security-dnssec-explained">DNSSEC</a>.</p>

<h2>Ask the authoritative nameserver directly</h2>
<p>This check settles most "did my change work?" questions, because it skips every cache. It takes two steps: find the domain's nameservers, then query one of them.</p>
<pre><code>dig example.com NS +short
elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.

dig @elliott.ns.cloudflare.com example.com A +norecurse</code></pre>
<p>In our test the reply carried the <code>aa</code> flag and a TTL of 300 seconds on each A record. That TTL is the longest a resolver should keep serving the old value after a change. The nslookup version is <code>nslookup -type=ns example.com</code> followed by <code>nslookup example.com elliott.ns.cloudflare.com</code>, and the answer is no longer labelled non-authoritative.</p>
<p>If the nameserver replies <strong>REFUSED</strong> or hands you a referral instead of an answer, you asked a server that does not host that zone, so re-check the NS list. When you are moving to a new DNS host, query the new provider's nameservers directly <em>before</em> you switch, so you know the zone is complete. Our <a href="/nameserver-lookup">nameserver lookup</a> shows which nameservers a domain delegates to right now, and <a href="/blog/how-to-check-domain-nameservers">this guide</a> explains the registry side of that check.</p>

<h2>Which server to pick</h2>
<table>
<thead><tr><th>Server</th><th>Address</th><th>Use it to</th></tr></thead>
<tbody>
<tr><td>Google Public DNS</td><td>8.8.8.8, 8.8.4.4</td><td>Compare with a large public cache</td></tr>
<tr><td>Cloudflare</td><td>1.1.1.1, 1.0.0.1</td><td>Get a second, independent cache</td></tr>
<tr><td>Quad9</td><td>9.9.9.9</td><td>Get a third opinion; it also blocks known malicious domains, so a block there is not proof of a DNS fault</td></tr>
<tr><td>The domain's own nameserver</td><td>From the NS lookup</td><td>See the current value with no cache involved</td></tr>
<tr><td>Your router or company DNS</td><td>Shown by a plain <code>nslookup</code></td><td>See exactly what your own devices receive</td></tr>
</tbody>
</table>

<h2>Windows PowerShell: Resolve-DnsName</h2>
<p>On Windows, Resolve-DnsName returns objects you can filter and pipe, which suits scripts and repeated checks:</p>
<pre><code>Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1
Resolve-DnsName -Name example.com -Type A -Server elliott.ns.cloudflare.com -DnsOnly</code></pre>
<p><code>-Server</code> takes one or more DNS servers. <code>-DnsOnly</code> stops Windows from also trying LLMNR or NetBIOS, <code>-NoHostsFile</code> ignores the local hosts file, and <code>-CacheOnly</code> shows only what the Windows DNS client cache already holds, a quick way to see whether your PC is still keeping an old answer.</p>

<h2>When the query fails</h2>
<ul>
<li><strong>Timed out, or "no servers could be reached":</strong> many office, hotel and some mobile networks block outbound DNS on port 53 to anything except their own resolver. Try another network, or use our <a href="/dns-lookup">online DNS lookup</a>, which queries from outside your network.</li>
<li><strong>REFUSED:</strong> the server will not answer recursive questions from you, or it is an authoritative server that does not host that zone.</li>
<li><strong>NXDOMAIN:</strong> that server says the name does not exist. If only one resolver says so, it may be holding a cached negative answer, which lasts as long as the zone's SOA negative-caching TTL (RFC 2308). Browser errors caused by this are covered in <a href="/blog/how-to-fix-dns-probe-finished-nxdomain">our NXDOMAIN fix guide</a>.</li>
<li><strong>SERVFAIL:</strong> the resolver could not get a usable answer, often because of a DNSSEC validation failure or unreachable nameservers. Run the query again with <code>dig +cd</code> (checking disabled); if an answer appears, DNSSEC is the likely cause. More fixes are in <a href="/blog/common-dns-errors-and-fixes">common DNS errors</a>.</li>
<li><strong>Different answers from different public resolvers:</strong> usually caching after a recent change, so wait for the old TTL to run out. Some domains also answer differently by location on purpose, which is how <a href="/blog/how-cdn-and-dns-work-together">CDNs use DNS</a>.</li>
</ul>

<h2>FAQ</h2>
<h3>Does the order of arguments matter in nslookup?</h3>
<p>Yes. Options come first, then the name, then the server: <code>nslookup -type=txt example.com 8.8.8.8</code>. Swap them and nslookup does a reverse lookup of the IP address while trying to use the domain name as the DNS server, which usually ends in a timeout.</p>
<h3>Can I give a server name instead of an IP address?</h3>
<p>Yes. <code>nslookup example.com dns.google</code> and <code>dig @one.one.one.one example.com</code> both work. The tool first resolves the server's name through your default resolver, so an IP address is more reliable when your default resolver is the thing you suspect.</p>
<h3>dig shows the new IP, so why does my browser still load the old site?</h3>
<p>Your operating system and browser keep their own short caches. Flush the OS cache with <code>ipconfig /flushdns</code> on Windows or <code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder</code> on macOS, then restart the browser.</p>

<p><em>Sources: Microsoft Learn, "nslookup" command reference and its server and lserver subcommands; Microsoft Learn, "Resolve-DnsName" (DnsClient module); BIND 9 manual pages (dig); RFC 1034 and RFC 1035 (DNS concepts and message format); RFC 2308 (negative caching). Example output from live queries run 22 October 2026 on macOS with DiG 9.10.6 and the system nslookup. Results for example.com, the domain reserved for documentation, will change over time.</em></p>

Use nslookup example.com 8.8.8.8 or dig @1.1.1.1 to query a specific DNS server, ask the authoritative nameserver, and read REFUSED, NXDOMAIN and SERVFAIL.

How to Query a Specific DNS Server With nslookup (and dig)

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

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

How to Query a Specific DNS Server With nslookup (and dig)

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

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