DKIM Selectors

A DKIM selector is the label that points a receiving server at the right public key in your DNS. When you send a signed message, its DKIM-Signature header carries two things the receiver needs: d= (your domain) and s= (the selector). The receiver combines them, looks up the key at s._domainkey.d, and uses it to verify the message wasn’t forged or altered in transit. Every service that sends as you publishes its own selectors — Microsoft 365 uses selector1 and selector2, Google Workspace uses google, Mailchimp uses k1 — so the first step to confirming your mail is properly signed is finding all of them.

What a healthy key looks like

Say example.com signs with Microsoft 365. Looking up its first selector returns a key record:

Field	Value
Name / Host	selector1._domainkey.example.com
Type	TXT
Value	v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…

Three tags carry the whole record:

• v=DKIM1 — the version, marking this as a DKIM key.
• k=rsa — the key type (RSA is near-universal).
• p=… — the public key itself, a long base64 string receivers use to check your signature. This is the part that matters: a record with a populated p= is an active key.

A revoked key looks almost identical, but with an empty p=:

v=DKIM1; k=rsa; p=

An empty p= deliberately tells receivers the key is no longer valid — mail signed with it will fail DKIM. That’s normal mid-rotation, but if you see it unexpectedly, re-enable DKIM signing in your mail provider to publish a fresh key.

Finding your selectors

There are two ways to find which selectors your domain uses:

The common defaults. Most providers use predictable names, and the checker probes a dozen of the most common automatically: selector1, selector2 (Microsoft 365), google (Google Workspace), k1, k2 (Mailchimp and others), plus default, dkim, mail, s1, s2, and two dated Google selectors. If your senders use any of these, they turn up on their own.

The definitive method. Selectors are chosen by your mail provider, so yours might not be on any common list. To find your real selector for certain: send yourself an email, open the original message (full headers), and read the s= tag in the DKIM-Signature header. That value is your selector — enter it in the checker and re-run.

Two selectors is healthy, not a mistake

Microsoft 365 and many others publish two selectors — selector1 and selector2 — and rotate between them, so a fresh key is always staged before the active one retires. Seeing more than one valid key means rotation is set up correctly, not that something is duplicated. You may also see a CNAME at the selector instead of the TXT directly: providers like Microsoft 365 publish the key as a CNAME pointing at a key they host for you. It resolves to the same key, and the checker follows it through.

A blank result isn’t proof DKIM is off

If nothing turns up on the common selectors, the checker returns a warning, never a failure — and that’s deliberate. Absence on the defaults does not mean DKIM is missing; your provider may simply use a selector the checker didn’t guess. Don’t disable signing or re-issue keys based on a blank result — confirm with your real selector (the s= header tag above) first.

Check your own

The checker probes all the common selectors at once and shows each result — valid, revoked, or absent — in a table, so you can see every key you publish in one pass. If your provider uses an uncommon selector, enter it and re-run:

Verify yours → Run the free DKIM selector checker against your domain.

Where DKIM selectors fit

DKIM is one of the two ways a message authenticates to your domain (SPF is the other), and it’s the one that usually survives forwarding. DMARC passes when either aligns — so valid, published DKIM keys are part of the foundation for reaching enforcement. If you’re working toward p=reject, confirming every sender signs with a key you can actually see here is one of the things to get right first — see the DMARC Enforcement Guide.