Skip to content
StoutNook
Menu
Every tool runs in your browser. Your files never leave your device.

DKIM checker

Enter a domain and its DKIM selector, or let us try the common ones, to find the public key mail servers use to verify your signed email. You'll see the key type and length and any problems with the record.

Leave the selector blank to try 43 common ones, or paste a whole name such as google._domainkey.example.com.

Public DNS lookup. Only the domain, selector and record names (such as google._domainkey.example.com) are sent, to Cloudflare's DNS resolver.

You'll see the DKIM public key, its type and size, every tag explained and any problems with fixes. Without a selector, we try the common ones.

  • Looks up public DNS records only
  • Free, no sign-up
  • Works on phone and desktop

How to check a DKIM record

  1. 1

    Type your domain, such as example.com.

  2. 2

    Add the selector if you know it, or leave it blank to try the common ones.

  3. 3

    Click Check DKIM to see the public key, its type and length, and every tag explained.

  4. 4

    Fix anything flagged, such as a 1024-bit key or testing mode, then check again.

Features

  • Key type and length

    Reads the public key itself to report RSA or Ed25519 and its exact size, so weak and broken keys stand out.

  • Finds common selectors

    No selector? We try the ones used by Google Workspace, Microsoft 365, Mailchimp, SendGrid and other services.

  • Follows CNAMEs

    Many providers publish your key through a CNAME. We follow it and tell you where it points, or that it points nowhere.

  • Public DNS only

    Only the selector and domain names are looked up, through Cloudflare. No emails are sent and nothing is stored.

What DKIM does

DomainKeys Identified Mail (DKIM, RFC 6376) adds a digital signature to every message you send. Your email service signs the headers and body with a private key it keeps secret, and publishes the matching public key in your DNS. A receiving server fetches the public key, checks the signature, and so knows two things: the message was signed by your domain, and nobody changed it on the way.

Unlike SPF, a DKIM signature usually survives forwarding, because it travels with the message rather than depending on which server delivered it. That makes DKIM the more reliable half of DMARC.

How to read a DKIM record

The key for selector google on example.com lives at google._domainkey.example.com and looks like this (shortened):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3b…IDAQAB
TagMeaning
v=DKIM1Version. Optional, but if present it must come first.
k=rsaKey type: rsa (the default) or ed25519 (RFC 8463).
p=The public key in base64. Empty means revoked.
t=y / t=sTesting mode, or no subdomains in the signing identity.
h=, s=, n=Allowed hashes, service type, and notes. Rarely needed.

A 2048-bit key is longer than the 255 characters one DNS string can hold, so it's stored as two or more strings. Receivers join them with nothing in between, so a missing or extra character at the join breaks the key. This checker joins them the same way and reports a key that can't be read.

Key length: why 2048 bits

RFC 8301 (2018) updated DKIM's cryptography: signers must use RSA keys of at least 1,024 bits and should use at least 2,048; receivers must not accept signatures from shorter keys; and the old rsa-sha1 algorithm must not be used at all. Google's sender guidelines require a key of 1,024 bits or more for Gmail and recommend 2048.

  • 512 or 768 bits: broken. Receivers reject the signatures, and 512-bit keys can be factored cheaply.
  • 1024 bits: still accepted, but weak. Plan a rotation.
  • 2048 bits: the recommended size, supported by every major provider.
  • Ed25519: a newer, compact key type. Not every receiver verifies it yet, so it is published alongside an RSA key.

Finding your selector

Each email service picks its own selector. Google Workspace uses google unless you change it, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1 to k3, and SendGrid uses s1 and s2. Leave the selector blank and this tool tries these and other common ones. Not finding a key proves nothing, though: the real answer is in the s= tag of the DKIM-Signature header of a message you've sent.

Common DKIM problems

  • Record at the wrong name. Some DNS hosts append your domain automatically, so entering the full name creates google._domainkey.example.com.example.com. Enter only google._domainkey.
  • Dangling CNAME. Microsoft 365, SendGrid and others ask you to add CNAMEs that point at keys they host. If the service hasn't enabled signing yet, the CNAME leads nowhere.
  • Testing mode left on. t=y asks receivers to treat signed mail like unsigned mail. Remove it once signing works.
  • Truncated key. A key pasted with a character missing, or with quotes inside it, can't be read.

To rotate a key safely, publish the new key under a new selector, switch signing to it, wait a few days for mail in transit to arrive, then empty the old key's p= and later delete it.

DKIM, SPF and DMARC

DMARC passes when either SPF or DKIM passes for a domain that aligns with the From: address. For DKIM, the signing domain in d= must match your From: domain, or share its organizational domain under relaxed alignment. A message signed only by your email provider's own domain passes DKIM but not DMARC. Check the other pieces with the SPF checker and DMARC checker, and see where your mail is delivered with an MX lookup.

Frequently asked questions

What is a DKIM selector?

A name that tells receivers which of your keys signed a message, so a domain can have several keys at once (one per email service, or an old and a new key during rotation). The key lives at <selector>._domainkey.<domain>, and the selector appears as s= in the DKIM-Signature header of every signed message.

Why can't the checker find my DKIM record?

Usually because the selector is different from the ones we try: selectors can be any name. Find the real one in a message's DKIM-Signature header. Other causes: the record isn't published yet, a CNAME points to a name that doesn't exist, or your DNS host added your domain twice (selector._domainkey.example.com.example.com).

Is a 1024-bit DKIM key still OK?

It still works: RFC 8301 sets 1,024 bits as the minimum receivers accept, and Gmail requires at least 1024. But the same RFC says signers should use 2,048 bits, and Google recommends 2048, so rotate to a 2048-bit key when you can. Keys shorter than 1,024 bits fail everywhere.

What does an empty p= mean?

The key has been revoked on purpose. Mail signed with that selector fails DKIM. It is normal for an old selector after a key rotation, but a problem if it is the selector your mail is still signed with.

Does DKIM stop spoofing on its own?

No. DKIM proves a message was signed by a domain and not changed, but the signing domain can differ from the From: address. DMARC connects the two: it requires the DKIM signing domain (or the SPF domain) to align with From:, and tells receivers what to do when it doesn't.

Can I use more than one DKIM key?

Yes, and most domains do: one selector per service that sends your mail (for example Google Workspace and a newsletter service), each with its own key. Each service signs with its own selector.

More free tools