<p><strong>Short answer:</strong> the apex domain (<code>example.com</code>) cannot be a CNAME, so it gets an <strong>A record</strong> (or an <strong>ALIAS/ANAME/flattened CNAME</strong> if your DNS provider supports one), and <code>www</code> gets a <strong>CNAME</strong> to the host. The values for each platform:</p>
<table>
<thead><tr><th>Host</th><th>Apex (<code>@</code>)</th><th><code>www</code> or other subdomain</th></tr></thead>
<tbody>
<tr><td>Vercel</td><td>A record with the value on your project's domain card (usually <code>76.76.21.21</code>; newer projects may show another, such as <code>216.198.79.1</code>)</td><td>CNAME to the target on the domain card, for example <code>d1d4fc829fe7bc7c.vercel-dns-017.com</code></td></tr>
<tr><td>Netlify</td><td>ALIAS/ANAME/flattened CNAME to <code>apex-loadbalancer.netlify.com</code>, or the fallback A record <code>75.2.60.5</code></td><td>CNAME to your site's <code>yoursite.netlify.app</code> name</td></tr>
<tr><td>GitHub Pages</td><td>Four A records: <code>185.199.108.153</code>, <code>185.199.109.153</code>, <code>185.199.110.153</code>, <code>185.199.111.153</code> (plus the matching AAAA records if you want IPv6), or ALIAS to <code>username.github.io</code></td><td>CNAME to <code>username.github.io</code> (or <code>orgname.github.io</code>)</td></tr>
</tbody>
</table>
<p>Add the domain in the host's dashboard <em>first</em>, then create the records at whoever runs your DNS, then check them with <code>dig</code> before you wait on SSL. The rest of this guide covers each platform's details, the records you must delete, and how to tell what is wrong when the dashboard keeps saying the configuration is invalid.</p>

<h2>Why the apex and www need different records</h2>
<p>A CNAME says "this name is really that other name", and the DNS rules do not let a CNAME share a name with any other record (<a href="https://www.rfc-editor.org/rfc/rfc1912#section-2.4" rel="noopener" target="_blank">RFC 1912, section 2.4</a>). The apex of every zone already has an SOA record and NS records, so a CNAME there is not allowed. That leaves two options for <code>example.com</code>:</p>
<ul>
<li><strong>A record (and AAAA for IPv6):</strong> a fixed IP address the host publishes. Works with every DNS provider.</li>
<li><strong>ALIAS, ANAME or CNAME flattening:</strong> a provider feature, not a standard record type. You enter a hostname, and the provider looks it up and answers with plain A/AAAA records. Netlify recommends this because it follows the host if its addresses change.</li>
</ul>
<p>Subdomains such as <code>www</code> or <code>blog</code> have no SOA or NS records, so they can use a normal CNAME. If you are unsure which record type fits a given name, our <a href="/blog/a-record-vs-cname-when-to-use-which">A record vs CNAME guide</a> walks through the rule in more detail.</p>

<h2>Before you touch DNS: two checks</h2>
<ol>
<li><strong>Find out who actually serves your DNS.</strong> Records added at your registrar do nothing if your nameservers point somewhere else, such as Cloudflare. Run a <a href="/nameserver-lookup">nameserver lookup</a> or <code>dig +short NS example.com</code> and edit records at the provider those names belong to.</li>
<li><strong>Write down the records you have now.</strong> Export or screenshot the zone. Pointing a website at a new host should touch only the apex A/AAAA records and the <code>www</code> CNAME. Your MX and TXT records (email, SPF, DKIM, verification) stay as they are. If you later move nameservers to the host instead, those email records must be recreated there first; see <a href="/blog/how-to-set-up-mx-records-for-email">how to set up MX records</a>.</li>
</ol>
<p>Lowering the TTL on the records you are about to change to 300 seconds a few hours ahead also makes a mistake much quicker to undo.</p>

<h2>Vercel</h2>
<p>Add the domain under your project's <strong>Settings &gt; Domains</strong>. Vercel then shows a domain card with the exact records it expects. Use those values, not ones copied from a forum post. Vercel's own guide, <a href="https://vercel.com/kb/guide/a-record-and-caa-with-vercel" rel="noopener" target="_blank">last updated on October 16, 2026</a>, says most projects use <code>76.76.21.21</code>, but newer projects get an address from a pool, such as <code>216.198.79.1</code>, and verification checks for the exact value on your card.</p>
<table>
<thead><tr><th>Type</th><th>Name</th><th>Value</th></tr></thead>
<tbody>
<tr><td>A</td><td><code>@</code></td><td>The IP on your domain card (often <code>76.76.21.21</code>)</td></tr>
<tr><td>CNAME</td><td><code>www</code></td><td>The CNAME target on your card, for example <code>d1d4fc829fe7bc7c.vercel-dns-017.com</code></td></tr>
</tbody>
</table>
<p>Things that trip people up on Vercel:</p>
<ul>
<li><strong>Delete apex AAAA records.</strong> Vercel does not support IPv6 for domains that use a third-party DNS provider. A leftover AAAA record that points at your old host splits visitors between two servers and can stop the SSL certificate from being issued.</li>
<li><strong>Check CAA records.</strong> If your zone has CAA records, one must allow <code>letsencrypt.org</code>, or certificate issuance fails.</li>
<li><strong>Older guides use <code>cname.vercel-dns.com</code>.</strong> When we looked it up on October 26, 2026, it answered with <code>76.76.21.93</code> and <code>66.33.60.194</code>, not <code>76.76.21.21</code>. That is a good reminder not to copy an IP out of a CNAME target into an A record. Use the documented value for each record type.</li>
<li><strong>Wildcards such as <code>*.example.com</code></strong> need Vercel's nameservers (<code>ns1.vercel-dns.com</code> and <code>ns2.vercel-dns.com</code>) or the certificate-delegation records the dashboard shows, because Vercel has to answer the certificate challenge for every subdomain.</li>
</ul>

<h2>Netlify</h2>
<p>Add the domain under <strong>Domain management</strong> for the site. If you add either the apex or <code>www</code>, Netlify automatically adds both, so plan to configure both. According to <a href="https://docs.netlify.com/manage/domains/configure-domains/configure-external-dns/" rel="noopener" target="_blank">Netlify's external DNS docs</a>:</p>
<table>
<thead><tr><th>Type</th><th>Name</th><th>Value</th></tr></thead>
<tbody>
<tr><td>ALIAS / ANAME / flattened CNAME (recommended)</td><td><code>@</code></td><td><code>apex-loadbalancer.netlify.com</code></td></tr>
<tr><td>A (fallback if no ALIAS support)</td><td><code>@</code></td><td><code>75.2.60.5</code></td></tr>
<tr><td>CNAME</td><td><code>www</code></td><td><code>yoursite.netlify.app</code></td></tr>
</tbody>
</table>
<p>Use one apex option, not both. Sites on Netlify's High-Performance Edge use different load-balancer values, which are shown in the <strong>Pending DNS verification</strong> dialog, so check there before copying the table above. On October 26, 2026, <code>apex-loadbalancer.netlify.com</code> resolved to <code>75.2.60.5</code> and <code>99.83.231.61</code>. That is why the ALIAS route is more resilient: if Netlify changes those addresses, your provider follows automatically.</p>

<h2>GitHub Pages</h2>
<p>Set the custom domain under the repository's <strong>Settings &gt; Pages</strong> first. If you publish from a branch, GitHub commits a <code>CNAME</code> file to the repository. If you publish with a custom GitHub Actions workflow, no file is created and none is needed. Then add the records from <a href="https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site" rel="noopener" target="_blank">GitHub's custom domain docs</a>:</p>
<table>
<thead><tr><th>Type</th><th>Name</th><th>Value</th></tr></thead>
<tbody>
<tr><td>A (add all four)</td><td><code>@</code></td><td><code>185.199.108.153</code>, <code>185.199.109.153</code>, <code>185.199.110.153</code>, <code>185.199.111.153</code></td></tr>
<tr><td>AAAA (optional, all four)</td><td><code>@</code></td><td><code>2606:50c0:8000::153</code>, <code>2606:50c0:8001::153</code>, <code>2606:50c0:8002::153</code>, <code>2606:50c0:8003::153</code></td></tr>
<tr><td>CNAME</td><td><code>www</code></td><td><code>username.github.io</code> (no repository name)</td></tr>
</tbody>
</table>
<p>Two GitHub-specific rules matter for security. First, <strong>do not use wildcard records</strong> such as <code>*.example.com</code>. GitHub warns that they put you at immediate risk of a domain takeover. Second, <strong>verify the domain</strong> under your account's Pages settings. GitHub gives you a TXT record at <code>_github-pages-challenge-USERNAME.example.com</code>, and once it is verified, other accounts cannot use your domain or its immediate subdomains for their own Pages sites (<a href="https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages" rel="noopener" target="_blank">GitHub: verifying your custom domain</a>). When the certificate is ready, tick <strong>Enforce HTTPS</strong>.</p>

<h2>Check the records yourself</h2>
<p>Do not trust the dashboard alone. Ask DNS directly, and ask a public resolver so your local cache is not involved:</p>
<pre>dig +short A example.com @1.1.1.1
dig +short AAAA example.com @1.1.1.1
dig +short CNAME www.example.com @1.1.1.1
dig +short CAA example.com @1.1.1.1</pre>
<p>On Windows, <code>nslookup -type=A example.com 1.1.1.1</code> gives the same answer, or use our <a href="/dns-lookup">DNS lookup tool</a>. What you want to see:</p>
<ul>
<li>The apex returns <strong>only</strong> the host's addresses. One extra IP, usually from a parking page or the previous host, means some visitors get the old site and certificate checks fail at random.</li>
<li>The AAAA query is empty for Vercel, matches GitHub's four addresses for GitHub Pages, or is empty.</li>
<li><code>www</code> returns your CNAME target, not an A record left over from the old host.</li>
<li>CAA is empty, or it includes <code>letsencrypt.org</code>.</li>
</ul>
<p>If the answers are right but your browser still shows the old site, it is caching, not configuration. <a href="/blog/dns-propagation-explained">How DNS propagation works</a> explains why, and how long the old TTL keeps the old answer alive.</p>

<h2>When the dashboard still says "Invalid Configuration"</h2>
<ul>
<li><strong>Records at the wrong provider.</strong> The most common cause. Check the nameservers again and edit the zone there.</li>
<li><strong>A conflicting record with the same name.</strong> Many providers create a default <code>@</code> A record or a <code>www</code> A record for a parking page. Delete it, because <code>www</code> cannot have both an A record and a CNAME.</li>
<li><strong>The provider appended your domain.</strong> A CNAME value typed as <code>username.github.io</code> without a trailing dot can become <code>username.github.io.example.com</code> on some panels. <code>dig +short CNAME www.example.com</code> shows exactly what was saved.</li>
<li><strong>A proxy in front.</strong> If the record is proxied through a CDN (the orange cloud in Cloudflare), DNS answers with the CDN's addresses, so the host's check never sees the values it asked for. Set the record to DNS only while you connect the domain; our <a href="/blog/cloudflare-dns-setup-guide">Cloudflare DNS setup guide</a> shows where that switch is.</li>
<li><strong>Not propagated yet.</strong> If a public resolver already returns the right values, give the host's check some time, or use its refresh or verify button.</li>
</ul>
<p>Once DNS is correct, the host issues the certificate. You can confirm it with our <a href="/ssl-checker">SSL checker</a>.</p>

<h2>FAQ</h2>
<h3>Should I point nameservers to the host instead?</h3>
<p>You can. Vercel and Netlify both offer their own DNS, and it removes the guesswork about which values to use. The trade-off is that the whole zone, including email records, then lives with your web host. If your registrar or Cloudflare already runs your DNS well, changing two records is the smaller change. If you do move, follow <a href="/blog/how-to-change-nameservers-step-by-step">how to change nameservers</a> and copy every existing record across first.</p>
<h3>Which should be the main address, apex or www?</h3>
<p>Either works. Pick one, make the other redirect to it in the host's domain settings, and keep it that way so links and search results stay consistent.</p>
<h3>Why did it work for me but not for a friend?</h3>
<p>Different resolvers cached the old record at different times. Until the old TTL runs out, two people can see two different sites. Check with <code>@1.1.1.1</code> and <code>@8.8.8.8</code>. If both are correct, it is only a matter of waiting.</p>
<h3>Does this affect my email?</h3>
<p>Not if you only change the apex A/AAAA records and the <code>www</code> CNAME. Email depends on MX and TXT records, which this change does not touch. For the full list of records a domain usually needs, see <a href="/blog/what-dns-records-does-a-website-need">what DNS records a website needs</a>.</p>

<h2>Sources</h2>
<ul>
<li><a href="https://vercel.com/kb/guide/a-record-and-caa-with-vercel" rel="noopener" target="_blank">Vercel: Can I use my domain on Vercel with A records?</a> (updated 16 Oct 2026)</li>
<li><a href="https://vercel.com/docs/domains/troubleshooting" rel="noopener" target="_blank">Vercel: Troubleshooting domains</a></li>
<li><a href="https://docs.netlify.com/manage/domains/configure-domains/configure-external-dns/" rel="noopener" target="_blank">Netlify: Configure external DNS for a custom domain</a></li>
<li><a href="https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site" rel="noopener" target="_blank">GitHub Docs: Managing a custom domain for your GitHub Pages site</a></li>
<li><a href="https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages" rel="noopener" target="_blank">GitHub Docs: Verifying your custom domain for GitHub Pages</a></li>
<li><a href="https://www.rfc-editor.org/rfc/rfc1912#section-2.4" rel="noopener" target="_blank">RFC 1912, section 2.4: CNAME records</a></li>
</ul>

Exact DNS records to point a domain to Vercel, Netlify or GitHub Pages: apex A or ALIAS, www CNAME, records to delete, and how to verify them with dig.

How to Point a Domain to Vercel, Netlify or GitHub Pages (A vs CNAME vs ALIAS)

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

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 Point a Domain to Vercel, Netlify or GitHub Pages (A vs CNAME vs ALIAS)

DKIM Record Lookup: Find Your Selector and Verify the Key

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