DKIM Checker

Each record below is published at s1._domainkey.example.com and checked by entering selector s1 and domain example.com. Keys are shortened here.

2048-bit RSA key

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…

Result: RSA · 2048-bit, hash SHA-256, four of five strength segments, and all seven checks pass. Keys starting with MIIBIjAN are typically 2048-bit; 1024-bit keys usually start with MIGfMA0.

1024-bit key in testing mode

v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…

Result: RSA · 1024-bit with two of five strength segments, 5 passed and 2 to review — the key length and the t=y testing flag. The key still verifies, but it is due for replacement.

Ed25519 key

v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=

Result: Ed25519 · 256-bit, four of five strength segments, and all seven checks pass. This sample key from RFC 8463 shows the format: the 32-byte public key itself, Base64-encoded to 44 characters. A DER-wrapped key starting with MCowBQYDK2Vw is the wrong format. Ed25519 is usually published next to an RSA selector, because not every receiver verifies Ed25519 signatures yet.

Revoked selector

v=DKIM1; p=

Result: a Revoked badge, an empty strength meter, and failed checks for the public key and key length (0-bit) — expected for a selector you retired on purpose, a problem only if a server still signs with it.

If a service asks you to point s1._domainkey.example.com at s1.domainkey.example.net with a CNAME, the resolver follows it and the checker shows the TXT record at the target.

• Key type — taken from k=; RSA is shown when the tag is missing, because RSA is the default.
• Key size — for RSA, the modulus length decoded from p=. Ed25519 keys have a fixed size: a p= value that decodes to exactly 32 bytes is shown as 256-bit, anything else as 0-bit.
• Hash — the first algorithm listed in h=. When h= is absent the tool shows SHA-256, although an absent tag actually allows any algorithm.
• Strength — five segments: RSA 4096-bit and above fills all five, RSA 2048-bit and Ed25519 fill four, RSA 1024-bit fills two, smaller keys one, and a revoked key none.
• Keyprint and fingerprint — a pattern and a short SHA256: fingerprint derived from the key, handy for spotting whether a key changed after a rotation.
• Validation — seven checks: record found, the v=DKIM1 tag, key present and not revoked, a supported key type (rsa or ed25519), key length, t=y testing mode, and whether p= decodes to a well-formed key — a DER-encoded RSA public key for k=rsa, or exactly 32 raw bytes for k=ed25519.
• Record tags, Public key and Raw TXT record — every tag by name, the full Base64 key wrapped at 64 characters, and the record as a zone-file line.

Selectors exist so a domain can publish several keys at once — one per sending service, or an old and a new key during a rotation. A safe rotation runs in this order:

1. Generate a new key pair in your mail server or provider and publish the public key under a new selector, for example s2 next to the current s1.
2. Check s2 here: it should be found, 2048-bit RSA or Ed25519, and without t=y.
3. Switch signing to s2, send a test message and confirm that the s= tag in its DKIM-Signature header now reads s2.
4. Keep s1 published for a while, because messages signed with it may still be queued or re-verified later.
5. Retire s1 by publishing an empty p= or deleting the record. Checking s1 should then show the Revoked badge or no record.

The same steps upgrade a 1024-bit key to 2048-bit. A 2048-bit key exceeds the 255-character limit of one TXT string, so it is published as several quoted strings in one record; the checker joins them before parsing.

No DKIM record for the selector

• Wrong selector or domain: copy s= and d= from the DKIM-Signature header of a message that was actually sent.
• Domain added twice: many DNS panels append the zone automatically, so entering the full name as the host creates s1._domainkey.example.com.example.com. Enter only s1._domainkey in those panels.
• A typo in _domainkey (the underscore is required), or a CNAME target the provider has not activated yet.
• DNS errors, timeouts and recently added records that are still cached as missing all look like a missing record. Query the name with the DNS lookup tool (TXT or CNAME) to see the raw answer.

Key length shows 0-bit or the public key check fails

The p= value could not be decoded as a public key. Typical causes are a key truncated while pasting, quote characters from a split string ending up inside the value, or a PEM header such as -----BEGIN PUBLIC KEY----- published with the key. Publish only the Base64 body. For k=ed25519, publish the raw 32-byte key (44 Base64 characters); a DER-wrapped key starting with MCowBQYDK2Vw is the wrong format and fails the check.

Weak key or testing flag

1024-bit RSA still verifies but is flagged; rotate to 2048-bit with a new selector. t=y tells verifiers the domain is only testing DKIM, so signed mail gets no different treatment from unsigned mail — remove it once signatures verify.

The key is valid but DMARC still fails

A valid key only proves the signature can be verified. For DMARC, the d= domain must also align with the visible From: domain — a service signing as its own domain does not count. Review the policy and alignment mode with the DMARC policy checker.

• It cannot list selectors. DNS offers no way to enumerate names under _domainkey, so you need the selector from a message header or your provider.
• It reads one TXT record per selector, preferring one that contains v=DKIM1 and otherwise using the first record with a p= tag.
• The s=, n= and g= tags are listed but not evaluated, and h=sha1 is not flagged.
• Both fields are required. A pasted full selector._domainkey.domain name in the selector box is trimmed to the selector.
• Answers come from the DNS resolver used by the helpers.work server. To see how DKIM fits with sender authorization, check the SPF record checker and read SPF, DKIM and DMARC explained.