Sign in Get up to 500 free credits

DKIM selectors and key rotation

A DKIM selector is the label that tells a receiver where to find the public key for a signature: the s= and d= values in the signature point to the TXT record at <selector>._domainkey.<domain>. Each selector holds one key, so a domain can have as many as it needs, one per service and a new one for every new key. That is what makes rotation painless: publish a key under a new selector, sign with it, keep the old key published while mail signed with it is still on its way, then revoke the old key with an empty p=. Use RSA keys of 2048 bits where you can, never shorter than 1024, and rotate at least every six months, as M3AAWG recommends.

How a selector works

RFC 6376, section 3.1 uses selectors so that one signing domain can have several public keys at the same time. Section 3.6.2.1 defines where they live: every DKIM key sits under a subdomain named _domainkey. A signature with d=example.com and s=news-202611 makes the receiver query this name:

news-202611._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Selectors may contain periods, which become separate DNS labels, so 2026-11.news works too and lets you delegate part of the selector namespace. Section 3.6.2.2 requires one TXT record per selector name: if a name holds several, the result is undefined. That is why two keys always need two selectors.

Find the selector in a message

Open a message you sent and view its full headers. The DKIM-Signature header names the domain in d= and the selector in s=:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=news-202611; t=1793990400; h=from:to:subject:date; bh=...; b=...
Authentication-Results: mx.example.org;
 dkim=pass header.d=example.com header.s=news-202611

The receiver records what it checked in Authentication-Results, where header.s holds the selector and header.d the domain (RFC 8601, section 6.3.2). A message can carry more than one DKIM-Signature. For DMARC, what counts is a passing signature whose d= aligns with your From: address (RFC 9989, section 4.4.1). Paste the domain and selector into the DKIM checker to see the published key, its type and size.

Multiple selectors per domain and per service

How many selectors a domain has is up to its owner (RFC 6376, section 3.1). The RFC expects many owners to need just one, but separate selectors keep things clear once several systems sign for you:

M3AAWG suggests names that carry the stream, the planned start date and the key length, in the style of sales-201309-1024. A scheme like that makes audits easy. RFC 6376 also cautions against names that reveal more than you want, such as the name of an individual user.

Keys for third-party senders

M3AAWG describes three ways to give a sending service a key on your domain:

  1. You publish the key. Either you generate the pair and send the private key to the service over an encrypted channel, or the service generates it and gives you only the public key, so the private key never travels. In the second case, confirm the key size and agree on the date the key will be retired.
  2. A delegated subdomain. The service controls a subdomain and its records. M3AAWG notes that this adds risk: the service could, for example, publish a DMARC record there that overrides your policy. Audit delegated subdomains.
  3. CNAME delegation. You publish several selectors as CNAMEs that point to records the service hosts. With three of them, the service can sign with one key while it rotates the others.

M3AAWG expects the request to rotate to come from the domain owner. If a service manages your key through CNAMEs, ask how and when it rotates.

Key length and algorithms

RFC 8301 updated the rules of RFC 6376:

Google recommends 2048-bit keys where your DNS host supports them and 1024 bits otherwise. Long keys are a DNS problem more than a crypto one. RFC 8301 notes that RSA keys much longer than 1024 bits do not fit in one 256-octet TXT string, and that some DNS software handles only one string. The fix is to publish the key as several quoted strings in one record, which receivers join without spaces (RFC 6376, section 3.6.2.2). Google also warns that some DNS hosts limit TXT record length. M3AAWG adds that your DNS servers must answer large records over EDNS0 or TCP. RFC 6376 (section 3.3.3) points out that very large keys, such as 4096 bits, might not fit in a 512-byte DNS answer.

Ed25519

RFC 8463 adds the ed25519-sha256 algorithm, published with k=ed25519. The public key is only 44 characters in base64, so the record fits in one string even at DNS hosts that cannot handle long records. The RFC says receivers must implement it and signers should. But a receiver that does not know an algorithm ignores that signature (RFC 6376, section 3.3.4), so for backward compatibility RFC 8463 lets you sign each message with both algorithms. Because each selector holds a single key, the RSA and the Ed25519 signatures need different selectors, with the same d=.

How often to rotate

M3AAWG recommends rotating DKIM keys at least every six months. Its members settled on twice a year as the balance between the risk of a cracked or stolen key and the work involved. Organizations with simple mail flows can rotate more often. Pick fixed dates: M3AAWG calls April and October a reasonable spread for many online retailers, as it avoids the heavy buying season. Regular rotation also keeps the process familiar, so an emergency rotation after a suspected compromise is routine rather than improvised. To be ready for one, M3AAWG suggests publishing the next public key in advance.

Rotate without breaking mail

This sequence follows RFC 6376, section 3.1, and the steps in M3AAWG's paper:

  1. Publish the new key under a new selector. Generate the pair, publish the public key and wait until DNS has propagated. Check it with the DKIM checker before you sign anything with it.
  2. Switch signing to the new selector. From now on, every new message carries the new s= value.
  3. Keep the old key published, unchanged. Mail signed with the old key may still be queued or in transit, and receivers may verify it later. M3AAWG says to leave the old key in DNS for at least seven days and up to 30 days.
  4. Revoke the old key with an empty p=. RFC 6376 (section 3.6.1) defines an empty p= as a revoked key. M3AAWG asks you to keep the record rather than delete it, so it is visible that the key was retired on purpose.
  5. Audit about a week later. Check the d= and s= of messages from each stream against the selectors you expect to be active, as M3AAWG recommends.

After a few rotations, your DNS looks like this:

dkim1._domainkey.example.com.  TXT  "v=DKIM1; p="
dkim2._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...old"
dkim3._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...current"
dkim4._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...next"

Here dkim1 is revoked, dkim2 still verifies older mail, dkim3 signs new mail and dkim4 is ready for the next rotation. The DKIM generator creates a 2048-bit pair in your browser and formats the record as quoted strings.

When a rotation goes wrong

A rotation breaks when the signer switches before the new key is visible in DNS, when the old key is retired while mail signed with it is still arriving, or when the published key does not match the private key. Gmail reports a bulk sender's failed DKIM check as 550 5.7.30 (Gmail SMTP errors). If DKIM was your only aligned pass, DMARC fails too, and under p=reject Microsoft refuses the message with 5.7.509 (Exchange Online NDR reference). DMARC aggregate reports, which M3AAWG recommends for mapping your mail streams, arrive daily and show which messages carried valid DKIM signatures, so a broken rotation shows up there (DMARC aggregate reports).

Questions

Can two services share one selector?

No. A selector name can hold only one key record, and M3AAWG advises against sharing a key between parties. Give each service its own selector, or its own set if it rotates through CNAMEs.

Should I delete the old selector after rotation?

RFC 6376 says there is no defined difference between a revoked key and a removed one. M3AAWG prefers revoking: keep the record with an empty p= so anyone checking can see the key was retired on purpose.

Is a 1024-bit key still acceptable?

It meets the minimum of RFC 8301 and Google accepts it, but RFC 8301 says signers should use 2048 bits, and M3AAWG wrote in 2019 that 1024-bit keys were "at the edge of attack" for general-purpose computers. Move to 2048 bits at your next rotation, under a new selector.

Try it

Look up your current key with the DKIM checker, and test an address you mail with the free email checker.

Sources

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.

Get up to 500 free credits. No card needed.

New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy.

Create your account Open the free email checker

Updated · Maintained by the email-validation.org team