DKIM Checker

Enter a domain to check all DKIM selectors. Shows the email provider, key strength, and CNAME delegation.

Try an example: mimecast.com · github.com · shopify.com

Check a Custom Selector

Enter a specific DKIM selector to look up. Separate multiple selectors with commas.

How this DKIM checker works

DKIM (RFC 6376) is the cryptographic signature your mail server attaches to outgoing messages. Receivers use it to check that the mail really came from your domain and wasn't edited along the way. The signature itself sits in the message headers. The public key receivers need to verify it sits in DNS, under a per-sender label called a selector.

Type a domain above and the tool queries over 500 known selectors covering the major providers (Google Workspace, Microsoft 365, SendGrid, Mailchimp, Amazon SES, Postmark, Mailgun) plus a long tail of smaller relays. Every key we find is listed with its algorithm and bit length. Weak or revoked keys get flagged. If your selector isn't in the list, paste it into the custom-selector field at the bottom and we'll fetch it directly.

What is a DKIM selector?

A selector is the label that sits before ._domainkey in the DNS lookup. Different providers, different selectors: 

google._domainkey.example.com       ← Google Workspace
selector1._domainkey.example.com    ← Microsoft 365
k1._domainkey.example.com           ← Mailchimp

The selector lives under your domain, but each provider gets its own label. That's what lets you run a dozen senders side by side without them stepping on each other. To see which selector signed a specific message, look at the s= tag inside that message's DKIM-Signature header.

How many DKIM records should I have?

One per service that sends mail as you. Three or four is normal. Ten is not unusual on marketing-heavy stacks. Each provider can rotate its own key without coordinating with the others, which is the whole point of selectors.

Key strength is what trips most domains up

RFC 8301 raised the minimum DKIM signing key from 1024 to 2048 bits in 2018. The trigger was Zachary Harris's 2012 result, where 1024-bit RSA keys at Google, Yahoo and PayPal turned out to be factorable on rented EC2 hardware in a weekend. Google has quietly soft-failed 1024-bit signatures for years.

Our take: rotate anything under 2048 today. Ed25519 (RFC 8463) is smaller and faster, and the cryptography is fine, but receiver support is still patchy. RSA-2048 is still the safe pick.

Why this matters now

Google and Yahoo require DKIM (along with SPF and a DMARC policy) for any sender pushing more than 5,000 messages a day. That rule has been in force since February 2024. Microsoft turned the same rule on for Outlook.com, Hotmail and Live in May 2025. Mail that fails the check bounces with 550 5.7.515.

What to do: if any selector here shows a weak key, book a rotation for this quarter. The DKIM key generator creates a fresh 2048-bit pair in your browser.

Empty p= is not a bug, it's a signal

An empty p= tag is DKIM's revocation marker. The selector still resolves in DNS, but the key behind it has been withdrawn. Any signature pointing at that selector verifies as invalid. Providers leave revoked selectors in place so older queued mail doesn't suddenly look tampered with.

For a domain that doesn't send mail at all, publish the M3AAWG non-sending posture: 

*._domainkey.example.com  TXT  "v=DKIM1; p="

Pair that with v=spf1 -all and v=DMARC1; p=reject; and the domain is locked down against spoofing without breaking anything that was actually sending. The checker treats this case as a positive verdict, not a missing-key error.

Where to go next

For the rest of the authentication stack, see the DMARC checker and the DMARC tags reference. If SPF needs work, the SPF builder generates a validated record. Some providers publish their selector as a CNAME alias to their own infrastructure rather than as a direct TXT record. In that case the CNAME checker is what you want.

Frequently Asked Questions

Common questions about DKIM and email sender authentication.

RSA-2048. Ed25519 keys are smaller and faster and the cryptography is fine, but receiver support is uneven. Some receivers treat an Ed25519-only signature as no signature at all.

If you want Ed25519 anyway, dual-sign. Publish both an RSA-2048 selector and an Ed25519 selector, and have your provider sign with both. Receivers verify whichever one they understand. Most providers don't expose dual signing as a checkbox yet, so plain RSA-2048 is the easier route.

Keys below 2048, almost always 1024-bit, should be rotated regardless. Google has been silently soft-failing them for years.

It's the revocation signal. The selector still exists in DNS so historical references don't 404, but the key is gone. Any signature claiming that selector verifies as invalid.

Sending providers leave revoked selectors in place on purpose. Deleting them would make older queued mail suddenly look tampered with. The wildcard form, v=DKIM1; p= published at *._domainkey.<domain>, is the M3AAWG-recommended posture for parked domains, and the checker treats it as a positive signal rather than a missing key.

DKIM signs a canonicalised version of the body and a chosen set of headers. A forwarder that prepends a banner, rewrites the subject, or strips the Message-ID breaks one of those hashes, and the signature stops verifying. This is the failure mode behind most "DKIM was fine yesterday, why is it failing now" tickets.

The fix is at the forwarder, not at you. ARC (RFC 8617) seals the original authentication results so downstream receivers can still trust them. Most major mailing-list software now applies ARC by default.

If you control the signing side and want to harden against minor edits, use relaxed header canonicalisation (c=relaxed/relaxed). That survives whitespace fixes and header refolding. It won't save you from a forwarder that actually edits the body.