HardenedHost

Note

How to check and verify a DKIM record with PowerShell

2 min read

When setting up custom email (like Google Workspace, Microsoft 365, or Amazon SES), your email provider asks you to add a DKIM record to your DNS.

DKIM acts like a digital wax seal: your mail server stamps every outgoing email with a private cryptographic key, and recipient inboxes verify that stamp against the public key published in your DNS.

Instead of pasting your domain into third-party web checkers, you can inspect and verify your DKIM records directly from your PowerShell terminal.

What is a “Selector”?

Every DKIM record lives under a special subdomain format:

<selector>._domainkey.<yourdomain.com>

The selector is simply a label chosen by your email provider so you can have multiple keys (for example, one for your Google Workspace inboxes, and one for your marketing newsletter).

Where do you find your selector?

  1. In your email dashboard: Google usually uses google (or a timestamp like 20230601). Amazon SES gives you three random tokens (like 7abcd1234ef). Microsoft 365 uses selector1.
  2. In an email header: Open an email sent from that domain, view the raw original source, and look for s= in the DKIM-Signature header (e.g. s=20230601; d=gmail.com).

Step 1: Testing a TXT-based DKIM record

Many providers give you a TXT record containing the public key starting with v=DKIM1; k=rsa; p=....

Using hardenedhost.com as our domain example, if your selector is google:

$selector = "google"
$domain   = "hardenedhost.com"

Resolve-DnsName -Name "$selector._domainkey.$domain" -Type TXT

To display just the clean key string without table borders:

(Resolve-DnsName -Name "$selector._domainkey.$domain" -Type TXT).Strings

What the response means:

  • v=DKIM1: The DKIM protocol version.
  • k=rsa: The encryption type (RSA).
  • p=MIIBIjANB...: The public key. Any mail server in the world uses this string to verify that emails from your domain weren’t forged or tampered with in transit.

Step 2: Testing a CNAME-based DKIM record (Amazon SES & Microsoft 365)

Some cloud providers (like Amazon SES or Microsoft 365) use CNAME records instead of TXT records. This allows them to rotate your security keys in the background automatically.

If your provider gave you a CNAME record (like token1._domainkey.hardenedhost.com):

Resolve-DnsName -Name "token1._domainkey.hardenedhost.com" -Type CNAME

If it is working, the NameHost column will show the provider’s target (e.g. token1.dkim.amazonses.com).

Step 3: Just added the record? Query your nameserver directly

Just like we covered in our DNS negative caching note, if you just clicked “Save” in Cloudflare, your local Wi-Fi or ISP router might still think the record doesn’t exist.

Bypass the middleman by querying your domain’s authoritative Cloudflare nameserver (lewis.ns.cloudflare.com) directly:

Resolve-DnsName -Name "selector._domainkey.hardenedhost.com" -Type TXT -Server lewis.ns.cloudflare.com

[!TIP] PowerShell Reminder: If you see a red message saying DNS name does not exist, double-check the spelling of your selector name. The nameserver is successfully answering your query—it is just confirming that no record with that exact selector exists yet.

How to tell if your key is strong (1024-bit vs 2048-bit)

Security baselines require 2048-bit RSA keys. You can quickly tell if a DKIM key is modern or outdated by checking the length of the p= public key string:

  • 2048-bit key (Secure): The p= value is roughly 390+ characters long.
  • 1024-bit key (Outdated): The p= value is only about 210 characters long. If your provider generated a 1024-bit key, consider regenerating it as 2048-bit for better domain reputation.