Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — DKIM Checker

No selector? We'll find it.

Enter a domain and we detect your mail provider from MX, probe its selectors and a broad catalog, and analyze every key we find — RSA or Ed25519, exact bit length, revoked keys, test mode, and SHA-1. Runs in your browser, nothing sent.

Request infrastructure review Key strength

Detects your provider from MX, probes its selectors, and decodes each key's length locally. Nothing is sent or stored.

/ What this does

DKIM signs your mail with a private key and publishes the matching public key in DNS at a selector — an arbitrary label most people never learn. This checker gets around that: it reads your MX records to identify your provider, tries that provider's selectors first, then a broad catalog, and for every key it finds it decodes the public key to report the exact type and bit length, whether the key is revoked, and whether test mode is quietly nullifying it. Finding the selector is half the job; the key still has to be strong.

Each result names the provider, shows RSA versus Ed25519, and grades the key — broken below 1024 bits, weak at 1024, sound at 2048, strong at 4096 — alongside the flags that make a technically-present key do nothing: an empty p= that means revoked, a t=y that means test mode. If nothing is discovered, enter the exact selector from a sent message's DKIM-Signature header, and the tool analyzes that one directly.

  • No selector needed

    Detects your provider from MX and probes its selectors plus a broad catalog, naming the provider behind each key it finds.

  • Exact key length

    Decodes each public key in your browser to report its real bit length, flagging anything below the 2048-bit standard.

  • Revoked & test mode

    Catches an empty p= (revoked key) and a lingering t=y (test mode) — the two quiet ways DKIM ends up doing nothing.

  • Browser-only

    Lookups are read-only DNS-over-HTTPS; key decoding uses your browser's cryptography. Nothing is sent to us or logged.

/ Key strength

How strong does a DKIM key need to be?

For RSA, 2048 bits is the standard in 2026, and the reasoning is settled rather than a matter of taste. RFC 8301 requires receiving servers to reject any key under 1024 bits and recommends 2048, NIST deprecated 1024-bit RSA years ago, and the major mailbox providers reject 1024-bit signatures from bulk senders. A 1024-bit key still technically validates in some places, but it sits on a deprecation path and offers a thin security margin — the kind of thing that passes today and fails after the next provider policy change.

Below that, keys leave weak behind and become broken outright. A 768-bit RSA key was publicly factored back in 2009, and 512-bit keys fall in hours on ordinary hardware. A key that short is worse than publishing none, because a valid-looking DKIM signature gives receivers and your own team false confidence while an attacker who factors the key can sign mail as you at will. This is why the tool grades by real bit length rather than merely confirming a key exists — presence and strength are different questions, and only one of them protects you.

Ed25519 is the modern alternative, standardized for DKIM in RFC 8463: a fixed 256-bit key with security comparable to RSA-3072, in a record a fraction of the size. The one caveat is support — as of 2026, Google and Fastmail verify Ed25519 while Microsoft 365 and Yahoo still don't, so signing with it alone leaves those receivers unable to validate you. The safe pattern is dual signing: publish an RSA-2048 key and an Ed25519 key under separate selectors, and a single pass from either satisfies DMARC. The tool identifies which algorithm each selector uses so you can see whether you're set up for that.

/ The quiet failures

Why does a published DKIM key still do nothing?

A DKIM record can be present and correct-looking while contributing nothing, and there are two classic ways it happens. The first is a revoked key: a record whose p= tag is empty. Per RFC 6376 that's the defined way to retire a key — the selector stays published so old signatures resolve, but the key itself is dead. During a rotation that's exactly right. Left in place months later, it's a selector that answers DNS but authenticates nothing, and anyone reading only "record exists" would miss it.

The second is test mode, the t=y flag. It tells receivers to evaluate the signature but treat the message as though it were unsigned, which is meant for the first days of a rollout while you confirm signing works. The trap is that it's routinely forgotten after go-live, so a domain that looks fully signed is having every signature discounted. Both of these are invisible to a checker that only confirms a key is present, which is why this tool reads the flags and calls them out.

The larger discipline is rotation. Keys should turn over once or twice a year, and immediately if a private key might be exposed, because a leaked key lets an attacker sign as you until it's revoked. The hard part isn't generating new keys — it's knowing which old selectors are safe to remove, since a key still signing forwarded or delayed mail can't be pulled yet. Publish new, switch signing, confirm it resolves, then revoke the old with an empty p= before removing it. Running that cycle cleanly as you add and drop sending services is the ongoing operation behind a healthy DKIM setup.

/ DKIM FAQ

Do I need to know my DKIM selector?
No — that's the point. A selector is an arbitrary label your provider chose, and most people don't know theirs. This checker reads your MX records to identify your mail provider, tries that provider's known selectors first, then falls back to a broad catalog of common ones. It names the provider for each key it finds. What it can't do — no tool can — is guess a custom or randomly generated selector, because DNS doesn't allow listing a zone's selectors. If nothing is found, open a message you sent, view the headers, and read the s= tag in the DKIM-Signature line, then enter that selector directly.
What key length should my DKIM use?
Use 2048-bit RSA as the minimum in 2026. RFC 8301 requires verifiers to reject keys under 1024 bits and recommends 2048, NIST deprecated 1024-bit RSA years ago, and Google, Microsoft, and Yahoo reject 1024-bit signatures from bulk senders. Anything at 512 or 768 bits is broken — those sizes have been publicly factored — and a key that short is worse than none because it gives false confidence. 4096-bit works but not every DNS provider handles the larger record cleanly, since a key that long must be split across multiple quoted strings in the TXT record. The tool decodes each key and reports its exact bit length, flagging anything below 2048.
What is RSA versus Ed25519 for DKIM?
RSA is the universal standard — supported everywhere, at the cost of a large key and signature. Ed25519 (RFC 8463) is modern: a fixed 256-bit key, far smaller records, faster signing, with security equivalent to RSA-3072. The catch in 2026 is support: Google and Fastmail verify Ed25519, but Microsoft 365 and Yahoo still don't. Signing only with Ed25519 means those receivers can't validate you. The safe move is dual signing — publish both an RSA-2048 key and an Ed25519 key under separate selectors, and a single pass from either satisfies DMARC.
What does a revoked key or test mode mean?
A revoked key is a DKIM record that exists but has an empty p= tag (RFC 6376). The selector is still published, but the key is intentionally dead — normal during rotation, suspect if it lingers after one. Test mode is the t=y flag: it tells receivers to treat the signature as if the message were unsigned, which is meant for initial rollout and is frequently left on by accident after going live, quietly nullifying your DKIM. The tool flags both, because a revoked-but-forgotten selector and a stuck test flag are two of the most common ways DKIM silently does nothing.
How often should I rotate DKIM keys?
At least once or twice a year, and immediately if a private key may have been exposed. Rotation limits the window in which a leaked key can be used to sign mail as you, and old vendor keys left published long after a service is gone are a real liability — whoever still holds that private key can sign as your domain. The clean process is to publish a new selector, switch signing to it, confirm it resolves, then revoke the old one with an empty p= before removing it. Knowing which old selectors are safe to retire is where signing-activity data helps.
Does the checker send or store anything?
No. Every lookup is a read-only DNS-over-HTTPS query run in your browser, and the key analysis — decoding the public key to determine its length — happens locally using your browser's built-in cryptography. Nothing is sent to our servers, no email is dispatched, and your domain isn't logged.

Strong keys, no forgotten selectors. That takes upkeep.

DKIM stays healthy only when keys are strong, rotated on a schedule, and retired once unused — across every service that signs for you. Keeping that clean as your sending grows is continuous work, and it's what we operate. Check your keys, then bring us the rotation.

Book infrastructure review

Related capabilities