# DKIM Record Checker: Look Up a DKIM Key

URL: https://email-validation.org/tools/dkim-checker/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

Enter a domain and a selector to see the DKIM public key published for it. Leave the selector empty and the checker
tries a short list of common selectors. It reads the key's type and size and flags weak, revoked, malformed or
testing keys, each with its fix.

## What DKIM does

DKIM ([RFC 6376](https://www.rfc-editor.org/rfc/rfc6376)) adds a digital signature to each message. The sending
server signs with a private key; the receiver fetches the matching public key from DNS, at
`<selector>._domainkey.<domain>`, and checks that the signed headers and body were not changed. Unlike SPF, a DKIM
signature survives forwarding, which makes it the more reliable half of DMARC.

## Finding your selector

The selector is not guessable in general: each provider picks its own, and a domain can have several. To find yours,
open a message you sent, view its original headers and find the `DKIM-Signature:` line. `d=` is the signing domain
and `s=` the selector:

```text
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
```

Common ones: `google` (Google Workspace), `selector1` and `selector2` (Microsoft 365), `k1` (Mailchimp), `s1` and
`s2` (several platforms).

## The key record

| Tag | Meaning |
| --- | --- |
| `v=DKIM1` | Optional; if present it must be first |
| `k=` | Key type: `rsa` (default) or `ed25519` ([RFC 8463](https://www.rfc-editor.org/rfc/rfc8463)) |
| `p=` | The public key, base64. Empty means the key is revoked |
| `t=y` | Testing mode: receivers may ignore the result |
| `h=` | Allowed hash algorithms |

## The problems this checker finds

- **No key at that name.** Wrong selector, or the key was never published. Every message signed with it fails DKIM.
- **RSA keys under 1024 bits.** Receivers must not accept them
  ([RFC 8301 §3.2](https://www.rfc-editor.org/rfc/rfc8301#section-3.2)).
- **1024-bit keys.** Still accepted, but weak; RFC 8301 says signers should use at least 2048 bits. Rotate to a new
  selector with a 2048-bit key.
- **Broken base64.** A pasted space, quote or line break, or a key cut off at 255 characters. Long keys must be split
  into several quoted strings inside one TXT record, never into two records.
- **`h=sha1`.** SHA-1 signatures must not be used and are treated as failing
  ([RFC 8301 §3.1](https://www.rfc-editor.org/rfc/rfc8301#section-3.1)).
- **`t=y` left on** after testing, and **empty `p=`** (a revoked key) on a selector you still sign with.

A published key shows that signing can work; whether your messages actually pass depends on the signer. Check a real
message's `Authentication-Results` header for `dkim=pass`. To create a key record, use our
[DKIM generator](https://email-validation.org/tools/dkim-generator/).

Checking email addresses rather than domains? Try our [free email checker](https://email-validation.org/email-checker/) or see [pricing](https://email-validation.org/pricing/) for lists and the API.

## Frequently asked questions

### How do I find my DKIM selector?

Open the headers of a message you sent and find the DKIM-Signature line: the s= value is the selector and d= the signing domain.

### Is a 1024-bit DKIM key still safe?

It is still accepted, but RFC 8301 recommends at least 2048 bits. Publish a 2048-bit key under a new selector, switch your signer to it, then remove the old key.

### Why does the checker not find my key?

Most often the selector is different from the ones tried. Enter the exact s= value from a sent message. If it still fails, the key is not published at selector._domainkey under your domain.