---
title: DKIM failing? How to check a DKIM record with the DKIM Checker
description: DMARC reports or message headers say dkim=fail or "no key", and you need to know whether the public key is published. To check a DKIM record, find the selector in the message's DKIM-Signature header, then look up the TXT record at selector._domainkey.yourdomain. Here's how to do it with the free DKIM Checker, how to read the key, and how to check its size with openssl.
canonical: https://watchfor.io/blog/how-to-check-a-dkim-record
---

# DKIM failing? How to check a DKIM record with the DKIM Checker

2026-10-04 · WatchFor Team · Guides · guides, email, security

DMARC reports or message headers say dkim=fail or "no key", and you need to know whether the public key is published. To check a DKIM record, find the selector in the message's DKIM-Signature header, then look up the TXT record at selector._domainkey.yourdomain. Here's how to do it with the free DKIM Checker, how to read the key, and how to check its size with openssl.

To check a DKIM record, you need two things: your domain and the selector.
The selector is the `s=` value in the `DKIM-Signature` header of a message
you sent. Look up the TXT record at `<selector>._domainkey.<domain>`: if it
returns a DKIM record with a non-empty `p=` key, receivers can verify your
signatures. No record, or an empty `p=`, means every message signed with
that selector fails DKIM.

The free [DKIM Checker](/dkim-record-checker) looks up the selector from a
WatchFor location and shows the key it finds. No signup.

## What this tool answers

*Is the public key for this selector published and usable?* Reach for it
when DMARC reports show DKIM failures, when headers say `dkim=fail` or
`dkim=neutral (no key)`, right after enabling DKIM in Google Workspace,
Microsoft 365 or an email service, and after a DNS migration, when the long
`_domainkey` records are the first to get lost.

## A real example

### Checking a DKIM record for Google Workspace mail

A team on Google Workspace sees DKIM failures in its DMARC reports and
wants to know whether the key is in DNS at all. Workspace signs with the
selector `google` unless the admin chose another prefix, and the `s=` tag in
any sent message confirms it (the [email header guide](/blog/how-to-read-email-headers)
shows where to find it).

We checked a public domain that uses Google Workspace. In the
[DKIM Checker](/dkim-record-checker) we entered domain `mozilla.org`,
selector `google`, and pressed **Check DKIM**:

![The DKIM Checker for mozilla.org with selector google: PASS, the google._domainkey record marked VALID, with the record v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCe... and key type rsa](/blog/how-to-check-a-dkim-record-result.webp)

The lookup took 709 ms and returned one record at `google._domainkey.mozilla.org`:

- **VALID**: the record publishes a non-empty `p=` key.
- **Key type `rsa`**, from the `k=` tag.
- The key itself starts with `MIGfMA0`. That prefix is the mark of a
  **1024-bit** RSA key (2048-bit keys start with `MIIBIjAN`); the
  command-line section confirms the size with openssl.

**The answer:** the key is published and well-formed, so a missing record
isn't what makes DKIM fail. The next suspects are the message itself
(signed with a different selector, or modified in transit by a mailing list
or a gateway that rewrites content) and the domain in `d=`. On key
strength: RFC 8301 accepts 1024-bit RSA keys and recommends 2048. Google
Workspace lets admins generate a 2048-bit key; switch when your DNS host
accepts the longer record.

## How to read the results

| What you see | What it means |
| --- | --- |
| **PASS / FAIL** | PASS: a usable key is published for this selector. FAIL: nothing usable at that name. |
| **`<selector>._domainkey`** | The exact name that was looked up, under the domain you entered. |
| **VALID** (green) | The TXT record publishes a non-empty `p=` public key. |
| **REVOKED** (amber) | The record is there but `p=` is empty: the key was retired on purpose, and mail still signed with it fails. |
| **NXDOMAIN** (red) | Nothing is published at that name: wrong selector, a typo, or a record lost in a DNS move. |
| **NO_RECORD** (red) | TXT records exist at that name, but none of them is a DKIM key record. |
| **TIMEOUT / ERROR** | The lookup itself failed. Run it again before drawing conclusions. |
| **Record** | The raw TXT value, copyable. Long keys are split into several strings in DNS; the tool joins them. |
| **Key type** | The `k=` tag, usually `rsa`, sometimes `ed25519`. Shown only when the record sets it. |
| **Key size** | Read from the `p=` key, for example 1024-bit RSA; amber below the recommended 2048. Missing on a VALID record when the key doesn't parse, which usually means it was truncated. |

## More ways to use it

- **Microsoft 365.** It signs with selectors `selector1` and `selector2`,
  published as CNAMEs from your domain to Microsoft. Check both; the
  CNAME target also has to resolve to a key.
- **Email services.** SendGrid commonly uses `s1`/`s2`, Mailchimp `k1`, and
  others their own names. The service's DNS setup page lists them, and the
  `s=` in a test message tells you which one is live.
- **Before deleting an old provider's records.** Look up its selector
  first. If it still resolves and something still signs with it, removing
  it breaks that mail.
- **After a key rotation.** Check the new selector before switching signing
  to it, and keep the old one published until mail signed with it has been
  delivered.

## Tips and gotchas

- **Without the selector you can't check DKIM.** There's no way to list all
  selectors of a domain. Take it from a real message: `DKIM-Signature: ...
  d=example.com; s=google; ...`.
- **The domain is the `d=` value, not always yours.** If `d=` shows your
  email provider's domain, the message passes DKIM for *their* domain and
  still fails DMARC alignment for yours. Set up the provider's custom DKIM
  for your own domain.
- **An empty `p=` means revoked.** RFC 6376 defines `p=` with no value as a
  revoked key. Providers do this on purpose when they retire a selector.
- **Paste the record as one value.** Most DNS panels split long TXT values
  into 255-character strings automatically. Line breaks or stray quotes
  pasted into the value corrupt the key.
- **`v=DKIM1` is optional.** RFC 6376 allows a key record without it, and
  some providers' key records start directly with `k=rsa;`. If the checker
  shows NO_RECORD for a selector you expect, confirm with `dig` below.

## Check it from the command line too

```bash
dig +short @1.1.1.1 TXT google._domainkey.mozilla.org
```

```text
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeaLfcj7zdLlf8U+HmEV9SvLcrhQcwBBKzGXpazWCkdEczUCIbrx4PNfn0MDK7Pm+iwLu2CBwts+H4HKHHLR6UIzQeUw3+QoHjcRdBPrsAVT2Z3lgis0aPrR5wlv5ymlMfqXYu7N8UqKVKe5r0TO7uU+NI/tqNR20GKEYdBWtiVwIDAQAB"
```

To get the key size, wrap the `p=` value in PEM markers and let openssl read
it:

```bash
k=$(dig +short @1.1.1.1 TXT google._domainkey.mozilla.org | tr -d '" \n' | sed 's/.*p=//')
printf -- "-----BEGIN PUBLIC KEY-----\n%s\n-----END PUBLIC KEY-----\n" \
  "$(echo "$k" | fold -w 64)" | openssl pkey -pubin -noout -text | head -1
```

```text
Public-Key: (1024 bit)
```

The same command on `google._domainkey.github.com` prints `Public-Key: (2048 bit)`.
And this is what a retired selector looks like:

```bash
dig +noall +answer @1.1.1.1 TXT 20230601._domainkey.gmail.com
```

```text
20230601._domainkey.gmail.com. 2677 IN	TXT	"v=DKIM1; k=rsa; p="
```

An empty `p=`: the key is revoked, and nothing signed with it verifies.

## Keep watching it

DKIM keys go missing quietly: a DNS migration drops a `_domainkey` record,
or a provider rotates selectors and the CNAME breaks. An
[email monitor](/email-monitoring) (the email policy type) with your
selectors in **DKIM Selectors** re-checks them on a schedule, and the
**DKIM Record Missing** rule fires when none of them resolves to a
DKIM key record. The same monitor watches SPF and DMARC.

## FAQ

**How do I find my DKIM selector?**
Open a message you sent, view the original or raw headers, and find the
`DKIM-Signature` header. The `s=` tag is the selector and `d=` the domain.
Your email provider's DKIM setup page lists it too.

**Why does DKIM fail when the record exists?**
Usually the message was changed after signing (a footer added by a list or
gateway), it was signed with a different selector than the one you checked,
or the published key doesn't match the private key the server signs with,
often after a rotation.

**Is a 1024-bit DKIM key still OK?**
It's allowed: RFC 8301 sets 1024 bits as the minimum and recommends 2048.
Move to 2048 when your DNS host supports long TXT records. How DKIM fits
with SPF and DMARC is in
[SPF, DKIM and DMARC explained](/blog/spf-dkim-dmarc-explained).

---

Canonical page: https://watchfor.io/blog/how-to-check-a-dkim-record · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt