How to Check DKIM Is Set Up After Switching Email Provider

After a switch, check that every sending domain publishes the new provider's DKIM key, at the selector that provider signs with. Enter that selector in the bulk DKIM checker and paste all your domains: each row shows whether the key is there, its length, and any error, such as a CNAME pointing at nothing.

Check DKIM on a list of domains →

Check them in bulk

1. Open the bulk DKIM checker.
2. Paste the sending domains, one per line: up to 100 a run, or 500 after a free Google sign-in.
3. Enter the new provider's selector: google for Google Workspace, selector1, selector2 for Microsoft 365, or the one your ESP shows on its DNS setup page. Up to three, separated by commas. Leave it blank to try 22 common selectors.
4. Press Check DKIM.
5. Read each row: Key found, Weak key, Testing, Revoked, Broken, CNAME to nothing or No key found. Download the CSV.

Do it by hand

printf "github.com\nstripe.com\nnotion.so\n" > domains.txt
sel=google

while read -r d; do
  key=$(dig +short txt "$sel._domainkey.$d" | grep -v '\.$' | tr -d '" \n')
  if [ -z "$key" ]; then echo "$d,$sel,NO KEY"; continue; fi
  bits=$(echo "$key" | sed 's/.*p=//; s/;.*//' | base64 -d 2>/dev/null \
    | openssl pkey -pubin -inform DER -noout -text 2>/dev/null | sed -n 's/.*(\([0-9]*\) bit).*/\1/p')
  echo "$d,$sel,${bits:-unreadable} bit"
done < domains.txt
# github.com,google,2048 bit
# stripe.com,google,1024 bit
# notion.so,google,NO KEY

We ran this on 9 November 2026. grep -v '\.$' drops the CNAME line dig prints when the selector is delegated, so only the key is decoded. NO KEY for notion.so means only that it publishes nothing at the google selector; it may sign with another one.

Selectors that point at a provider show up as CNAMEs:

dig +short cname s1._domainkey.github.com
# s1.domainkey.u51742174.wl175.sendgrid.net.

The steps people miss after a switch

• Turning signing on. Google's Set up DKIM page has you add the DNS record first and click Start Authentication later, and says it can take up to 48 hours to start working. Microsoft 365 has you publish the CNAMEs, then enable signing; see Microsoft's DKIM guide.
• The right Microsoft target. Microsoft's guide says custom domains added since May 2025 get CNAME targets ending in dkim.mail.microsoft, while existing domains keep the older onmicrosoft.com format, and the two can't coexist for the same selector. Copy the values the Defender portal gives you, not ones from an old setup.
• Key length. RFC 8301 says signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits". Google's page says to choose 2048 if your DNS host supports it.
• The old provider's selector. Leave it in place until the old provider has stopped sending, so mail still in flight verifies. Then remove it or publish it empty (p=), which RFC 6376 defines as a revoked key.
• Proof from a real message. Send yourself a message and read the DKIM-Signature header: s= is the selector, d= the signing domain. If d= is the provider's domain rather than yours, DKIM won't align for DMARC.

For per-provider setup, see Google Workspace DKIM setup, Microsoft 365 DKIM setup and DKIM for every service that sends as your domain.

Next step: check the list before the first send

A provider switch is when old list problems show: the new platform judges you on your first sends. Upload the list at /verify to check every mailbox without sending. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.

More: deliverability dropped after switching ESP, switching email platforms? verify the list first.