How to find your DKIM selector (and rotate the key safely)

You need to check a DKIM key, rotate it, or work out why signatures fail, and the first thing every tool asks for is the selector, a short name nobody wrote down. The selector decides which DNS record holds the public key, so without it you cannot look the record up. This guide shows how to read the selector from a real message, what to try when you have no message, how long your key should be, and how to rotate a key without a gap in signing.

The short answer#

The selector is the value of the s= tag in the DKIM-Signature header of any message your domain sent. Open the full headers of one message, find DKIM-Signature:, and read s= for the selector and d= for the signing domain. The public key then lives in a TXT record at selector._domainkey.d, for example mail._domainkey.example.com. With no message to hand, ask your sending provider for the DNS record they told you to publish, because the selector is the first part of its name. Your key should be 2048-bit RSA: RFC 8301 requires at least 1024 and says signers should use at least 2048. The email header analyzer shows whether DKIM passed and whether a signature is present, but you read s= and d= yourself from the DKIM-Signature line. Then confirm the DNS side with the SPF, DKIM and DMARC checker.

Read the selector from a message header#

Send yourself an email from each system that sends as your domain, such as your mailbox provider, your marketing platform, your transactional service and your helpdesk. Open the original source or headers of the received copy. In Gmail, use the message menu and choose "Show original". Find the line that starts with DKIM-Signature:.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=mail2026; t=1730700000;
  h=from:to:subject:date; bh=...; b=...

Here d=example.com is the domain that signed and s=mail2026 is the selector. The key therefore sits at:

mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Query it directly to confirm:

dig +short TXT mail2026._domainkey.example.com

Two things to watch for. A message can carry more than one DKIM-Signature, for example one from your own domain and one from the sending service's domain. Look at each d= value. And pay attention to whether d= is your domain at all. Many platforms sign with their own domain by default, which passes DKIM but does not align with your From address for DMARC. If d= is not you, the sender is not yet set up for your domain, and the alignment failures that follow are easy to mistake for a DNS problem.

What to do when you have no message#

Sometimes there is nothing to open: you inherited a domain, the sender is dormant, or you want to audit before sending. You have three options.

1. Check the provider's setup page. When you authenticated a domain with a sender, it told you to publish a CNAME or TXT record. Its name starts with the selector, for example selector._domainkey. That record, still present in your DNS zone, is the answer.
2. Read your DNS zone. Look for names ending in ._domainkey. The label before it is a selector. Your DNS host's record list, or a zone export, shows them all, which is the one place you can enumerate what exists.
3. Guess from common names. Providers use predictable defaults, and a tool can try them for you. Qualisend's Domain Health Monitoring probes 25 common names when you have not configured any selectors: google, selector1, selector2, k1, k2, s1, s2, dkim, default, mail, smtp, mandrill, sendgrid, krs, protonmail, zendesk1, zendesk2, mxvault, everlytickey1, hs1, hs2, pm, fm1, fm2 and fm3. A hit tells you a key exists. A miss tells you nothing, because custom selectors such as mail2026 are invisible to guessing.

Guessing is a fallback. Anything you rely on should be written down with its selector, which is why the first step of a domain health routine is to list every sender and its selector.

Anatomy of a DKIM key record#

The record in DNS is a list of tags, and it helps to know what each one does.

Many providers publish a CNAME at the selector name that points to a key they host, so the record you see may be an alias. That is normal: it lets the provider rotate keys for you. It also means that if the provider removes the target, your selector silently stops resolving.

Key length: 1024 or 2048#

RFC 8301 sets the rules. Signers must use RSA keys of at least 1024 bits and should use at least 2048. Verifiers must not treat keys below 1024 as valid. Google's sender guidelines agree: 1024 is the minimum, and 2048 is recommended. So a 1024-bit key still works, which is exactly why it often survives for years, and it is the first thing to upgrade.

There is one practical wrinkle. A 2048-bit public key is longer than the 255 characters a single DNS string can hold. The record must be published as several quoted strings inside one TXT record, which DNS joins back together.

mail2026._domainkey.example.com.  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                          "...rest-of-the-key..." )

Most DNS hosts do this automatically when you paste the full value, but not all, and the failures are quiet: a key that is truncated or contains stray characters fails verification even though the record exists. After publishing, query it and compare the length. The DNS provider guides show how individual hosts handle long values.

If a service generates your key, you usually pick the length in its settings when you create it, and changing it means generating a new key and a new selector, which is a rotation.

Rotating a key without a gap#

Rotation is replacing a key with a new one on a new selector. There is no law that says how often. Advice we would stand behind is to rotate when a key is below 2048 bits, when someone with access to the private key leaves, after any suspected exposure, and otherwise on a schedule your team will actually keep, such as once or twice a year. The procedure matters more than the cadence.

1. Generate the new key at your provider, or on your own mail server, with a new selector name, such as mail2027. Never reuse the old name.
2. Publish the new record in DNS and wait until public resolvers return it. Check with dig before doing anything else.
3. Switch signing to the new selector in the sending system. From now on messages carry s=mail2027.
4. Leave the old record in place for a while. Messages signed with the old key may still be in transit or queued, and receivers verify when they receive, not when you sent. A week is a common, cautious wait.
5. Retire the old key by deleting the record, or publish it with an empty p= to show it is revoked on purpose.
6. Confirm by sending a test message and checking that s= shows the new selector and DKIM passes.

The most common mistake is doing step 5 before step 3, or skipping step 2 entirely, which means mail signed with a selector that has no key.

Watching a selector over time#

A DKIM record is easy to break and nobody notices. An old key removed too early, a CNAME whose target disappeared, a key revoked by an overenthusiastic cleanup: each leaves mail signing with a selector that no longer resolves. Domain Health Monitoring lets you list up to 10 DKIM selectors for a domain and checks them every day. For each one it confirms a key is present, reads the RSA key size, and flags a missing or revoked key as a bad issue, a 1024-bit key as a warning, anything shorter as bad, and the t=y testing flag as a warning. If you configure none, it falls back to the 25 common names above and warns when none yield a key.

Remember the consequence for rotation. Once you retire an old selector, remove it from the monitored list too, or it will report a missing key. And a limit: it reads DNS, so it cannot see which selector your mail actually signs with, and it does not alert on key age. The broader picture, including SPF and DMARC, is in email domain health monitoring, and the SPF side of the same checks is in SPF too many DNS lookups. Setting up DMARC covers how alignment uses the d= domain.

DKIM proves a message really came from your domain, but not that the address on the other end is real. The free email checker tests one address at a time for syntax, MX records and typos. To clean a whole list, the free plan on the pricing page includes 100 credits that run the full verification, because a correctly signed message still needs a healthy list to earn the inbox.