# DKIM Selectors and Key Rotation: A Practical Guide URL: https://email-validation.org/guides/dkim-selectors-key-rotation/ Updated: 2026-11-06 > Documentation index: https://email-validation.org/llms.txt 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 `._domainkey.`. 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](https://www.rfc-editor.org/info/rfc6376/) 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: ```text 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=`: ```text 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](https://www.rfc-editor.org/info/rfc8601/)). 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](https://www.rfc-editor.org/info/rfc9989/)). Paste the domain and selector into the [DKIM checker](https://email-validation.org/tools/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: - **One per service.** The mailbox provider, the newsletter platform and the billing system each sign with their own key. M3AAWG's [DKIM Key Rotation Best Common Practices](https://www.m3aawg.org/DKIMKeyRotation) advise against sharing the same key across several parties. Providers pick their own default names; Google Workspace, for example, uses `google` and asks you to choose another prefix if your domain already has a key under that name ([Google: Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim)). - **One per key.** Never put a new key under an old selector. RFC 6376 warns that reusing a selector makes a message that fails because its key was replaced look just like a forgery. M3AAWG adds that old messages fail any re-check against the new key and that receivers may still hold the old value in cache. 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](https://www.rfc-editor.org/info/rfc8301/) updated the rules of RFC 6376: - Sign with `rsa-sha256`. `rsa-sha1` must not be used for signing or verifying, and signatures that use it fail. - RSA keys must be at least 1024 bits, and signers should use at least 2048 bits. - Receivers must not accept signatures made with keys shorter than 1024 bits, and must be able to verify keys from 1024 to 4096 bits. 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](https://www.rfc-editor.org/info/rfc8463/) 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](https://email-validation.org/tools/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: ```text 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](https://email-validation.org/tools/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](https://email-validation.org/bounce-codes/550-5-7-30/) ([Gmail SMTP errors](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)). If DKIM was your only aligned pass, DMARC fails too, and under `p=reject` Microsoft refuses the message with [5.7.509](https://email-validation.org/bounce-codes/5-7-509/) ([Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)). 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](https://email-validation.org/guides/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](https://email-validation.org/tools/dkim-checker/), and test an address you mail with the free [email checker](https://email-validation.org/email-checker/). ## Related - [DKIM generator](https://email-validation.org/tools/dkim-generator/) and [DMARC checker](https://email-validation.org/tools/dmarc-checker/). - [Bounce code 550 5.7.30](https://email-validation.org/bounce-codes/550-5-7-30/): DKIM failed at Gmail. - [Glossary: SPF, DKIM and DMARC](https://email-validation.org/glossary/#spf-dkim-dmarc). ## Related guides - [The SPF 10-lookup limit explained](https://email-validation.org/guides/spf-lookup-limit/) - [Moving DMARC from p=none to p=reject](https://email-validation.org/guides/dmarc-none-to-reject/) - [How to read DMARC aggregate reports](https://email-validation.org/guides/dmarc-aggregate-reports/) - [Gmail and Yahoo sender requirements](https://email-validation.org/guides/gmail-yahoo-sender-requirements/) - [Outlook.com requirements for high-volume senders](https://email-validation.org/guides/outlook-sender-requirements/) - [All guides](https://email-validation.org/guides/) ## Sources - [RFC Editor: RFC 6376, DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/info/rfc6376/): selectors and transitions (3.1), key sizes (3.3.3), unknown algorithms (3.3.4), revoked keys (3.6.1), the `_domainkey` namespace and TXT records (3.6.2). - [RFC Editor: RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/info/rfc8301/): `rsa-sha1` retired, minimum and recommended RSA key sizes. - [RFC Editor: RFC 8463, A New Cryptographic Signature Method for DKIM](https://www.rfc-editor.org/info/rfc8463/): Ed25519 keys and dual signing. - [RFC Editor: RFC 9989, DMARC](https://www.rfc-editor.org/info/rfc9989/): DKIM alignment (4.4.1). - [RFC Editor: RFC 8601, Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/info/rfc8601/): `header.s` in Authentication-Results. - [M3AAWG: DKIM Key Rotation Best Common Practices](https://www.m3aawg.org/DKIMKeyRotation) (March 2019): rotation frequency, selector naming, third-party keys, the 7 to 30 day overlap, revocation and audits. - [Google: Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim): key length choice, the `google` prefix, TXT length limits. - [Google: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes): 550 5.7.30. - [Microsoft Learn: Email nondelivery reports and SMTP errors in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online): 5.7.509. ## 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](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).