Free DKIM Record Checker

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify email authenticity.

A selector is a label used to distinguish between multiple DKIM keys on the same domain (e.g., google, mail, s1).

Yes, completely free.

Absolutely. The DKIM Record Checker processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the DKIM Record Checker is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the DKIM Record Checker in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The DKIM Record Checker works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

There is no DNS command that lists every selector on a domain, because DKIM records sit at a specific hostname — selector._domainkey.yourdomain.com — and you can only query a name you already know. The fastest way to learn yours is to open a recent message your domain sent and read the DKIM-Signature header: the s= tag is the selector. If you cannot see headers, the selector almost always matches your sending platform's default, such as google for Google Workspace, k1 or mandrill for Mailchimp, s1 and s2 for SendGrid, or protonmail for Proton. This checker lists those common selectors as one-click buttons, so you can try each one in seconds until the record resolves and confirm which key your provider is actually publishing.

The p= tag holds the public key that receiving servers use to verify your signatures, so an empty p= is not a harmless blank — it is an explicit revocation. Publishing p= with no value tells the world that any key previously associated with that selector is no longer valid, and mail signed with it will fail the DKIM check. Providers do this intentionally when they retire a selector after a key rotation, but it also happens by accident when a record is copied incorrectly or truncated in a DNS editor. If legitimate email suddenly fails authentication, an empty key on your active selector is a prime suspect. This tool flags a missing p= as revoked rather than valid, so you can spot a dead key immediately and republish a fresh record.

A 1024-bit RSA key still produces valid signatures and will pass authentication today, but it is no longer the recommended standard. NIST and most major mailbox providers now treat 2048-bit as the baseline for DKIM, because 1024-bit keys are considered increasingly feasible to break given modern computing power. The practical risk is that an attacker who factors the key could forge signed mail from your domain. Upgrading means generating a new 2048-bit key at your email provider, publishing the new public key under a fresh selector, and removing the old one once mail flows cleanly. This checker estimates the key size from the published public key and rates it strong at 2048 bits or more, adequate at 1024, and weak below that, so you can see at a glance whether your record needs an upgrade.

When you move to a new sending platform, the new provider signs your outgoing mail with its own private key under its own selector — and that key only works if the matching public key is published in your DNS. Failures usually happen because the old provider's selector is still in place while the new one was never added, or the new TXT record was pasted incorrectly and the public key is malformed. The receiving server looks up the selector named in each message's signature, so if that exact hostname has no valid record, verification fails and DMARC may quietly reject the mail. After any provider change, check the new selector here to confirm the record resolves and the public key is present, then remove the stale selector so old, unsigned configurations cannot cause confusion.

The three work together but check different things. SPF publishes a list of IP addresses and servers allowed to send mail for your domain, so a receiver can confirm the message came from an authorized source. DKIM adds a cryptographic signature to each message and publishes the public key in DNS, proving the mail genuinely came from your domain and was not altered in transit. DMARC ties them together: it tells receivers what to do when SPF or DKIM fails — none, quarantine, or reject — and where to send reports. A strict DMARC policy needs at least one of SPF or DKIM to pass and align, which is why a broken DKIM record can quietly suppress your reach. Use this checker to confirm the DKIM piece is healthy before tightening your DMARC policy.