DKIM Checker

What the DKIM Checker looks at

DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending server sign each message with a private key. Receivers fetch the matching public key from DNS and check the signature. If it verifies, they know the signing domain took responsibility for the message and that the signed parts weren't changed in transit.

The public key is published at:

<selector>._domainkey.<domain>

The checker:

• Looks up the TXT record (following a CNAME if your provider uses one).
• Checks the tags: v=DKIM1 if present, key type k= (default rsa; ed25519 is also defined), and the public key p=.
• Measures the RSA key length.
• Detects an empty p=, which means the key has been revoked.
• Flags syntax problems such as stray quotes or a key split incorrectly across strings.

Any selector names tried for you are a guess based on common conventions, not a scan. DNS can't list the selectors a domain uses.

How to read the results

• Pass. A valid key was found at the selector, with an RSA key of 2048 bits or more, or an Ed25519 key.
• Warning. A valid key that's weaker than recommended, such as 1024-bit RSA. Gmail accepts 1024 bits but Google recommends 2048.
• Fail. A record exists at the selector but can't be used: malformed, unknown key type, an RSA key under 1024 bits, or an empty p= you didn't intend.
• Not tested. We couldn't find any selector. This isn't a failure. DKIM selectors can be any name, so an unknown selector means "we don't know", not "broken". Enter the selector from a real message to get a definite answer.
• Not applicable. The domain sends no mail (for example, it publishes Null MX and v=spf1 -all), so DKIM isn't needed.

Finding your selector

1. Send a message from the account you want to test to any mailbox you can read.
2. Open the full headers (in Gmail: More > Show original; in Outlook: File > Properties > Internet headers).
3. Find the DKIM-Signature: header. It looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=selector1; h=from:to:subject:date; bh=...; b=...

4. Enter d= as the domain and s= as the selector.

Or paste the whole header into the Email Header Analyzer, which pulls these values out for you.

Common problems and fixes

No key at the selector. Your provider gives you the record to publish. Microsoft 365 uses two CNAME records (selector1 and selector2) that point to keys it hosts; Google Workspace gives you a TXT record from the Admin console. Publish exactly what they show, then turn signing on in the provider's console.

Key split wrongly. Long keys exceed 255 characters, so DNS stores them as several strings. Most DNS panels handle this; if yours doesn't, split the value into quoted chunks in one record:

s1._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
  "...IDAQAB" )

1024-bit key. Generate a 2048-bit key in your provider's console under a new selector, publish it, switch signing to it, and keep the old key published for at least seven days, and up to 30, as M3AAWG advises, before you revoke it. Our DKIM key rotation guide walks through each step.

Signing with the wrong domain. If a service signs with its own domain (d=mailer.example.net) rather than yours, DKIM passes but won't align for DMARC. Set up custom DKIM for your domain in that service.

Revoking a key. To retire a key deliberately, publish it with an empty p=:

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

Limitations

• We can't list selectors. DNS doesn't allow it. An unknown selector is unknown, not a failure.
• A valid key doesn't prove your mail is being signed. Check a real message's Authentication-Results header for dkim=pass.
• Signatures can break in transit if a mailing list or gateway rewrites the message. That isn't a key problem.
• We check the public key only. We never see your private key.

Related

Read SPF vs DKIM vs DMARC to see how DKIM alignment feeds into DMARC.