Free DKIM record checker.
Enter a domain and a selector, and get the published DKIM public key back with the state of every tag in it. If you do not know your selector, the fix section below finds it from any message you have already sent.
Privacy: this tool runs entirely in your browser. When you click Check, one DNS query for the domain you typed goes to Cloudflare's public DNS resolver (Google's as fallback). Nothing is stored, logged or sent to GrowthPal.
DKIM at a glance
| Item | Value |
|---|---|
| Record location | A TXT record at selector._domainkey.yourdomain.com |
| Common selectors | google (Workspace), selector1 and selector2 (Microsoft 365), k1 (Mailchimp), smtp (Brevo), default |
| Key length | 1024-bit is still accepted; 2048-bit is the sensible choice where DNS allows it |
| What it proves | The message was signed by a holder of the private key and the signed parts were not altered in transit |
| Keys per domain | As many as you have selectors. That is how rotation and multiple senders work |
| Specification | RFC 6376, published September 2011 |
What is a DKIM record?
A DKIM record is a DNS TXT record holding the public half of a signing key, published at a selector under your domain. Your sending platform signs each outgoing message with the private half, and receivers fetch the public half to check that signature.
What the signature covers is the interesting part. DKIM signs the message body and a chosen set of headers, then records the result in a DKIM-Signature header. A receiver recomputes both and compares. If either changed in transit, the signature fails.
That design is why DKIM survives forwarding when SPF does not. SPF asks whether this server is allowed to send for you, which stops being true the moment a message is relayed. DKIM asks whether this message is intact and genuinely signed by you, which stays true no matter how many hops it takes, as long as nothing rewrites it on the way.
How to read your DKIM check result
The DKIM check needs two inputs, a domain and a selector, because a domain can carry any number of keys and the selector is what names the one you want.
A public key present is the healthy result. It means the record exists, parses, and carries a key that messages can be verified against.
No record at that selector is ambiguous rather than fatal. Far more often than a missing key, it means the wrong selector. The tool lists the common ones to try, and the procedure below reads the real answer out of a message you have already sent.
An empty p= tag is the one unambiguous failure. A published record with no key in it is how a key is formally revoked, so anything still signing with that key is now failing verification everywhere.
What this check cannot tell you is whether your signatures actually verify. Publishing a valid key and signing correctly are two different jobs, and only a received message proves the second one.
What each DKIM tag means
| Tag | What it does | Notes |
|---|---|---|
v | Version. DKIM1 when present. | Optional, but first if used |
k | Key type: rsa or ed25519. | Defaults to rsa |
p | The public key itself, base64. Empty means the key is revoked. | Required |
t=y | Testing mode. Receivers are told to treat failures as if DKIM were not deployed. | Remove once live |
t=s | Stops the key being used for subdomains of the signing domain. | Rarely needed |
h | Restricts which hash algorithms may be used with this key. | Usually omitted |
s | Service type the key applies to. * or email. | Defaults to * |
n | Free-text note for humans. Ignored by verifiers. | Optional |
Why DKIM fails, and what each failure looks like
| Symptom | Cause | Fix |
|---|---|---|
| No record at the selector | Wrong selector far more often than a missing key. | Read the real selector out of a sent message, using the steps below. |
Empty p= | The key has been revoked, deliberately or by a provider rotating it. | Generate a new key at the provider and publish the record it gives you. |
| Body hash did not verify | Something altered the message body after signing. Mailing list footers are the classic case. | Nothing to fix on your side. This is why DMARC accepts SPF or DKIM, not both. |
| Signature verification failed | The key was rotated but the DNS record was not updated, or a header the signature covers was rewritten. | Republish the current public key. Check whether a gateway is modifying headers. |
| A 2048-bit key will not publish | A single DNS TXT string is capped at 255 characters and the key is longer. | Split it into several quoted strings in one record; the resolver concatenates them. |
| Signed, but DMARC still fails | The signing domain does not align with the From address. | Have the platform sign as your domain rather than its own. |
How to find your DKIM selector
The selector is not something you guess, it is something a sent message tells you. Any message you have already delivered carries it.
- Send a message to an address you can open. A different mailbox is ideal, because you want to see what a receiver saw.
- Open the original source. In Gmail, the three-dot menu, then Show original. In Outlook, File, then Properties. Most clients call it source, headers, or original.
- Find the DKIM-Signature header. There may be more than one if a gateway signs as well as your platform.
- Read the
s=andd=tags.s=is your selector,d=is the signing domain. DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1; h=from:to:subject:date; bh=...; b=... - Check that d= is your domain. If it is your platform's domain instead, the signature is real but it will not align for DMARC, which is a different problem worth fixing.
- Put the domain and selector into the checker above to confirm the public key is published and not revoked.
Common questions about DKIM
What is a DKIM selector and where do I find mine?
The selector is the label that tells receivers which key to check, and the public key sits at selector._domainkey.yourdomain. Google Workspace uses google by default, Microsoft 365 uses selector1 and selector2. Cold email platforms generate their own, so check the DNS records they handed you at setup.
Should I use a 1024 or 2048-bit key?
2048 wherever your DNS host allows it. 1024 is still accepted but weak by current standards. Some DNS providers cannot store the longer TXT value in one string and need it split into chunks, which is the usual reason a 2048-bit key looks like it failed to publish.
Does DKIM survive forwarding when SPF does not?
Usually. SPF breaks on forwarding because the forwarding server is not on your list. DKIM signs the message itself, so the signature stays valid as long as nothing modifies the signed content. Mailing lists that append a footer do break it, which is one reason DMARC accepts either check passing.
Does every sending domain need its own DKIM key?
Yes. The key is published in each domain's DNS, so every sending domain needs its own record live before its first warmup send. Across forty or fifty sending domains that is forty or fifty records, which is why domain count is an infrastructure decision rather than an afterthought.
Can one domain have several DKIM keys at once?
Yes, one per selector, and that is exactly how rotation and multi-platform sending work. Each signature names its own selector, so receivers always know which key to fetch. Publish the new key, move signing to it, then leave the old record in place until nothing is signing with it.
What is a body hash failure?
The bh tag in a signature is a hash of the message body taken at signing time. A body hash failure means the body arrived different from how it left, usually because a mailing list or gateway appended a footer. Your key and your record are fine; the message was edited in transit.
Tools check the plumbing. The message is what your market answers. Get your TAM mapped, your ICP broken down and 5 angles written for your buyers, free.