Free DKIM Record Checker
Auto-discovers DKIM selectors based on your mail provider (Google Workspace, Microsoft 365, OVH, Mailchimp, SendGrid…) — or enter a selector manually. Validates key length and surfaces the raw record.
Leave selector empty to auto-discover. We detect the provider from your MX records and try the right selectors.
DKIM the way real receivers see it
DKIM records hide behind opaque selectors. Most checkers ask you to type the selector by hand and stop there — useless if you don't already know it. Ours figures it out.
Provider-aware probe
Detects your mail provider from MX records, then tries the selectors it actually uses — google for Workspace, selector1/selector2 for Microsoft 365, k1/k2 for Mailchimp, and a dozen more.
CNAME chain follow
Microsoft, Mailchimp and many SaaS publish DKIM as a CNAME pointing at the vendor's TXT. Our probe follows the chain so you see the actual key, not just a redirect.
Weak-key detection
Flags keys under 1024 bits as weak per RFC 8301. A 768-bit RSA key in your DKIM record is a deliverability and security red flag — we'll tell you to ask your provider to regenerate.
Common DKIM selectors by provider
Need to enter a selector manually? Here are the ones the major mail platforms publish.
| Provider | Typical selector(s) | Record name format |
|---|---|---|
| Google Workspace / Gmail | google._domainkey.example.com | |
| Microsoft 365 | selector1, selector2 | selector1._domainkey.example.com |
| OVH | mxvault, ovhmo-selector1 | mxvault._domainkey.example.com |
| Mailchimp / Mandrill | k1, k2, k3 | k1._domainkey.example.com |
| SendGrid | s1, s2, m1 | s1._domainkey.example.com |
| Mailgun | k1, mg | k1._domainkey.example.com |
| Postmark | pm | pm._domainkey.example.com |
| Zoho Mail | zoho, zmail | zoho._domainkey.example.com |
| Fastmail | fm1, fm2, fm3, mesmtp | fm1._domainkey.example.com |
| ProtonMail | protonmail, protonmail2 | protonmail._domainkey.example.com |
| Amazon SES | amazonses (or custom) | {selector}._domainkey.example.com |
| HubSpot | hs1-_domainkey, hs2-_domainkey | hs1-_domainkey.example.com |
Why monitoring DKIM matters
DKIM keys aren't write-once-and-forget. RFC 8301 recommends rotation; major providers like Google rotate automatically. A new key appearing in your DNS is most often a planned rotation — but it can also be a hijacked DNS record or a mail vendor pushing their own signing material onto your domain.
More mundanely, a DKIM record that vanishes or gets corrupted by a copy-paste error silently degrades your deliverability for everyone you mail. There's no error message — your campaigns just start hitting spam.
DNSMonit checks every DKIM selector for your domain hourly. If the published key changes, gets removed, or starts pointing somewhere unexpected, you get an email within an hour.
DKIM Checker — Frequently Asked Questions
What is a DKIM record?
DKIM (DomainKeys Identified Mail) is a DNS TXT record that publishes the public half of a cryptographic key used to sign outgoing mail. Receivers verify the signature with this public key to confirm the message wasn't forged or tampered with in transit.
Why does DKIM need a selector?
DKIM records live at <selector>._domainkey.<domain>, so a domain can publish multiple keys at the same time — one per service or rotation period. Each mail vendor uses its own selector (Google: 'google', Microsoft: 'selector1', Mailchimp: 'k1', etc.).
How does this DKIM checker discover selectors?
It first reads your MX records to identify the mail provider, then queries the selectors that provider commonly publishes (e.g. selector1/selector2 for Microsoft 365). If no provider is recognized, it falls back to a short list of generic selectors. You can also enter a specific selector manually.
Do I need DKIM if I have SPF?
Yes. SPF and DKIM are independent: SPF authorizes sending IPs, DKIM cryptographically signs messages. DMARC requires at least one of them to pass with proper alignment. Most mailbox providers downrank mail that has only SPF, with no DKIM signature.
Should I rotate DKIM keys?
Yes — yearly is the common recommendation, and major providers (Google, Microsoft) rotate automatically. The risk of leaving a single key in place is that a leak gives attackers years of usable signing material. DNSMonit alerts you when the published key changes so you notice rotations (planned or otherwise).
What does the 'key length' warning mean?
DKIM keys shorter than 1024 bits are considered weak. RFC 8301 says signers MUST use at least 1024 bits and SHOULD use 2048+. If our checker reports a short key, ask your mail vendor to regenerate.
Be the first to know when a DKIM key rotates
DNSMonit tracks every DKIM selector on every domain you monitor and emails you the moment a key changes — planned rotation or otherwise.