DKIM Explained: How to Find, Read and Check a DKIM Record

DKIM is the part of email authentication that people find hardest to picture, because unlike SPF it involves cryptography and a value you cannot guess. You cannot look up a domain's DKIM record without first knowing its selector — and that trips almost everyone up the first time.

Once you understand selectors, the rest is straightforward. The DKIM Checker will pull any record if you give it a domain and a selector.

What DKIM does

DomainKeys Identified Mail attaches a cryptographic signature to outgoing messages. The sending server signs selected headers and the body with a private key. The matching public key is published in DNS. A receiving server fetches that public key, verifies the signature, and learns two things: the message really was authorised by that domain, and it has not been altered in transit.

That second property is the important one. SPF tells you where a message came from. DKIM tells you the content is intact.

Selectors, and why you need one

A domain can have many DKIM keys at once — one per sending system, or rotated over time. They are distinguished by a selector, a short label chosen by whoever set it up.

The record lives at:

So a selector of google on example.com means the record sits at google._domainkey.example.com.

There is no way to enumerate selectors from DNS. You cannot ask "what selectors does this domain have?" — you can only ask "does this specific selector exist?". That is a deliberate design property, and it is why you need to find the selector before you can check anything.

Finding the selector

The reliable way is to read an actual email. Open any message from the domain, view the original or raw source, and look for the DKIM-Signature header:

The d= tag is the signing domain. The s= tag is the selector — here, selector1. Feed those two into the DKIM Checker.

If you cannot get hold of a message, common selectors are worth trying: Google Workspace typically uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1, SendGrid uses s1 and s2, and Amazon SES uses long generated tokens you will not guess.

Reading the record

The published record is a TXT record that looks like this:

v=DKIM1 — version. Always this.

k=rsa — key type. Nearly always RSA; ed25519 exists but is rare in practice.

p= — the base64 public key. This is the substance of the record.

You may also see t=y, which marks the domain as in testing mode and tells receivers not to treat failures harshly. Useful during setup, easy to forget about afterwards, and worth removing once you are live.

An empty p= means the key has been revoked. The record still exists, but it explicitly says "this key is no longer valid". That is a deliberate revocation, not a broken record.

Key length matters

DKIM keys are commonly 1024 or 2048 bits. 1024-bit RSA is now considered weak, and some providers have started treating it with suspicion.

The historical reason for short keys was a real constraint: DNS TXT records are limited to 255 characters per string, and a 2048-bit key does not fit in one. The fix is splitting the key across multiple quoted strings within the same record, which every serious DNS provider supports. If your provider does not, that is a reason to change provider rather than a reason to use a weak key.

If you are setting up DKIM today, use 2048-bit.

Why DKIM survives forwarding

This is DKIM's genuine advantage over SPF.

When somebody forwards your email, the sending server changes — so SPF fails, because the forwarder is not on your list. But the DKIM signature travels with the message. The signed headers and body are unchanged, so the signature still verifies. DKIM passes.

That is why mailing lists and forwarding do not destroy authentication entirely, and why DMARC accepts a pass from either SPF or DKIM rather than demanding both.

The caveat: if the forwarder modifies the message — adding a footer, rewriting links, altering the subject to prepend [LIST] — the body hash no longer matches and the signature breaks. Mailing lists that append unsubscribe footers do exactly this, which is the problem ARC was invented to solve.

Checking yours

1. Get a real message from the domain and read the DKIM-Signature header.
2. Note d= (domain) and s= (selector).
3. Run both through the DKIM Checker.
4. Confirm p= is present and not empty, and that the key is 2048-bit.
5. Check whether t=y is still set from a setup you finished months ago.

If you send through several providers, each will have its own selector, and each needs checking separately. It is common to find that three are configured correctly and the fourth was never finished.

Common questions

How do I find my DKIM selector?

Read the DKIM-Signature header of a real email from that domain. The s= tag is the selector. There is no way to list selectors from DNS.

Can a domain have more than one DKIM key?

Yes, and most do — one per sending system, plus rotated keys. Each has its own selector.

What does an empty p= mean?

The key has been revoked. The record is intentionally published as a tombstone.

Is 1024-bit DKIM still acceptable?

It works, but it is weak by modern standards. Move to 2048-bit if your DNS provider supports split TXT strings — and most do.

Where to go next

1. Check the key with the DKIM Checker, then read the raw message with the Email Header Analyzer.
2. DKIM only becomes enforcement when you add DMARC.
3. Ask in the BitCops community if a signature is failing and you cannot see why — that one usually needs a second pair of eyes.
4. Free foundations in the BitCops courses.