DKIM Record Checker
Enter a domain and DKIM selector to fetch the published public key, confirm it parses, and verify the signing setup that lets receivers detect tampered or forged mail. Reads public DNS only.
Live DNS lookup via DNS-over-HTTPS. We only read public DNS records.
How the DKIM check works
Enter your domain and a selector, and the tool looks up <selector>._domainkey.<domain> in DNS. It confirms the record parses as DKIM (v=DKIM1), checks that a public key is published (and not empty/revoked), and reports the key type and whether testing mode is on.
Finding the right selector
The selector isn't guessable — it's set by whoever sends your mail. The reliable way to find it is to open a message you've sent, view its raw headers (try the email header analyzer), and read the s= value from the DKIM-Signature line. Then confirm the full picture with the DMARC and SPF checkers.
What each field of a DKIM TXT record means
A DKIM record is a single DNS TXT record made of semicolon-separated tag=value pairs. v=DKIM1 is the version tag and, when present, must come first; it tells a verifier the record follows the DKIM spec. k= names the key type and is rsa by default, with ed25519 now supported by many providers for shorter keys. p= holds the base64-encoded public key that receivers use to check the signature. A validator or dkim lookup that flags a malformed p= value usually points to a copy-paste error or a record split incorrectly across TXT strings.
Three optional tags shape how the key behaves. t=y puts the selector in testing mode, so receivers evaluate the signature but should not treat a DKIM failure as a reason to reject. h= lists the acceptable hash algorithms (for example h=sha256), letting you exclude weaker hashes like sha1. s= is the service type and defaults to * (all uses); setting s=email restricts the key to email service. You will also see n= for human notes, which verifiers ignore. When you run a dkim record check, confirm the tags actually match what your provider documents rather than assuming defaults.
Key length lives inside the base64 p= blob, not in a separate tag. A 1024-bit RSA key produces a short public key that fits in one TXT string, but 1024-bit is now considered weak and some receivers discount it. 2048-bit RSA is the current standard and is long enough that DNS often splits it into multiple quoted strings inside one TXT record, which is normal and gets concatenated on lookup. After you rotate to a longer key, use a dkim validator to confirm the record still parses, then cross-check delivery with the SPF checker and DMARC checker.
Common DKIM selectors by provider
The selector is chosen by whoever sends your mail, so there is no single value to guess. The list below covers the defaults most senders publish, which is a useful starting point for a dkim record check when you do not yet have a signed message to inspect.
- Google Workspace:
google(record atgoogle._domainkey.<domain>). - Microsoft 365:
selector1andselector2, published as CNAMEs whose exact target Microsoft 365 generates for your tenant (read it from the Microsoft 365 admin center orGet-DkimSigningConfig, since the format varies by tenant). - Mailchimp:
k1(older setups may usek2ork3). - SendGrid:
s1ands2, published as CNAMEs to SendGrid-hosted records. - Amazon SES: three token-named CNAME selectors that SES generates for you (long random tokens, not friendly names).
- Zoho Mail:
zmail. - Postmark: often
<hash>pmstyle selectors published as CNAMEs.
Because many providers publish the selector as a CNAME that points to a record they host, your dkim lookup should follow the CNAME to the final TXT so you see the real p= key. If two selectors are published (as with Microsoft 365 or SendGrid), only the one named in the active DKIM-Signature is signing right now; the second exists so the provider can rotate keys without downtime.
Frequently asked questions
What is a DKIM record and selector?
DKIM (DomainKeys Identified Mail) publishes a public key in DNS that lets receivers verify a message was signed by your domain and not altered in transit. The key lives at <selector>._domainkey.<domain>. The selector is a label chosen by your mail provider (for example 'google', 'selector1', or 'k1') so a domain can rotate or run multiple keys.
How do I find my DKIM selector?
Look at the DKIM-Signature header of a message you've sent: the s= tag is the selector and the d= tag is the domain. In a header trace you'll see something like s=google; d=yourdomain.com. Common selectors include google (Google Workspace), selector1/selector2 (Microsoft 365), and k1 (Mailchimp).
What does an empty public key (p=) mean?
If the record's p= value is empty, the key has been revoked and that selector can no longer sign or verify mail. A valid selector publishes a long base64 public key. An empty key on a selector you expect to be active is a misconfiguration to fix.
Does DKIM stop spoofing on its own?
Not by itself. DKIM proves a message was signed by the domain in the d= tag and wasn't modified, but a receiver only acts on that under a DMARC policy that requires alignment with the visible From: address. DKIM + SPF + DMARC together are what stop domain spoofing.
What DKIM key length should I use?
Use a 2048-bit RSA key. 1024-bit keys still validate, but they are considered weak by current standards and some receivers give them less weight, so 2048-bit is the recommended default for new setups. If your DNS provider limits a single TXT string to 255 characters, the 2048-bit key is split into multiple quoted strings inside one record, which is normal and gets joined back together during a check. Some providers also support ed25519 keys, which are much shorter, but publish an RSA key alongside them for receivers that do not yet support ed25519.
How often should I rotate DKIM keys?
A common practice is to rotate DKIM keys every 6 to 12 months, and immediately if you suspect a private key was exposed. The safe way to rotate is to publish a new selector and key, switch your mail platform to sign with the new selector, confirm live mail is validating on it, and only then revoke the old key by setting its p= value to empty (or removing the record). Keeping two selectors available at once, which providers like Microsoft 365 and SendGrid do by default, lets you rotate without a gap where mail is unsigned.
What does DKIM testing mode (t=y) do?
The t=y flag marks the selector as being in testing mode. Receivers should still evaluate the signature, but they are told not to treat a DKIM failure any more harshly than unsigned mail, so a broken signature will not cause rejection while you are testing. It is meant as a temporary setting during rollout so you can watch reports without risking delivery. Leaving t=y in place long-term weakens the protection, because it signals to receivers that failures on that selector can be ignored, so remove it once you have confirmed signatures pass.
Why does DKIM fail on some mailing lists but survive forwarding?
DKIM signs specific headers and the message body, so anything that modifies the signed content breaks the signature. Mailing lists frequently rewrite the subject (adding a list tag), append a footer, or convert the body format, and any of those changes invalidates the body hash, so DKIM fails at the far end. Plain forwarding that passes the message through untouched usually keeps DKIM intact, which is a key advantage over SPF: forwarding changes the sending server so SPF fails on the new hop, but an unmodified DKIM signature still validates because it does not depend on the connecting IP address.
Related free tools
Sign your mail. Protect your brand everywhere else.
DKIM secures email integrity. PhishEye handles the impersonation that happens on the web, in search, and on social.