DKIM: finding your selector and fixing key problems

How DKIM signs a domain’s mail, how to find your selector, and what a missing, broken, or revoked key means.

DKIM signs each message your mail service sends with a private key. The signature goes in a DKIM-Signature header, and receivers check it with a public key you publish in DNS. If the message was changed on the way, or wasn’t signed with your key, the check fails.

The signature travels with the message, so DKIM still passes when a message is forwarded unchanged, where SPF often fails. DMARC counts a DKIM pass when the signing domain (d=) is your domain, or a subdomain of it.

What SignalDNS checks

A DKIM key lives at a name built from a selector, such as google._domainkey.example.com. DNS has no way to list the selectors a domain uses, so we check DKIM only when you give us a selector, or ask us to try common ones.

With a selector, we read the TXT record at that name. We follow a CNAME there, as receivers do, and join a long key that’s split into several strings. We report whether a key is published, its type (k=, RSA unless it says otherwise), and whether it has been revoked.

If you choose Try common selectors, we try up to 12. First come the ones your mail provider uses, which we recognise from your MX records: for example selector1 and selector2 for Microsoft 365, or fm1 to fm3 for Fastmail. Then come widely used ones, such as default, s1, and k1. We report the first one that has a key. Finding none doesn’t mean DKIM is off: your provider may use a selector we didn’t try.

What a DKIM record looks like

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

google is the selector. _domainkey is always the same.
v=DKIM1 is optional. If it’s there, it must come first.
k= is the key type: rsa, the default, or ed25519.
p= is the public key. Your mail service generates the key pair and gives you this part.

A 2048-bit RSA key is longer than the 255 characters one TXT string can hold, so it’s stored as several strings in one record. Some DNS providers split it for you; with others, you paste it in parts. Either way it stays one record.

Many providers give you a CNAME to publish instead of the key, pointing at a record they host. Microsoft 365, Fastmail, and iCloud Mail work this way. The provider can then change the key without you editing DNS.

How to find your DKIM selector

From a message. Send yourself an email from the domain and view the message source (in Gmail, “Show original”). Find the DKIM-Signature header. s= is the selector, and d= is the domain it signs for:
```
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...
```
A message can carry more than one signature. Use the one whose d= is your domain.
From your provider. Google Workspace uses google unless you chose another prefix. Microsoft 365 uses selector1 and selector2. Fastmail uses fm1, fm2, and fm3, and iCloud Mail uses sig1. Other providers show the selector where you set up DKIM.
From SignalDNS. Leave the selector empty and choose Try common selectors.

Each service that sends as your domain, such as a newsletter or invoicing tool, usually signs with its own selector. Checking one selector doesn’t check the others.

There’s no DKIM key for this selector

Nothing is published at the selector’s name. If your mail is signed with this selector, receivers can’t find the key, and DKIM fails. SignalDNS marks this as needing attention.

The usual causes are a misspelled selector, a selector from another domain, DKIM never being set up at the provider, or a record added under the wrong name. Some DNS providers add your domain to the name for you, so entering the full name gives google._domainkey.example.com.example.com.

How to fix it:

Confirm the selector from a message header, as above.
In your provider’s admin console, generate the DKIM key, or get the CNAME records.
Publish it with the host set to your selector followed by ._domainkey, such as google._domainkey, and let your DNS provider add the domain.
Turn signing on. Google Workspace and Microsoft 365 don’t sign with your key until you do.
Check again here with the same selector. A new record can take a while to reach every resolver; see DNS resolvers and propagation.

The DKIM record is broken

There’s a record at the selector’s name, but receivers can’t use it, so mail signed with this selector fails DKIM. SignalDNS marks this as a problem. The causes we report:

No public key. The record has no p= tag. That happens when only part of the value was copied, or when another kind of record was published at this name.
The wrong version. v= is there but isn’t DKIM1.
More than one record at the name. RFC 6376 leaves the result undefined, so receivers may use either one.

How to fix it: delete what’s there and publish exactly what your provider gives you, as one record. Copy it from the provider’s console, not from a document or chat, which can change quotes or cut the value short.

The DKIM key has been revoked

The record has an empty p=. RFC 6376 uses that to mean the key has been revoked, and receivers fail any signature made with it. SignalDNS marks this as needing attention.

That’s the right state for a selector you’ve retired. It’s a problem if your mail is still signed with this selector.

How to fix it: if you still sign with this selector, publish its current key, or switch signing to a selector that has one. If you retired it on purpose, nothing needs fixing.

RSA or Ed25519 keys

Most DKIM keys are RSA. RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048. Receivers must be able to check keys up to 4096 bits. Use 2048 if your DNS provider can store it; Google’s guide gives the same advice.

Ed25519 keys (k=ed25519, RFC 8463) give similar security with much shorter keys, so they fit in a single TXT string. Receivers that don’t support Ed25519 can’t use those signatures, so RFC 8463 describes signing with both: one RSA and one Ed25519 signature, each with its own selector.

SignalDNS reports the key type from k=. We don’t check the length of an RSA key.

Rotating DKIM keys

Changing keys from time to time limits the damage if a private key leaks. With the CNAME records many providers use, the provider changes the key for you. Microsoft 365 uses its two selectors for this: one signs, and the other is used after the next rotation.

To rotate a key yourself:

Generate a new key pair and publish the public key under a new selector, such as s2 beside s1.
Check here that the new key is visible.
Switch signing to the new selector.
Keep the old key published for a while, because receivers may check a signature some time after delivery. RFC 6376 advises keeping the old key for a reasonable time.
Then delete the old record, or revoke it with an empty p=.

Your provider’s guides

What we can’t tell from outside

We can only check selectors you give us or that we try. We read the published record, but we don’t check that the key itself is valid, how long it is, or that it matches the private key your provider signs with. We don’t send or verify mail, so we can’t tell whether your messages are signed at all. DMARC reports show whether your mail passes DKIM.

Sources

Last reviewed September 30, 2026.