Email errors

Multiple DKIM records: when several selectors are fine and when two records conflict

Several DKIM keys under different selectors are normal. Two TXT records at the same selector conflict: what verifiers do with them and how to keep one.

By Updated Last verified

On this page
  1. Several selectors are normal
  2. Two records at the same selector conflict
  3. One record in several strings is not a duplicate
  4. A CNAME and a TXT at the same name
  5. How to fix a conflict
  6. Why a scan cannot list every selector
  7. Check your keys
  8. Sources

A domain can publish several DomainKeys Identified Mail (DKIM) keys, as long as each one sits under its own selector: RFC 6376 (opens in a new tab) subdivides the key namespace with selectors to support multiple concurrent public keys per signing domain. What conflicts is two TXT records at the same selector name. The standard requires TXT records to be unique for a selector name, and with several records the results are undefined (section 3.6.2.2 (opens in a new tab)). To fix it, keep the one record the sending service's own setup screen gives you for that selector, and delete the other.

Several selectors are normal

DKIM (opens in a new tab) lets an organization claim some responsibility for a message by associating its domain name with it. All DKIM keys are stored under a subdomain named _domainkey, and the DNS name comes from the signature: a d= tag of example.com and an s= tag of s1 mean a query for s1._domainkey.example.com (RFC 6376 section 3.6.2.1 (opens in a new tab)).

Selectors exist to support multiple concurrent public keys per signing domain, and the domain owner decides how many keys and selectors it has (section 3.1 (opens in a new tab)). One use the standard lists is delegating signing to a partner, such as an advertising provider or another outsourced function.

Checked against live DNS, github.com publishes keys under several selectors, including these three:

Name Type Value
google._domainkey.github.com TXT a key starting v=DKIM1; k=rsa; p=
s1._domainkey.github.com CNAME s1.domainkey.u51742174.wl175.sendgrid.net
selector1._domainkey.github.com CNAME selector1-github-com._domainkey.microsoft.onmicrosoft.com

Each selector name matches one its provider documents. google is Google Workspace's (opens in a new tab) default prefix selector. Twilio SendGrid's (opens in a new tab) example publishes s1._domainkey.example.com as a CNAME record, and Microsoft (opens in a new tab) uses the hostnames selector1._domainkey and selector2._domainkey for all Microsoft 365 organizations.

Checked against live DNS, the CNAME target s1.domainkey.u51742174.wl175.sendgrid.net returned a TXT record starting k=rsa; t=s; p=, and selector1-github-com._domainkey.microsoft.onmicrosoft.com returned one starting v=DKIM1; k=rsa; p=.

One service can also use two selectors. Microsoft 365 generates two key pairs and uses one selector at a time; Twilio SendGrid uses s1 and s2 interchangeably and rotates them when necessary. To find the selectors your own services use, see DKIM selector.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Two records at the same selector conflict

A DNS name can hold several records of the same type with different data. Together they form a Resource Record Set (RRSet) (RFC 2181 section 5 (opens in a new tab)), and a query for that name and type always returns all of them (section 5.1 (opens in a new tab)).

For a DKIM key that is the conflict. RFC 6376 section 3.6.2.2 (opens in a new tab) requires TXT records to be unique for a selector name: if the RRSet holds multiple records, the results are undefined. This is what it looks like, with shortened keys:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...old"
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...new"

When the key query returns multiple records, the verifier can choose one of them or cycle through them, at the implementer's discretion, and the order of the records is unspecified (section 6.1.2 (opens in a new tab)). If the signature does not validate, the verifier should ignore it and return PERMFAIL (signature did not verify) (section 6.1.3 (opens in a new tab)). If a header already shows a DKIM failure, DKIM fail explains how to read the reason in brackets.

One record in several strings is not a duplicate

A TXT record holds one or more character-strings, and each string carries at most 255 characters after its length octet (RFC 1035 section 3.3 (opens in a new tab)). A 2048-bit DKIM key record is longer than 255 characters. Most DNS hosts split it for you (DKIM record generator). The standard requires the strings in a TXT record to be joined with no whitespace between them before use.

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..." "...IDAQAB"

That is one record holding one key. Two separate TXT records at the same name, each with its own key, are the conflict above.

A CNAME and a TXT at the same name

Some services have you publish a CNAME at the selector name instead of a TXT key. In Microsoft 365 (opens in a new tab), the CNAME records point to the public keys used to verify the DKIM signature. Twilio SendGrid (opens in a new tab) generates three CNAME records when you turn on automated security.

A name with a CNAME record should hold nothing else. If a CNAME is present at a name, no other data should be present, so that the data for an alias and its canonical name cannot differ (RFC 1034 section 3.6.2 (opens in a new tab)). RFC 2181 section 10.1 (opens in a new tab) puts it as a rule: for any domain name, exactly one of these is true. One CNAME record exists, optionally accompanied by the DNSSEC records SIG, NXT and KEY; one or more records exist, none of them a CNAME record; the name exists but has no records of any type; or the name does not exist at all.

So if s1._domainkey.example.com already holds a TXT key from an earlier setup, it should not also hold the CNAME a service asks for. Keep one or the other at the selector name.

How to fix a conflict

Start by listing what is at the name. If you're not sure which DKIM keys you set up for other services, Google (opens in a new tab) advises checking your DNS records at your domain host.

  1. In your DNS host, find every TXT and CNAME record at the selector name, for example s1._domainkey on example.com.
  2. Open the setup screen of the service that signs with that selector and copy the record it asks for. In Google Workspace, you copy the DKIM values shown in the Authenticate email window; in Microsoft 365 (opens in a new tab), the Defender portal or Exchange Online PowerShell shows the required CNAME values for a custom domain.
  3. Keep the record that matches what the service shows and delete the others, so the name holds one TXT record or one CNAME.
  4. Run the DKIM check to see the keys it finds under common and provider selectors.

When two services want the same selector, give one of them another name. Google covers its own case: if your domain already uses a DKIM key with the prefix google, enter a different prefix.

To replace a key, don't paste a new key under the old selector. Reusing a selector with a new key makes a message that failed because the key is no longer valid impossible to tell apart from a forged one, so signers are advised to assign new keys to new selectors (RFC 6376 section 3.1 (opens in a new tab)). Both keys stay published, each under its own selector, during the transition period while mail signed with the old key may still be in transit; at the end of it, the old key is removed. DemiSignal's DKIM record generator follows the same pattern: a new selector for each rotation, so the old and new key can be published side by side.

Why a scan cannot list every selector

A verifier reads the selector from the signature it checks: the key name is built from the s= and d= tags (RFC 6376 section 3.6.2.1 (opens in a new tab)). The domain owner decides how many selectors to use. Some domains avoid selector names that would let outside parties harvest data, and a selector can be an unassociated random value, such as a fingerprint of the public key (section 3.1 (opens in a new tab)).

DemiSignal's DKIM check tries the selectors common services use and the ones your SPF and MX records point to; a service that uses its own selector name will not be found that way. The full check marks such a case as not verified: DNS answered, but the result cannot be confirmed from DNS alone. If your provider uses a selector the check does not try, the key is there but the check cannot see it.

A missing selector in a scan does not prove a domain has no DKIM. The selector is in the s= value of the DKIM-Signature header of an email the service sent; DKIM selector shows where to look.

Check your keys

DemiSignal's DKIM check finds the DKIM keys a domain publishes under common and provider selectors, with each key's type, size and what to fix. A key record with an empty p= tag has been revoked, and a verifier must treat it as a failed signature check (RFC 6376 section 6.1.2 (opens in a new tab)).

The free check covers SPF, DKIM and DMARC records and looks for DKIM keys under commonly used selectors. It only reads the public DNS records of the domain you enter, and no account is needed. For a new key under a new selector, the DKIM record generator makes the key pair and the TXT record to publish.

Sources

Tools for this

Frequently asked questions

Can a domain have more than one DKIM record?

Yes, as long as each key sits under its own selector. Selectors exist so one domain can publish several keys at once, and each sending service publishes its key at its own selector name.

What happens if two DKIM records share a selector?

RFC 6376 requires TXT records to be unique for a selector name, and the results are undefined when there are several. A verifier may pick one of the records or cycle through them, and their order is unspecified.

Can a DKIM selector have both a CNAME and a TXT record?

No. If a CNAME record is present at a name, no other data should be present there; the only exceptions RFC 2181 allows are certain DNSSEC records. Keep either the CNAME or the TXT record at the selector name, not both.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account