DKIM Checker

Check a domain's DKIM records the way receiving mail servers find them, or paste an email to test its signature: which selectors answer, who signs, how strong each key is, and whether it lines up with DMARC.

Sources: 140 common selectors from 67 email providers, asked through Google Public DNS (Cloudflare behind it) · RFC 6376 and RFC 8301 key checks · emails verified in your browser · nothing about you is stored

How to check a DKIM record

Type the domain above: the checker asks the 140 selectors email providers use, shows every key it finds with its size and provider, and says honestly when it finds none. Know the selector? Choose Domain + selector and it's checked first.

By hand you need the selector, because DNS can't list them: dig +short TXT selector._domainkey.example.com, or nslookup -type=TXT with the same name on Windows. The selector is the s= in any email's DKIM-Signature (RFC 6376 §3.6.2.1).

dig shows the text, not what it means: it doesn't decode the key's size, follow the provider's CNAME, or tell a standby slot from a broken one. That's what this DKIM record checker adds.

dig +short TXT selector._domainkey.example.com

Every TXT string at the name: join them to read the key.

What dig shows, and what it doesn't

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1The name is selector._domainkey.domainNo selector, no answer: DNS has no “list all keys”.
  2. 2Two strings, one recordA TXT string holds 255 bytes, so a 2048-bit key is split; receivers join them with nothing between.
  3. 3The key's real sizeopenssl decodes p=: 2048 bits is what RFC 8301 asks for.
  4. 4A CNAME into the providerNo TXT behind it: Microsoft 365's standby slot, not an error.
google.com's key and microsoft.com's selector1 as Cloudflare DNS returned them on October 25, 2026.

Reading the result: the selector sweep

The answer comes first, as a sentence. Under it, who signs and the key itself, each tag coloured over its exact characters with the key's size on RFC 8301's scale; on navy, every selector the check asked, so you can see what was tried.

No grade: a retired key or a provider's empty standby selector is normal, and “not found among the common selectors” never means “no DKIM”.

DKIM check of github.com: twelve keys from six providers, the selector sweep and the key size meterDKIM check of github.com: twelve keys from six providers, the selector sweep and the key size meterThe verdictOne sentence: how many keys, and what needs doing.Who signsOne card per provider, found by its CNAME or a documented selector. Each selector chip opens its key.The keyEach tag coloured over its characters, and the key's size on RFC 8301's scale.The selector sweepEvery name asked, lit as it answers: green a key, amber 1024-bit, dashed a standby slot.DMARC alignmentWhether a key with this domain's d= lines up with its DMARC policy.
A DKIM check of github.com: the verdict, who signs, the key split into its tags with its size, and on navy every selector the check asked. Select a number to see what each part shows.

What is DKIM?

DKIM (DomainKeys Identified Mail) is a signature a sending server adds to each message, which receivers check with a public key the domain publishes in DNS (RFC 6376). A valid signature proves two things: the domain in d= signed it, and the signed parts haven't changed since.

The sender hashes the body into bh= and signs the chosen headers plus that hash with its private key into b=. The receiver reads d= and s=, fetches the key at s._domainkey.d, and redoes both. One changed byte in the body, or in a signed header, and it fails.

DKIM says nothing about what to do when it fails, and any domain can sign. That's DMARC's job: it asks for a passing signature whose d= matches the From: domain.

One message, signed at the sender and checked at the receiver

example.com's serversigns with its private key
the message, with its DKIM-Signature
The receiverGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

The message as sent

  • Body hash matches bh=
  • Header signature verifies

dkim=pass header.d=example.com

The same message, its Subject edited on the way

  • Body hash matches bh=
  • Header signature doesn't verify

dkim=fail (signature-mismatch)

Both results are the engine's, from the sample email on this page and the same email with its Subject changed after signing. RFC 6376 §3.7, RFC 8301.

What is a DKIM selector, and how do I find mine?

A selector is the name of one DKIM key: the s= in a signature, and the first label of the DNS name the key lives at (s1._domainkey.github.com). A domain can have as many as it likes: one per provider, per server, per year (RFC 6376 §3.1).

To find yours, open any email the domain sent and look at the original: Gmail's More (⋮) › Show original lists the DKIM-Signature, and its s= is the selector. Or paste the email into Verify an email above.

Most providers use fixed names, so a sweep finds them. Amazon SES, Postmark, SparkPost and HubSpot generate a name per account, which only an email or the provider's dashboard tells you.

From the signature to the key, and the names providers use

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegooglethe admin can change the prefix
Microsoft 365selector1 · selector2CNAMEs into the tenant; one active, one standby
Twilio SendGrids1 · s2CNAMEs to u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAMEs to dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3three CNAMEs, one filled at a time
Proton Mailprotonmail · 2 · 3CNAMEs into domains.proton.ch
Amazon SES3 random tokens32 random characters each: can't be guessed
Postmark20240101000000pma date and “pm”: can't be guessed
SparkPostscph + MMYYscph and the month the key was made
HubSpoths1-<HubID>your account number
github.com's s1 as Cloudflare DNS returned it on October 25, 2026. Providers' names from their own documentation (67 providers, 140 selectors in the sweep).

DKIM record format: every tag explained

A DKIM record is a TXT record of tag=value pairs separated by semicolons; only p=, the public key, is required. v=DKIM1 is optional but, when present, must come first (RFC 6376 §3.6.1).

k= says the key type (rsa unless it says ed25519), t= carries flags (y testing, s strict), h= limits hashes and s= services. An empty p= revokes the key on purpose.

Tag names are case-sensitive and a repeated tag invalidates the record. Unknown tags are ignored.

The record, tag by tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagSetsValuesDefaultNote
v=VersionDKIM1DKIM1recommended; first if present
k=Key typersa · ed25519rsaunknown types: key ignored
p=Public key (base64)the key, or emptyrequiredempty = revoked
t=Flagsy testing · s strictnoney: treated as unsigned
h=Hashes allowedsha256 (sha1 forbidden)allsha1 alone fails (RFC 8301)
s=Service type* · email*other services only: ignored
n=Notes for peopleany text–never read by software

How long p= is, and how many TXT strings it needs

RSA 1024216 characters · 1 TXT string
RSA 2048392 characters · 2 TXT strings
RSA 3072564 characters · 3 TXT strings
RSA 4096736 characters · 3 TXT strings
Ed2551944 characters · 1 TXT string

255-byte TXT string boundaries (counting “v=DKIM1; k=rsa; p=”)

p= lengths are measured SubjectPublicKeyInfo keys. yahoo.com publishes its 2048-bit key in 4 strings: any split works, since receivers join them with nothing between (RFC 6376 §3.6.2.2).

1024 vs 2048-bit DKIM keys, and how to rotate them

Use 2048-bit RSA. RFC 8301 still requires verifiers to accept 1024-bit keys, but asks signers for at least 2048, and tells verifiers to reject keys under 1024 bits. M3AAWG calls 1024 bits “at the edge of attack” and reports a 512-bit key cracked in about 72 hours for about $75.

An Ed25519 key is small (44 characters of p=), and for backward compatibility RFC 8463 lets signers add an RSA signature beside it: two selectors, two signatures (RFC 8463).

Rotate by publishing the new key under a new selector, switching signing, keeping the old key 7 to 30 days for mail in flight, then emptying its p=. M3AAWG suggests every six months. Providers like Fastmail and Microsoft 365 do it for you with standby selectors.

Where real keys sit on RFC 8301's scale

FailsValid, rotate to 2048GoodMay fail at some receivers
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Rotation without a gap (M3AAWG)

  1. Day 0Publish the new key at a new selector
  2. Day 1+Switch signing to it
  3. +7–30 daysKeep the old key for mail in flight
  4. ThenEmpty the old p=; don't reuse the name
fastmail.comfm1empty p=fm22,048fm3empty p=three CNAMEs, one filled: rotation is a DNS change at Fastmail's end
Key sizes read from DNS on October 25, 2026, decoded from each p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Why does DKIM fail? Body hash, forwarding and mailing lists

DKIM fails when the signed bytes changed, when the key can't be found, or when the key doesn't match the signature. Forwarding that leaves the message unchanged keeps DKIM intact (unlike SPF); mailing lists usually break it, because they add footers or tag the subject.

The verifier on this page checks the body hash and the header signature apart, so it can tell a footer added on the way from a forgery.

Body hash did not verify

A mailing list added a 153-byte footer. The headers still verify with project.example's key, so this isn't a forgery.

Fix Lists that keep the body intact, or ARC (RFC 8617) so later receivers see the original result.

body-hash-mismatch

Signature did not verify

A signed header changed after signing (a list adding its name to the Subject), or the selector now holds a different key.

Fix Don't rewrite signed headers; publish a new key under a new selector instead of replacing one.

signature-mismatch

No key for signature

s=2023old._domainkey.shop.example is NXDOMAIN: the selector was deleted while mail signed with it was still in flight.

Fix Keep old keys published 7–30 days after switching; empty p= rather than delete.

key-not-found

Forwarding: a forwarder that passes the message on unchanged keeps DKIM valid, which is why DMARC usually survives forwarding through DKIM even when SPF fails.

DKIM vs SPF vs DMARC

SPF says which servers may send for a domain, DKIM proves a domain signed the message and it wasn't changed, and DMARC ties both to the From: address and says what to do when they fail.

They answer different questions, so you need all three: Gmail and Yahoo require SPF and DKIM from bulk senders, plus a DMARC record, and RFC 9989 asks domains at p=reject to DKIM-sign rather than rely on SPF.

Three records, three questions

Three records, three questionsSPFDKIMDMARC
What it provesThis server may send for the MAIL FROM domainDomain d= signed it; signed parts unchangedFrom: matches a domain that passed SPF or DKIM
Where it livesTXT at github.comTXT at s1._domainkey.github.comTXT at _dmarc.github.com
github.com todayv=spf1 … ~all12 keys, 6 providersp=quarantine; sp=reject
Survives forwardingNo: the forwarder's IP isn't listedYes, when the message arrives unchangedYes, through an aligned DKIM pass
Breaks whena new sending service isn't in the recordthe body or a signed header changesneither passes for the From: domain
github.com's records as read on October 25, 2026.

How to read the DKIM-Signature header in an email

Open the original message and find the DKIM-Signature header: d= is who signed, s= is which key, h= lists the signed headers, and bh= and b= are the two hashes a receiver checks.

The receiver's verdict is a separate header added on arrival: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Gmail's Show original page (in English) sums it up as “DKIM: 'PASS' with domain example.com”.

A message can carry several signatures, one per signer (your domain and your email service, or a mailing list). Any one passing signature with an aligned d= is enough for DMARC.

The sample email's signature, tag by tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Version v=always 1
  2. 2Algorithm a=rsa-sha256 (or ed25519-sha256)
  3. 3Canonicalization c=relaxed tolerates re-folding
  4. 4Signing domain d=compared with From: for DMARC
  5. 5Selector s=the key at s._domainkey.d
  6. 6Signed at t=Unix time: Oct 24, 2026, 9:12 AM
  7. 7Signed headers h=from twice = oversigned
  8. 8Body hash bh=SHA-256 of the canonical body
  9. 9Signature b=over the h= headers and this field

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

The made-up sample email this page loads (example.com, a key made for it), verified by the engine.

DKIM checker: frequently asked questions

What is a DKIM record?

A DKIM record is a TXT record that publishes a domain's public key at selector._domainkey.domain, such as google._domainkey.example.com. It holds tag=value pairs: p= is the base64 key and is required, k= the key type, t= flags. Receivers fetch it to check the DKIM-Signature on incoming mail. A domain can publish many, one per selector, usually one per sending service.

How do I find my DKIM selector?

Open any email the domain sent, view the original message and find the DKIM-Signature header: the value after s= is the selector, and d= is the domain. In Gmail use More (⋮) › Show original; in Outlook on the web, View › View message source. Or paste the email into Verify an email above, which reads s= and d= for you.

Why does the checker find no key when my mail is signed?

Because DNS can't list selectors: a key is found only by asking for its exact name. The checker asks the 140 names providers use; if yours signs with another (Amazon SES and Postmark generate one per account), the sweep can't see it. Add the selector from an email's s= and it's checked first, or verify an email instead.

Is a 1024-bit DKIM key still OK?

It still works: RFC 8301 requires verifiers to accept RSA keys from 1024 to 4096 bits, and Gmail and Yahoo set 1024 bits as their minimum. But RFC 8301 asks signers for at least 2048 bits, and M3AAWG calls 1024 at the edge of attack. Plan a rotation: Microsoft 365 and Google Workspace both offer 2048-bit keys. RFC 8301 tells verifiers to reject keys under 1024 bits.

What does an empty p= mean?

An empty p= means the key is revoked: signatures with that selector fail, exactly as if the key were missing. It's usually deliberate. Google keeps its old dated selectors this way, and Fastmail and Microsoft 365 keep empty standby selectors to rotate into. It's a problem only if it's the selector your mail is signed with today.

What does t=y mean in a DKIM record?

t=y marks the key as testing: receivers should treat mail signed with it like unsigned mail, even when the signature verifies. It's meant for a first setup and is often forgotten. t=s is different: it means strict, so the i= in signatures must be exactly the signing domain, not a subdomain. Some email services publish t=s on their keys; SendGrid's keys for github.com carry it.

Why does DKIM fail with “body hash did not verify”?

The body the receiver hashed doesn't match the bh= value in the signature, so the body changed after signing. Mailing lists that add a footer, security gateways that rewrite links and disclaimers added by a server all cause it. If the header signature still verifies, the message is genuine but modified; this page's verifier checks both apart.

Does DKIM survive email forwarding?

Usually, yes. A forwarder that passes the message on unchanged keeps the signature valid, because DKIM signs the content, not the path. That's the difference from SPF, which fails at the forwarder's IP address. Forwarders that alter the message, such as mailing lists adding footers or subject tags, break DKIM; ARC lets them vouch for the original result.

Do I need DKIM if I already have SPF?

Yes. SPF breaks when mail is forwarded and only covers the hidden MAIL FROM address, while DKIM survives forwarding and can align with the From: domain DMARC checks. Gmail and Yahoo require both from bulk senders, Outlook.com since May 2025, and RFC 9989 asks domains with p=reject to DKIM-sign their mail.

How often should I rotate DKIM keys?

M3AAWG recommends at least every six months. Publish the new key under a new selector, switch signing to it, keep the old key published for 7 to 30 days so mail in flight still verifies, then empty its p= instead of deleting it. Never reuse a selector name. Hosted providers with CNAME selectors rotate the keys for you.

Is my email uploaded when I verify it here?

No. This DKIM validator checks the email in your browser: public DNS is asked only for the keys' names (s._domainkey.d), and dnsrobot.net only for the From domain's and the signing domains' DMARC policy. The one exception is an Ed25519 signature a browser can't check: the page then asks before sending the email once to our server, which checks it in memory and stores nothing.

Can I use an Ed25519 DKIM key?

Yes. RFC 8463 defines it and requires verifiers to support it. For backward compatibility, publish it at its own selector next to an RSA key and sign every message twice, as archlinux.org does with dkim-ed25519 and dkim-rsa: receivers that can't verify Ed25519 still have the RSA signature. Microsoft 365 and Google Workspace offer RSA keys only.

Missing something?Suggest a feature or a new tool