<p><strong>Short answer:</strong> ask a validating resolver and look at the flags. <code>dig +dnssec example.com A @1.1.1.1</code> prints a <code>flags:</code> line; if it contains <strong>ad</strong> (authenticated data), the answer passed DNSSEC validation all the way from the root. Then run <code>dig DS example.com @8.8.8.8</code>. A DS record in the parent zone is what turns a signed zone into a validating one. No DS means resolvers treat the domain as unsigned, however many signatures the zone itself publishes.</p>
<p>This guide walks through the four checks that tell you which of the three states a domain is in (secure, unsigned or broken), using real output from queries we ran on 23 October 2026. If you want the theory first, start with <a href="/blog/dns-security-dnssec-explained">DNSSEC explained</a> and come back for the commands.</p>

<h2>Signed is not the same as validating</h2>
<p>A domain owner can switch on DNSSEC at their DNS host and see signatures appear in the zone, yet nothing changes for visitors. Validation needs an unbroken chain: the root vouches for the TLD, the TLD vouches for your domain through a <strong>DS record</strong>, and the DS must match a key (DNSKEY) in your zone. The DS record is added at your registrar, not at your DNS host, and that hand-off is where most setups stall.</p>
<p>A recent example shows how common this is. Pakistan's <code>.pk</code> zone became DNSSEC-signed in early October 2026, and a scan of 158,561 <code>.pk</code> domains on 11 October found just one that validated end to end. Another 1,230 had signed their own zones but had no DS record in the parent, so validating resolvers treated them as unsigned (CircleID, 20 October 2026). We checked the TLD side ourselves: <code>dig DS pk @1.1.1.1</code> now returns key tag 34973 with the <code>ad</code> flag set.</p>

<h2>Check 1: ask a validating resolver for the ad flag</h2>
<p>Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9) all validate DNSSEC. Query one of them directly, so you are not relying on whatever resolver your router uses (our guide to <a href="/blog/nslookup-specific-dns-server">querying a specific DNS server</a> covers the syntax):</p>
<pre><code>dig +dnssec +multi cloudflare.com A @1.1.1.1</code></pre>
<p>Trimmed output from 23 October 2026:</p>
<pre><code>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 43914
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232

;; ANSWER SECTION:
cloudflare.com.  300 IN A 104.16.132.229
cloudflare.com.  300 IN A 104.16.133.229
cloudflare.com.  300 IN RRSIG A 13 2 300 (
                 20261024110238 20261022090238 34505 cloudflare.com.
                 D1e+XWcyXJxVe/OEi63SN47ac40/uoXre9t76UJMzGgO ... )</code></pre>
<p>Three things to read:</p>
<ul>
<li><strong>ad in the flags line:</strong> the resolver validated the answer. This is the single most useful signal.</li>
<li><strong>do in the EDNS line:</strong> the <code>+dnssec</code> option asked for DNSSEC records, so the RRSIG signature is included in the answer.</li>
<li><strong>The RRSIG line:</strong> algorithm 13 (ECDSA P-256 with SHA-256), then the expiry and inception timestamps (here 24 October 11:02 UTC and 22 October 09:02 UTC), then key tag 34505, the key that made the signature.</li>
</ul>
<p>Run the same query for <code>google.com</code> and the flags line reads <code>qr rd ra</code> with no <code>ad</code>. That is not an error. google.com simply does not use DNSSEC, and the answer resolves normally.</p>

<h2>Check 2: is there a DS record in the parent zone?</h2>
<pre><code>dig DS cloudflare.com @8.8.8.8 +noall +answer
cloudflare.com.  15878 IN DS 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9</code></pre>
<p>The four fields after <code>DS</code> are the key tag (2371), the algorithm (13), the digest type (2 = SHA-256) and the digest of the key. For an unsigned domain you get <code>status: NOERROR</code> with <code>ANSWER: 0</code> and only the TLD's SOA record in the authority section. That is what <code>dig DS google.com @8.8.8.8</code> returned for us.</p>
<p>The 15878 is the remaining cache time at Google's resolver. Ask the TLD server itself (<code>dig DS cloudflare.com @a.gtld-servers.net +norec</code>) and you see the full TTL, 86400 seconds, for a .com DS record. Remember that number: a wrong DS can stay in caches for a whole day.</p>

<h2>Check 3: does the zone's DNSKEY match the DS?</h2>
<pre><code>dig DNSKEY cloudflare.com @1.1.1.1 +noall +answer +multi
cloudflare.com. 644 IN DNSKEY 256 3 13 ( ... ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 34505
cloudflare.com. 644 IN DNSKEY 257 3 13 ( ... ) ; KSK; alg = ECDSAP256SHA256 ; key id = 2371</code></pre>
<p>Flag <strong>257</strong> marks the key-signing key (KSK) and <strong>256</strong> the zone-signing key (ZSK). The chain holds because the KSK's key id, 2371, equals the key tag in the DS record, and both use algorithm 13. The ZSK's id, 34505, matches the key tag in the RRSIG from check 1. If the DS key tag matches no DNSKEY in the zone, validating resolvers reject the domain.</p>

<h2>Check 4: ask the authoritative nameserver</h2>
<p>Find the nameservers (<a href="/blog/how-to-check-domain-nameservers">how to check a domain's nameservers</a>), then query one without recursion:</p>
<pre><code>dig cloudflare.com A @ns3.cloudflare.com +dnssec +norec
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1</code></pre>
<p>Here you want <strong>aa</strong> (authoritative answer) plus an RRSIG next to each record set. You will not see <code>ad</code>: authoritative servers serve signatures but do not validate them. If the RRSIG is missing here, the zone is not being signed. If it is present but the expiry timestamp is in the past, the signer has stopped refreshing it, and validating resolvers will start failing the domain.</p>


<h2>What the results mean</h2>
<table>
<thead><tr><th>What you see</th><th>State</th><th>Effect on visitors</th></tr></thead>
<tbody>
<tr><td>ad flag; DS key tag matches the KSK</td><td>Secure</td><td>Resolves; protected against spoofed answers</td></tr>
<tr><td>No DS, no DNSKEY</td><td>Unsigned (insecure)</td><td>Resolves normally, without DNSSEC protection</td></tr>
<tr><td>DNSKEY and RRSIG in the zone, no DS in the parent</td><td>Signed but not validating</td><td>Resolves normally, but validators treat it as unsigned</td></tr>
<tr><td>DS present, but no matching key or expired signatures</td><td>Bogus</td><td>SERVFAIL on every validating resolver</td></tr>
</tbody>
</table>
<p>The third row is the half-finished setup from the <code>.pk</code> scan: the fix is to add the DS record at the registrar. The fourth row is the dangerous one, because the domain goes dark for every user whose resolver validates.</p>

<h2>Is DNSSEC behind a SERVFAIL? Use +cd</h2>
<p><code>dnssec-failed.org</code> is a test domain that is broken on purpose. Here is what a validating resolver says about it:</p>
<pre><code>dig dnssec-failed.org A @1.1.1.1
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 59644
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; OPT=15: 00 09 ... ("..no SEP matching the DS found for dnssec-failed.org.")</code></pre>
<p>Now add <code>+cd</code> (checking disabled), which tells the resolver to skip validation:</p>
<pre><code>dig +cd dnssec-failed.org A @1.1.1.1
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 6398
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
dnssec-failed.org.  300  IN  A  96.99.227.255</code></pre>
<p>SERVFAIL normally, an answer with <code>+cd</code>: that combination means DNSSEC validation is the cause, not a dead nameserver. The <code>OPT=15</code> line is an Extended DNS Error (RFC 8914). The first bytes, <code>00 09</code>, are info-code 9, "DNSKEY Missing", and the text explains it: no key in the zone matches the DS. The older dig bundled with macOS prints the raw bytes, while newer BIND releases decode the code for you. Other DNSSEC codes you may meet are 6 (DNSSEC Bogus), 7 (Signature Expired) and 10 (RRSIGs Missing). For SERVFAILs that are not DNSSEC-related, see <a href="/blog/common-dns-errors-and-fixes">common DNS errors and fixes</a>.</p>
<p>The same test works the other way round. If <code>dnssec-failed.org</code> resolves through your normal resolver, that resolver is not validating DNSSEC at all.</p>

<h2>Windows, delv and browser tools</h2>
<ul>
<li><strong>Windows PowerShell:</strong> <code>Resolve-DnsName cloudflare.com -Type A -Server 1.1.1.1 -DnssecOk</code> sets the DNSSEC OK bit, so RRSIG records are listed with the answer. <code>-DnssecCd</code> sets checking-disabled, the same test as <code>dig +cd</code>.</li>
<li><strong>delv:</strong> on Linux systems with a current BIND 9 package, <code>delv @1.1.1.1 example.com A</code> validates the chain itself and prints <code>; fully validated</code> or <code>; unsigned answer</code>. The old copy bundled with macOS stopped with "no crypto support" when we tried it, so stick with dig there.</li>
<li><strong>Online:</strong> DNSViz (dnsviz.net) draws the whole chain from the root and marks the broken link. Verisign Labs' DNSSEC Debugger gives a plain pass/fail list. Our <a href="/dns-lookup">DNS lookup tool</a> is handy for quick record checks next to them.</li>
</ul>

<h2>Before you change DNS provider or registrar</h2>
<p>Most bogus domains are self-inflicted during a move. If you change the domain's nameservers to a new DNS host while the old DS record stays at the registrar, validating resolvers look for a key the new host does not have. Either remove the DS at the registrar first and wait out its TTL (a day for .com) before switching, or turn on DNSSEC at the new host and publish its DS in the same change. Our <a href="/blog/how-to-change-nameservers-step-by-step">nameserver change guide</a> and <a href="/blog/domain-transfer-checklist">domain transfer checklist</a> show where this fits in the order of steps. Once the change is made, cached DS records explain why some networks fail before others, the same timing covered in <a href="/blog/dns-propagation-explained">DNS propagation explained</a>.</p>

<h2>FAQ</h2>
<h3>Does nslookup show whether DNSSEC is working?</h3>
<p>No. nslookup does not display the DNS header flags, so you cannot see <code>ad</code>. Use dig, delv or Resolve-DnsName instead.</p>
<h3>Is an unsigned domain a problem?</h3>
<p>It still works everywhere. It just lacks protection against forged answers. A broken setup is worse than no DNSSEC, so finish the DS step properly or leave DNSSEC off.</p>
<h3>Why does the ad flag disappear when I query my router?</h3>
<p>Many home routers and some ISP resolvers forward queries without validating, or strip the flag. Test against 1.1.1.1, 8.8.8.8 or 9.9.9.9 to see the real state of the domain.</p>

<p><em>Sources: RFC 4033–4035 (DNSSEC records and validation); RFC 8914 (Extended DNS Errors); Microsoft Learn, "Resolve-DnsName" (DnssecOk and DnssecCd parameters); BIND 9 documentation for dig and delv; CircleID, "Pakistan's .PK Is Now DNSSEC-Signed, but Only One Domain Validates" (20 October 2026). Example output from live queries run 23 October 2026 on macOS with DiG 9.10.6. Keys, signatures and TTLs change over time, so your output will differ.</em></p>

Check DNSSEC with dig: look for the ad flag, find the DS record, match it to the DNSKEY, and use dig +cd to prove whether DNSSEC is behind a SERVFAIL.

How to Check if a Domain Is DNSSEC-Signed (and Actually Validating)

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

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 Check if a Domain Is DNSSEC-Signed (and Actually Validating)

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

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