How DKIM works and how to find your selector

DKIM (DomainKeys Identified Mail) lets a domain put a cryptographic signature on the messages it sends. The receiver checks the signature with a public key that the domain publishes in DNS. A valid signature proves two things: the signing domain took responsibility for the message, and the signed parts have not changed on the way.

The specification is RFC 6376 from 2011, updated by RFC 8301 (algorithms and key sizes) and RFC 8463 (Ed25519 keys).

How signing and verification work

The sending server — your mailbox provider or email service — holds a private key. For every outgoing message it:

1. chooses the header fields to sign; From must always be one of them;
2. normalizes headers and body with the chosen canonicalization: simple tolerates almost no change, relaxed tolerates changed whitespace and rewrapped header lines;
3. hashes the body and stores the hash in bh=;
4. signs the chosen headers together with the new DKIM-Signature header itself (its b= still empty) and stores the result in b=;
5. adds the DKIM-Signature header at the top of the message.

The receiver reads d= and s= from the signature, fetches the public key from DNS, recomputes the body hash and verifies the signature. It records the outcome in the Authentication-Results header, for example dkim=pass header.i=@example.com header.s=s2026.

Nothing in DKIM ties d= to the From address: any domain can sign any message. Connecting the two is the job of DMARC, which passes only when the signing domain is aligned with the From domain — see SPF vs DKIM vs DMARC.

The DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
        h=from:to:subject:date:message-id;
        bh=…; b=…

The tags you will meet (RFC 6376, section 3.5):

Tag	Meaning
v=1	Version
a=	Algorithm: rsa-sha256 or ed25519-sha256; rsa-sha1 is no longer allowed
d=	Signing domain — the domain taking responsibility; the key is looked up under it
s=	Selector — which of the domain’s keys was used
h=	Signed header fields, separated by colons
bh=	Hash of the body
b=	The signature itself
c=	Canonicalization for header and body; default simple/simple
t=, x=	Signing time and optional expiry
i=	Identity the message was signed for; same domain as d= or a subdomain of it
l=	Length of the signed body — avoid it: content appended after the signed part still verifies (section 8.2)

The public key record

The verifier builds a DNS name from the selector, the fixed label _domainkey and the domain (section 3.6.2.1). For d=example.com; s=s2026 it asks for a TXT record at:

s2026._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Tag	Meaning
v=DKIM1	Recommended, not required; if present, it must come first
k=	Key type: rsa (default) or ed25519
p=	Public key in base64. An empty p= means the key has been revoked
h=	Allowed hash algorithms (optional)
s=	Service type, email or * (optional)
t=	Flags: y = testing, failures are treated like unsigned mail; s = i= must not be a subdomain of d=
n=	Notes for humans

Publish exactly one TXT record per selector (section 3.6.2.2). Long keys can be split into several strings within that record; verifiers join them without spaces.

Key types and sizes

Key	Status
RSA under 1024 bits	Invalid: verifiers must not accept such signatures (RFC 8301)
RSA 1024 bits	The minimum; Gmail requires at least 1024 bits for mail to personal Gmail accounts
RSA 2048 bits	Recommended: signers should use at least 2048 bits (RFC 8301). The key is longer than one 255-character TXT string, so it is split
Ed25519	RFC 8463: the key is only 44 characters; verifiers must support it, signers should
rsa-sha1 signatures	Invalid: must not be used for signing or verifying (RFC 8301)

Ed25519 doesn’t have to replace RSA. A message can carry two signatures — one RSA, one Ed25519 — with the same d= but different selectors, because each selector holds a single key (RFC 8463, section 6). Verifiers ignore signatures with algorithms they don’t implement (RFC 6376, section 3.3.4), so the RSA signature still works where Ed25519 is unknown.

Why selectors can’t be listed via DNS

DNS answers questions about exact names. There is no query that returns “all names under _domainkey.example.com” — a resolver can only ask about a name it already knows.

Selectors are free-form. RFC 6376 suggests names based on office locations, dates or even individual users (section 3.1), and many providers generate their own. A tool that claims to “find all selectors” can only try a list of popular names: it misses everything else, and a hit doesn’t prove that the key is in use. That is why the DKIM checker asks you for the selector. It offers documented provider defaults as shortcuts, but it doesn’t guess.

How to find your selector

The reliable source is a message you actually sent:

1. Send a message from the system you want to check to a mailbox at another provider.
2. Open the full source of the message — in Gmail, use Show original.
3. Find the DKIM-Signature header: s= is the selector, d= the domain. Many receivers repeat the selector in Authentication-Results as header.s=.

You can also paste the headers into the email header analyzer. It lists every signature with its domain and selector next to the DKIM results from Authentication-Results, and runs entirely in your browser.

A message often carries more than one signature, for example one from your email service with d= set to the service’s own domain and one with your domain. For DMARC, only a passing signature whose d= aligns with your From domain counts. If no signature uses your domain, enable custom DKIM (often called domain authentication) in that service.

Documented defaults of two large providers:

• Google Workspace: the default selector prefix is google, so the key sits at google._domainkey.example.com. You can choose another prefix, for example if one is already taken.
• Microsoft 365: two selectors, selector1 and selector2, published as CNAME records. Only one is active at a time; key rotation switches to the other.

For other services, the selector is listed on the DKIM or domain authentication page of their admin console.

CNAME delegation

Instead of a TXT record with the key, many providers ask you to publish a CNAME at the selector name that points into their own DNS zone. The provider keeps the key there and can rotate it without you touching your DNS:

s1._domainkey.example.com.  3600  IN  CNAME  s1.dkim.esp.example.

The verifier follows the CNAME and reads the TXT record at the target. Microsoft 365 works this way: selector1._domainkey and selector2._domainkey point to names under your tenant’s onmicrosoft.com domain or, for custom domains added since May 2025, under dkim.mail.microsoft. Copy the exact targets from the provider’s console — Microsoft stresses that the values in its documentation are illustrations only.

Typical mistakes with delegated selectors:

• a TXT record created where the provider asked for a CNAME;
• the domain appended twice by the DNS panel, giving s1._domainkey.example.com.example.com;
• only one selector published when the provider asks for two.

Check your DKIM

1. Run the DKIM checker with your domain and selector. It follows CNAME delegation and reports the key type and size, revoked keys, testing mode and publishing errors such as quotes or spaces pasted into the key.
2. A published key doesn’t prove that your mail is signed with the matching private key. Send a test message and check for dkim=pass with your domain in the email header analyzer.
3. Check that the passing signature’s d= aligns with your From domain, and see which policy applies to failing mail in the DMARC checker.