DKIM record checker.
Probe twelve common selectors or enter your own, then validate the public key. Use it after a client provider setup or rotation to catch weak, revoked, and broken keys.
More than a TXT lookup.
A DKIM record can exist and still fail every signature check. The checker parses each key the way a receiving mail server does and validates the actual key material.
selector discovery
DKIM keys live at <selector>._domainkey, and the selector is anything the sender chose. We probe twelve selectors used by Microsoft 365, Google Workspace, Mailchimp, and other major senders — or check exactly the one you give us.
key material validation
The p= tag must hold a real base64-encoded public key. We decode it and parse the underlying RSA or Ed25519 key, so corrupted copy-paste jobs that look fine in DNS get caught.
key strength
1024-bit RSA keys are considered breakable and some receivers already distrust them. We measure the actual modulus and flag anything under 2048 bits.
revoked keys
An empty p= tag means the key was revoked. Legitimate as a cleanup step, but mail still signed with that selector fails DKIM — we surface it so nothing signs with a dead key.
record syntax
Version tags that aren't DKIM1, missing public key tags, unsupported key types, and multiple TXT records on one selector — each one breaks verification in its own way.
CNAME delegation
Providers like Microsoft 365 publish your keys behind CNAMEs. We follow the delegation and show where each selector actually points, so broken handoffs are visible.
The DKIM mistakes we see most.
signing was never turned on
The provider published the keys, but signing was never enabled in the sending platform — common after Microsoft 365 setups, where the CNAMEs exist but DKIM sits disabled in the admin center.
1024-bit keys left behind
Keys generated years ago default to 1024-bit RSA. They still verify today, but they are considered breakable and receivers increasingly penalize them. Rotate to 2048-bit.
broken copy-paste
DKIM keys are long, and DNS interfaces love to mangle them: truncated base64, stray whitespace, or a record split across quoted chunks incorrectly. The record exists; the key inside it doesn't parse.
dead CNAME delegation
The selector CNAME points at a provider you left, or at a hostname the provider deleted. Every signature referencing that selector now fails, silently.
key rotation that removed the old key too soon
Mail already in transit is signed with the old selector. Delete the old key the moment the new one goes live and that in-flight mail fails verification.
DKIM questions, answered.
DKIM (DomainKeys Identified Mail) lets a sending server cryptographically sign each message. The signature travels in the message headers, and the matching public key is published as a DNS TXT record at <selector>._domainkey.yourdomain.com. Receivers fetch the key, verify the signature, and use the result for spam filtering and DMARC.
A selector is the name the sender chose for a key, and it becomes part of the DNS location: selector s1 for example.com means the key lives at s1._domainkey.example.com. Selectors let a domain publish many keys at once — one per provider, or old and new keys during rotation. Each signed message names its selector in the s= tag of the DKIM-Signature header.
Open a message you sent and view its full headers: the DKIM-Signature header's s= tag is the selector. Common defaults are selector1 and selector2 (Microsoft 365), google (Google Workspace), and k1 (Mailchimp). This checker probes twelve common selectors automatically, and you can enter a custom one if yours isn't in the list.
It verifies today, but 1024-bit RSA is considered breakable with realistic resources, and RFC 8301 requires verifiers to support 2048-bit keys. Some receivers already treat shorter keys as weak or ignore them. If your provider still signs with 1024-bit keys, rotate to 2048-bit — most platforms now generate them by default.
Publish a new key under a new selector, switch signing to it, then wait before removing the old key — mail signed before the switch still references the old selector while it is in transit. To revoke a key explicitly, publish it with an empty p= tag. Providers that use CNAME delegation typically rotate keys for you.
Yes. SPF breaks when mail is forwarded and only checks the envelope sender, while a DKIM signature survives forwarding and covers the message itself. DMARC passes when either SPF or DKIM passes and aligns with the visible From address — so having both means one can fail without your mail going to spam.
The published key is only half the system — the sending server must actually sign with it. Common causes: signing is disabled at the provider, the message was signed with a selector whose key was deleted, the key was rotated mid-transit, or a mailing list modified the message after signing. Check the DKIM-Signature header of a failing message and compare its s= tag with the selectors published in DNS.
A healthy DKIM key is one part of the client domain.
The free scan checks email auth & DMARC, SSL & domain expiry, look-alikes, and blacklists together from public records. One result, no signup.
Keep checking the same failure point.
Use the related tools one at a time, or run all four posture checks together.
DNS lookup →
Query A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA records in parallel and share one result.
SPF record checker →
Follow every include, count the 10-lookup limit, and flag syntax errors or unsafe policies.
DMARC record checker →
Parse every DMARC tag, grade the policy, and flag weak enforcement or missing reporting.