<p><strong>Short answer:</strong> A DKIM record lives at <code>selector._domainkey.yourdomain.com</code>, so you cannot look it up until you know the selector. Get the selector from a real message: open the full headers of an email your domain sent, find the <code>DKIM-Signature</code> header and read two tags, <code>d=</code> (the signing domain) and <code>s=</code> (the selector). Then query the TXT record at <code>s._domainkey.d</code>:</p>
<pre>dig +short TXT google._domainkey.example.com</pre>
<p>If you get back a string with a long <code>p=</code> value, the public key is published. If you get nothing, the selector or domain is wrong, the record was never added, or the change has not reached your resolver yet. The rest of this guide shows where to find the headers in Gmail, Outlook and Apple Mail, the lookup commands for every platform, how to read the record, and what each failure means.</p>

<h2>What a DKIM pass does (and does not) prove</h2>
<p>This week is a good reminder of what DKIM is for. On October 22, 2026, <a href="https://www.helpnetsecurity.com/2026/10/22/legitimate-platforms-abused-phishing-emails/" rel="noopener" target="_blank">Help Net Security reported</a> on Cisco Talos research into scams delivered through legitimate platforms: fake order confirmations that were sent by real retailer systems, so they passed DKIM and DMARC. DKIM answers one narrow question: which domain signed this message, and was the signed content changed after signing? It does not say the content is honest. Reading the <code>d=</code> value and looking up the key yourself tells you exactly who took responsibility for a message, nothing more.</p>
<p>For your own domain, the lookup matters for a plainer reason. Under the <a href="https://support.google.com/mail/answer/81126?hl=en" rel="noopener" target="_blank">Gmail email sender guidelines</a>, every sender to Gmail needs SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail accounts needs SPF, DKIM and DMARC. A missing or broken DKIM key usually shows up as rejected or spam-foldered mail long before anyone thinks to check DNS.</p>

<h2>Step 1: Find the selector and signing domain</h2>
<p>DNS gives you no way to list every name under <code>_domainkey</code>, so guessing selectors is slow and proves nothing when it fails. The selector is written into every signed message, so start there. Send a test email from the domain you want to check to a mailbox at another provider, then open the full headers:</p>
<ul>
<li><strong>Gmail on the web:</strong> open the message, click More (the three dots) next to Reply, then <strong>Show original</strong>. The summary at the top already lists the DKIM result and domain; the raw header is below it (<a href="https://support.google.com/mail/answer/29436?hl=en" rel="noopener" target="_blank">Google's steps</a>).</li>
<li><strong>New Outlook for Windows and Outlook on the web:</strong> select <strong>More actions</strong> at the top of the message, then <strong>View</strong> &gt; <strong>View message details</strong> (<a href="https://support.microsoft.com/en-us/outlook/view-internet-message-headers-in-outlook" rel="noopener" target="_blank">Microsoft's steps</a>).</li>
<li><strong>Apple Mail:</strong> open the message, then choose <strong>View</strong> &gt; <strong>Message</strong> &gt; <strong>All Headers</strong>.</li>
</ul>
<p>Search the header text for <code>DKIM-Signature</code>. A Google Workspace signature looks like this (shortened):</p>
<pre>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=google; t=1761386400;
        h=to:subject:message-id:date:from:mime-version;
        bh=...; b=...</pre>
<p>Here <code>d=example.com</code> is the signing domain and <code>s=google</code> is the selector, so the public key lives at <code>google._domainkey.example.com</code>. A message can carry more than one DKIM-Signature header, for example your domain's signature plus one added by the email service that sent it. Look them all up. The one whose <code>d=</code> matches the domain in the visible From address is the one DMARC cares about.</p>
<p>Then read the receiving server's verdict in the <code>Authentication-Results</code> header. It names the exact signature it checked:</p>
<pre>Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google header.b=AbCdEf12;
       spf=pass ...;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com</pre>

<h3>Default selectors used by common senders</h3>
<p>If you cannot get a message, these defaults are a reasonable first guess. Your own setup may differ, so a real header always wins.</p>
<table>
<thead><tr><th>Sending service</th><th>Default selector(s)</th><th>What you publish</th></tr></thead>
<tbody>
<tr><td>Google Workspace</td><td><code>google</code> (you can choose another prefix when you generate the key)</td><td>TXT record with the public key</td></tr>
<tr><td>Microsoft 365</td><td><code>selector1</code> and <code>selector2</code></td><td>Two CNAME records pointing to Microsoft-hosted names</td></tr>
<tr><td>SendGrid</td><td><code>s1</code> and <code>s2</code></td><td>CNAME records pointing to sendgrid.net names</td></tr>
</tbody>
</table>
<p>With CNAME-based providers the TXT key itself sits in the provider's DNS. Your lookup follows the CNAME automatically, so seeing a CNAME line before the key is expected, not an error. <a href="https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure" rel="noopener" target="_blank">Microsoft's DKIM guide</a> explains why Microsoft 365 uses CNAME records for this.</p>

<h2>Step 2: Query the DKIM record</h2>
<p>Swap in your own selector and domain.</p>
<p><strong>macOS and Linux (dig):</strong></p>
<pre>dig +short TXT google._domainkey.example.com</pre>
<p><strong>Windows Command Prompt (nslookup):</strong></p>
<pre>nslookup -type=TXT google._domainkey.example.com</pre>
<p><strong>Windows PowerShell:</strong></p>
<pre>Resolve-DnsName -Name google._domainkey.example.com -Type TXT</pre>
<p>To rule out a stale cache on your own network, ask a public resolver directly with <code>dig +short TXT google._domainkey.example.com @1.1.1.1</code> or <code>nslookup -type=TXT google._domainkey.example.com 8.8.8.8</code>. Our guide to <a href="/blog/nslookup-specific-dns-server">querying a specific DNS server</a> explains when that matters. If you would rather use a browser, enter the full name (for example <code>google._domainkey.example.com</code>) in the <a href="/dns-lookup">DNS lookup tool</a> and choose TXT.</p>
<p>This is what a CNAME-based key looks like. SendGrid's own domain, queried on October 25, 2026 (key shortened):</p>
<pre>$ dig +short TXT s1._domainkey.sendgrid.com
s1.domainkey.u298828.wl079.sendgrid.net.
"k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2LaY8C3p..."</pre>
<p>And this is a retired key. Gmail's own selector from June 2023, queried the same day:</p>
<pre>$ dig +short TXT 20230601._domainkey.gmail.com
"v=DKIM1; k=rsa; p="</pre>
<p>The empty <code>p=</code> is deliberate. <a href="https://www.rfc-editor.org/rfc/rfc6376.html" rel="noopener" target="_blank">RFC 6376</a>, the DKIM standard, says an empty public key value means the key has been revoked. Any message still signed with that selector will fail.</p>

<h2>Step 3: Read the record</h2>
<table>
<thead><tr><th>Tag</th><th>Meaning</th><th>What to check</th></tr></thead>
<tbody>
<tr><td><code>v=DKIM1</code></td><td>Record version</td><td>Optional (SendGrid's record above omits it), but if present it must come first</td></tr>
<tr><td><code>k=</code></td><td>Key type</td><td><code>rsa</code> is the default; <code>ed25519</code> is defined in <a href="https://www.rfc-editor.org/rfc/rfc8463.html" rel="noopener" target="_blank">RFC 8463</a></td></tr>
<tr><td><code>p=</code></td><td>Base64 public key</td><td>Must not be empty unless you meant to revoke the key</td></tr>
<tr><td><code>t=y</code></td><td>Testing mode</td><td>Receivers treat a failure like an unsigned message; remove it once signing is stable</td></tr>
<tr><td><code>t=s</code></td><td>Strict domain</td><td>The signature's <code>i=</code> domain must equal <code>d=</code> exactly, with no subdomains</td></tr>
<tr><td><code>h=</code></td><td>Allowed hash algorithms</td><td>If present, it should allow <code>sha256</code></td></tr>
</tbody>
</table>
<p><strong>Key length.</strong> A quick way to tell the key size from a lookup: an RSA <code>p=</code> value of about 216 characters is a 1024-bit key, and about 392 characters is a 2048-bit key. <a href="https://www.rfc-editor.org/rfc/rfc8301.html" rel="noopener" target="_blank">RFC 8301</a> requires signers to use RSA keys of at least 1024 bits, recommends at least 2048 bits, and forbids SHA-1 signing. <a href="https://support.google.com/a/answer/174124?hl=en" rel="noopener" target="_blank">Google Workspace's DKIM setup guide</a> likewise says to choose 2048 bits if your domain host supports it.</p>
<p><strong>Split strings are normal.</strong> A single TXT string can hold at most 255 characters, so a 2048-bit key is usually published as two or more quoted strings inside one record, and dig prints them as <code>"v=DKIM1; k=rsa; p=MIIB..." "...rest of key"</code>. Receivers join them back together. The real problems are a key split across two separate TXT records, stray spaces or line breaks pasted into the key, or extra quote marks typed into a panel that adds its own.</p>

<h2>What the result means and how to fix it</h2>
<table>
<thead><tr><th>What you see</th><th>Likely cause</th><th>Fix</th></tr></thead>
<tbody>
<tr><td>No TXT answer for the name</td><td>Wrong selector, record never added, or added at the wrong host name</td><td>Copy the selector from a header. Most DNS panels want only <code>google._domainkey</code> in the host field; typing the full domain there creates <code>google._domainkey.example.com.example.com</code></td></tr>
<tr><td>Record found, <code>p=</code> empty</td><td>The key was revoked during a rotation</td><td>Fine if nothing signs with that selector any more; otherwise publish the current key from your provider</td></tr>
<tr><td><code>dkim=fail</code> with "signature verification failed"</td><td>The DNS key does not match the private key the server signs with, often an old key left after regenerating</td><td>Copy the current value from your provider's admin page and replace the record</td></tr>
<tr><td><code>dkim=fail</code> with "body hash did not verify"</td><td>The message was changed after signing (mailing list footer, a gateway rewriting links, some forwarding)</td><td>This is not a DNS problem; find the system that modifies mail after it is signed</td></tr>
<tr><td><code>dkim=permerror</code> or "no key"</td><td>Malformed or missing record, or two TXT records at the same name</td><td>Keep exactly one record per selector, pasted without extra quotes or line breaks</td></tr>
<tr><td><code>dkim=pass</code> but <code>dmarc=fail</code></td><td>The <code>d=</code> domain belongs to your email service, not to your From domain</td><td>Turn on custom domain authentication with that service so it signs as your domain</td></tr>
</tbody>
</table>
<p>DMARC accepts a DKIM pass only when the signing domain lines up with the From domain. With the default relaxed alignment, a subdomain such as <code>mail.example.com</code> counts for <code>example.com</code>. Our <a href="/blog/spf-dkim-dmarc-setup-guide">SPF, DKIM and DMARC setup guide</a> covers the policy side, and the <a href="/blog/email-deliverability-and-dns-records">email deliverability and DNS records</a> overview shows how DKIM fits with MX and SPF.</p>

<h2>After you add or change a DKIM record</h2>
<ol>
<li><strong>Check the authoritative servers first.</strong> Find them with <code>dig +short NS example.com</code>, then ask one directly, for example <code>dig +short TXT google._domainkey.example.com @ns1.your-dns-host.com</code>. If the authoritative answer is right, the rest is caching; see <a href="/blog/dns-propagation-explained">how DNS propagation works</a>.</li>
<li><strong>Finish the provider side.</strong> In Google Workspace, go back to <strong>Apps</strong> &gt; <strong>Google Workspace</strong> &gt; <strong>Gmail</strong> &gt; <strong>Authenticate email</strong> and start authentication once the record resolves. Google notes the admin page may keep asking you to update DNS for up to 48 hours even when the record is correct.</li>
<li><strong>Rotate without downtime.</strong> Publish the new key under a new selector, switch signing to it, keep the old record for a few days so mail already in transit still verifies, then revoke the old one with an empty <code>p=</code> value.</li>
<li><strong>Send one more test.</strong> Confirm <code>dkim=pass</code> with the new <code>header.s=</code> value in Authentication-Results.</li>
</ol>
<p>If you use Google Workspace, check SPF at the same time with our <a href="/blog/spf-record-for-google-workspace">SPF record for Google Workspace</a> guide.</p>

<h2>FAQ</h2>
<h3>Can I find a DKIM selector without an email from the domain?</h3>
<p>Not reliably. DNS does not let you list names under <code>_domainkey</code>. You can try common defaults such as <code>google</code>, <code>selector1</code> or <code>s1</code>, but a miss proves nothing. A header from a real message is the only certain source.</p>
<h3>Why does my DKIM record not start with v=DKIM1?</h3>
<p>The version tag is optional. Records without it, like SendGrid's example above, are valid as long as the <code>p=</code> key is correct.</p>
<h3>Should I use a 1024-bit or 2048-bit key?</h3>
<p>Use 2048 bits if your DNS host accepts long TXT values, which almost all do today. Use 1024 bits only as a fallback; RFC 8301 sets that as the minimum.</p>
<h3>Does a DKIM pass mean an email is safe?</h3>
<p>No. It means the domain in <code>d=</code> signed the message and the signed parts were not altered. As the October 2026 Cisco Talos research shows, a legitimate system can still sign a scam someone fed into it.</p>

<h2>Sources</h2>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6376.html" rel="noopener" target="_blank">RFC 6376: DomainKeys Identified Mail (DKIM) Signatures</a></li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8301.html" rel="noopener" target="_blank">RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM</a></li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8463.html" rel="noopener" target="_blank">RFC 8463: A New Cryptographic Signature Method for DKIM (Ed25519)</a></li>
<li><a href="https://support.google.com/a/answer/174124?hl=en" rel="noopener" target="_blank">Google Workspace Admin Help: Set up DKIM</a></li>
<li><a href="https://support.google.com/mail/answer/81126?hl=en" rel="noopener" target="_blank">Gmail Help: Email sender guidelines</a></li>
<li><a href="https://support.google.com/mail/answer/29436?hl=en" rel="noopener" target="_blank">Gmail Help: Trace an email with its full headers</a></li>
<li><a href="https://support.microsoft.com/en-us/outlook/view-internet-message-headers-in-outlook" rel="noopener" target="_blank">Microsoft Support: View internet message headers in Outlook</a></li>
<li><a href="https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure" rel="noopener" target="_blank">Microsoft Learn: Set up DKIM to sign mail from your Microsoft 365 domain</a></li>
<li><a href="https://www.helpnetsecurity.com/2026/10/22/legitimate-platforms-abused-phishing-emails/" rel="noopener" target="_blank">Help Net Security: Attackers abuse legitimate platforms to deliver phishing emails that pass authentication checks (October 22, 2026)</a></li>
</ul>

How to do a DKIM record lookup: find the selector in the email header, query selector._domainkey with dig or nslookup, read the key and fix DKIM failures.

DKIM Record Lookup: Find Your Selector and Verify the Key

<p><strong>Short answer:</strong> "DNS server not responding" means your device sent a name lookup to the DNS server it is configured to use and got no answer back in time. Your internet connection itself may be fine; it is the step that turns a name like example.com into an IP address that fails. You can confirm it in ten seconds: if <code>ping 1.1.1.1</code> gets replies but <code>ping example.com</code> fails, DNS is the problem. Then run <code>nslookup example.com 1.1.1.1</code>. If that answers while a plain <code>nslookup example.com</code> times out, the resolver you normally use (usually your router or your ISP) is at fault, and switching to a public resolver fixes it in about a minute. The rest of this guide is the full order of checks, with exact commands for Windows, macOS and Linux.</p>

<h2>What the error actually means</h2>
<p>Windows shows it in Network Diagnostics as "Your computer appears to be correctly configured, but the device or resource (DNS server) is not responding." Chrome and Edge usually report the same failure with a <code>DNS_PROBE</code> error code, and Safari says it "can't find the server." In every case the client asked a resolver to translate a name and nothing usable came back.</p>
<p>That is different from the errors in our <a href="/blog/common-dns-errors-and-fixes">common DNS errors guide</a>. NXDOMAIN means a server <em>did</em> answer and said the name does not exist. SERVFAIL means a server answered and said it could not resolve the name. "Not responding" means there was no answer at all, so the problem almost always sits between your device and its resolver, not in the website's own DNS records. If one site shows <a href="/blog/how-to-fix-dns-probe-finished-nxdomain">DNS_PROBE_FINISHED_NXDOMAIN</a> while everything else loads, that is a different fault with a different fix.</p>

<h2>Step 1: Confirm it really is DNS</h2>
<p>Open a terminal (Command Prompt or PowerShell on Windows, Terminal on macOS or Linux) and run two pings: one to an IP address, one to a name.</p>
<pre>ping 1.1.1.1
ping example.com</pre>
<table>
<thead><tr><th>Result</th><th>What it tells you</th><th>Next step</th></tr></thead>
<tbody>
<tr><td>Both fail</td><td>No network path at all (Wi-Fi, cable, router or ISP outage)</td><td>Fix the connection first; DNS settings will not help</td></tr>
<tr><td>IP replies, name fails</td><td>The connection works, name lookups do not</td><td>Continue with Step 2</td></tr>
<tr><td>Both work</td><td>DNS is working right now</td><td>The problem is one site or an intermittent resolver; test that exact name with nslookup</td></tr>
</tbody>
</table>
<p>Some networks block ping. If <code>ping 1.1.1.1</code> fails but other connections clearly work (a messaging app, a video call), treat it as "IP replies" and carry on.</p>

<h2>Step 2: Find out which DNS server you are actually using</h2>
<p>You cannot fix a resolver until you know which one your device is asking.</p>
<ul>
<li><strong>Windows:</strong> <code>ipconfig /all</code> and read the <em>DNS Servers</em> line for your active adapter, or in PowerShell <code>Get-DnsClientServerAddress -AddressFamily IPv4</code>.</li>
<li><strong>macOS:</strong> <code>scutil --dns | grep nameserver</code></li>
<li><strong>Linux with systemd-resolved:</strong> <code>resolvectl status</code>; on other systems <code>cat /etc/resolv.conf</code>.</li>
</ul>
<p>How to read the address: <code>192.168.1.1</code>, <code>192.168.0.1</code> or <code>10.0.0.1</code> is normally your router, which forwards every lookup to your ISP. <code>127.0.0.53</code> is the local systemd-resolved stub on Linux, so check <code>resolvectl status</code> for the real upstream. An address you do not recognise, such as a leftover VPN resolver or something you once typed in manually, is a strong clue in itself.</p>

<h2>Step 3: Ask a different DNS server directly</h2>
<p>This is the test that splits the problem in half. Run the same lookup three times: once against your normal resolver and twice against public ones.</p>
<pre>nslookup example.com
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8</pre>
<p>A resolver that does not answer looks like this on macOS and Linux (we pointed the lookup at an unused documentation address to reproduce it):</p>
<pre>$ dig +time=2 +tries=1 example.com @192.0.2.1
;; connection timed out; no servers could be reached</pre>
<p>On Windows the same failure prints <code>DNS request timed out</code> instead. A healthy answer from Cloudflare's resolver, run on 24 October 2026, looked like this:</p>
<pre>$ nslookup example.com 1.1.1.1
Server:    1.1.1.1
Address:   1.1.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 104.20.23.154</pre>
<ul>
<li><strong>Your default times out, the public servers answer:</strong> your configured resolver is the problem. Go to Step 4, then Step 5 if it comes back.</li>
<li><strong>All three time out:</strong> something on your device or network is blocking DNS traffic (port 53) itself. Skip to Step 6.</li>
</ul>
<p>In PowerShell the equivalent is <code>Resolve-DnsName -Name example.com -Server 1.1.1.1 -DnsOnly</code>. For more ways to point a lookup at a chosen server, see <a href="/blog/nslookup-specific-dns-server">how to query a specific DNS server with nslookup and dig</a>.</p>

<h2>Step 4: Restart the router and flush the local cache</h2>
<p>Most home routers run a small DNS forwarder. After long uptime, a firmware glitch or an ISP reconnect it can stop answering while the rest of the router keeps working, which is exactly the "IP works, names don't" pattern. Unplug the router for 30 seconds, plug it back in and wait until it has fully reconnected.</p>
<p>Then clear the cache on your device so it stops reusing failures it stored while DNS was broken:</p>
<ul>
<li><strong>Windows:</strong> <code>ipconfig /flushdns</code> (or <code>Clear-DnsClientCache</code> in PowerShell)</li>
<li><strong>macOS:</strong> <code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder</code></li>
<li><strong>Linux (systemd-resolved):</strong> <code>resolvectl flush-caches</code></li>
</ul>
<p>Be realistic about what flushing does: it cannot make a dead resolver answer. It only removes stale entries, which is why it helps after the resolver is back but not before.</p>

<h2>Step 5: Switch to a public DNS resolver</h2>
<p>If your ISP's resolver keeps failing, stop depending on it. These free public resolvers are run by large operators and answer from many locations:</p>
<table>
<thead><tr><th>Provider</th><th>IPv4</th><th>IPv6</th></tr></thead>
<tbody>
<tr><td>Cloudflare</td><td>1.1.1.1, 1.0.0.1</td><td>2606:4700:4700::1111, 2606:4700:4700::1001</td></tr>
<tr><td>Google Public DNS</td><td>8.8.8.8, 8.8.4.4</td><td>2001:4860:4860::8888, 2001:4860:4860::8844</td></tr>
<tr><td>Quad9</td><td>9.9.9.9, 149.112.112.112</td><td>listed on Quad9's own setup page</td></tr>
</tbody>
</table>
<p>Using one address from two different providers (for example 1.1.1.1 and 8.8.8.8) gives you a fallback if one provider has an incident. Our <a href="/blog/best-free-dns-providers-compared">free DNS providers comparison</a> covers the privacy and filtering differences.</p>
<h3>Windows</h3>
<p>In PowerShell as administrator, find your adapter name, then set the servers:</p>
<pre>Get-NetAdapter
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","8.8.8.8")</pre>
<p>To go back to the servers your router hands out, run <code>Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses</code>. The same change is available in Settings under Network &amp; internet, in the DNS server assignment section of your Wi-Fi or Ethernet connection.</p>
<h3>macOS</h3>
<p>Open System Settings, click Network, choose your connection, click Details and then DNS. Or from Terminal:</p>
<pre>networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
networksetup -setdnsservers Wi-Fi empty</pre>
<p>The second line undoes the change and returns to the router's servers.</p>
<h3>On the router</h3>
<p>Setting the DNS servers in the router's WAN or DHCP settings fixes every device on the network at once, including phones, TVs and consoles that have no easy DNS setting of their own.</p>
<p><strong>One caution for work laptops:</strong> company networks often resolve internal names (intranet sites, Active Directory, VPN-only hosts) only through the company's own DNS servers. Overriding them with a public resolver can break those names. On a managed device, report the problem to IT instead of changing DNS yourself.</p>

<h2>Step 6: When no DNS server answers at all</h2>
<p>If even 1.1.1.1 and 8.8.8.8 time out while <code>ping 1.1.1.1</code> works, DNS packets are being dropped on the way out. Check these in order:</p>
<ol>
<li><strong>VPN client.</strong> Many VPNs force their own resolver and can leave a dead DNS setting behind after a crash or an unclean disconnect. Disconnect, quit the client completely and test again.</li>
<li><strong>Security software.</strong> Antivirus suites with "web protection" or DNS filtering sometimes intercept lookups. Pause that feature briefly to test, then turn it back on.</li>
<li><strong>Captive portal.</strong> Hotel, airport and office guest Wi-Fi often blocks DNS until you accept the login page. Open any plain http address in a browser to trigger the sign-in screen.</li>
<li><strong>A broken IPv6 resolver.</strong> If the router advertises an IPv6 DNS server that does not work, some lookups stall. Check the IPv6 entries from Step 2; our <a href="/blog/ipv6-dns-configuration-guide">IPv6 DNS configuration guide</a> explains how they are assigned.</li>
<li><strong>Windows network stack.</strong> In an administrator Command Prompt run <code>ipconfig /release</code>, <code>ipconfig /renew</code>, then <code>netsh winsock reset</code> and <code>netsh int ip reset</code>, and restart the PC.</li>
</ol>
<p>The opposite pattern also exists: nslookup works but one browser fails. That usually means the browser's own secure DNS setting points at a provider your network blocks. Our <a href="/blog/dns-over-https-explained">DNS over HTTPS explainer</a> shows where that setting lives.</p>

<h2>If only your own domain fails</h2>
<p>If you run a website and visitors report DNS errors for your domain while every other site works for them, the issue is not their resolver. It is your domain's authoritative nameservers, and resolvers will usually return SERVFAIL rather than a timeout. Check which nameservers the domain is delegated to and whether each one answers:</p>
<pre>dig NS yourdomain.com +short
dig @ns1.yourdnshost.com yourdomain.com A +norecurse</pre>
<p>A nameserver that times out here, a delegation to servers that no longer host the zone, or an expired domain are the usual causes. You can run the same checks in the browser with our <a href="/nameserver-lookup">nameserver lookup</a> and <a href="/dns-lookup">DNS lookup</a> tools, and <a href="/blog/how-to-check-domain-nameservers">how to check what nameservers a domain is using</a> walks through reading the results.</p>

<h2>Quick checklist</h2>
<ol>
<li>Ping an IP and a name to confirm the fault is DNS.</li>
<li>Note which DNS server your device uses.</li>
<li>Run nslookup against your default resolver, 1.1.1.1 and 8.8.8.8.</li>
<li>Restart the router and flush the local DNS cache.</li>
<li>If the default resolver keeps failing, switch to two public resolvers from different providers.</li>
<li>If nothing answers, check the VPN, security software, captive portal, IPv6 DNS and the Windows network stack.</li>
</ol>

<h2>FAQ</h2>
<h3>Is it safe to use 1.1.1.1 or 8.8.8.8 instead of my ISP's DNS?</h3>
<p>For most home users, yes. Both are free, widely used resolvers with published privacy policies. The main exception is a work or school network that needs its own DNS servers for internal names.</p>
<h3>Why does only one device get the error?</h3>
<p>Because that device has its own DNS setting: a manual entry, a VPN, security software or a stale cache. Compare its Step 2 output with a device that works.</p>
<h3>Will flushing DNS fix "DNS server not responding"?</h3>
<p>Only if the resolver is already answering again and your device is holding on to an old failure. If the resolver itself is down, change the resolver instead.</p>

<h2>Sources</h2>
<ul>
<li><a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig" rel="noopener" target="_blank">Microsoft Learn: ipconfig</a></li>
<li><a href="https://learn.microsoft.com/en-us/powershell/module/dnsclient/set-dnsclientserveraddress" rel="noopener" target="_blank">Microsoft Learn: Set-DnsClientServerAddress</a> and <a href="https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache" rel="noopener" target="_blank">Clear-DnsClientCache</a></li>
<li><a href="https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac" rel="noopener" target="_blank">Apple Support: Change DNS settings on Mac</a></li>
<li><a href="https://developers.cloudflare.com/1.1.1.1/setup/windows/" rel="noopener" target="_blank">Cloudflare: set up 1.1.1.1 on Windows</a></li>
<li><a href="https://developers.google.com/speed/public-dns/docs/using" rel="noopener" target="_blank">Google Public DNS: get started</a></li>
</ul>

DNS server not responding? Confirm it is DNS with two pings, test 1.1.1.1 and 8.8.8.8 with nslookup, then fix the resolver on Windows, macOS, Linux or your router.

DNS Server Not Responding: What It Means and How to Fix It

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

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

DKIM Record Lookup: Find Your Selector and Verify the Key

DNS Server Not Responding: What It Means and How to Fix It

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