Multiple DKIM Records: Many Selectors Yes, Two Per Name Never

Yes, and a domain sending real mail almost certainly should have several. Multiple concurrent DKIM keys are the design rather than a workaround, and the mechanism that makes them work is the selector.

The confusion behind the question comes from SPF, which sits next to DKIM in every setup guide and behaves in the opposite way. A domain may publish exactly one SPF record and publishing two breaks it. People reasonably assume DKIM inherits that constraint. It does not, and the rule it does have is narrower and easier to break by accident.

What the specification actually says

RFC 6376 opens its section on selectors with the reason they exist: "To support multiple concurrent public keys per signing domain, the key namespace is subdivided using selectors." It goes on to leave the count entirely to the domain owner: "The number of public keys and corresponding selectors for each domain is determined by the domain owner. Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations can choose to manage disparate selectors and key pairs in different regions or on different email servers."

Every key lives at a name built from its own selector. RFC 6376 fixes the shape: "All DKIM keys are stored in a subdomain named _domainkey. Given a DKIM-Signature field with a d= tag of example.com and an s= tag of foo.bar, the DNS query will be for foo.bar._domainkey.example.com."

So each platform that signs for your domain publishes at its own hostname, and those hostnames do not collide. A receiver never has to choose between them, because the signature it is checking names the selector to fetch.

1. Step 1Each platform signs with its own key

   The DKIM-Signature header carries d= for your domain and s= for that platform's selector.

2. Step 2The receiver reads d= and s=

   Those two values are all it needs to construct the DNS name to query.

3. Step 3One record is fetched

   The lookup goes to selector._domainkey.yourdomain.com, which holds that platform's key and nobody else's.

4. Step 4The signature is verified

   Other platforms' keys at other selectors are never consulted and cannot interfere.

The rule that does apply, and why it fails so quietly

The constraint is per name rather than per domain, and RFC 6376 states it in one sentence: "TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined."

Undefined is the word to sit with. This is not a specified error, and that makes it worse than one. The verification section spells out what a receiver may do when it finds two records at one name: it "can choose one of the key records or may cycle through the key records, performing the remainder of these steps on each record at the discretion of the implementer", and "the order of the key records is unspecified."

So two records at one selector name produces an outcome that depends on which receiver you asked and, potentially, on which record their resolver happened to return first. Some mail verifies. Some does not. The pattern has no shape you can debug from, because a domain in this state fails intermittently across providers rather than failing consistently anywhere.

Several selectors, one key eachThe design

• google._domainkey and vendor._domainkey both published
• Each platform's signature names its own selector
• Every lookup returns exactly one record
• Add, rotate and remove platforms independently

One selector, two recordsThe defect

• Two TXT records answering at the same hostname
• The specification calls the result undefined
• A receiver may pick either, in unspecified order
• Verification succeeds and fails without a pattern

Where the duplicate usually comes from

Almost nobody publishes two records at one name deliberately. Three routes account for most of them.

Re-onboarding a platform. A vendor is reconnected, generates a fresh key, and the new record is added while the old one is left in place because deleting things in DNS feels risky. Both now answer at the same selector.

Two platforms picking the same default. Selector names are chosen by the signing platform, and defaults are not coordinated across vendors. Google Workspace defaults to the prefix google, and its documentation carries the instruction for exactly this collision: "If your domain already uses a DKIM key with the prefix google, enter a different prefix in this field." A vendor that also defaults to something generic, on a domain that already has one, produces the same clash.

A migration that copied the zone. Moving DNS providers can carry both an old and a new record across, particularly where a long key was split into multiple strings and the import handled the split inconsistently.

The fix in all three cases is to delete rather than to add. Read the DKIM-Signature header of a message the platform actually sent, take the s= value from it, and keep the record that matches what is being signed with today.

You cannot list the selectors on a domain

The awkward part of auditing this is that there is no query that returns a domain's DKIM records. DNS answers questions about names you already know, and a selector is an arbitrary label chosen by a signing platform, so there is nothing to enumerate against. A domain could be publishing a key at any string at all, and the only way to find it is to already suspect the string.

That leaves three ways to build the list, and they are worth doing in this order.

Read real message headers. Send yourself a message from each platform, or find one it sent recently, and take the s= value out of the DKIM-Signature header. This is the only method that tells you what is being signed with today rather than what was configured at some point, and it is the reason a selector taken from a vendor's documentation is a guess.

Ask each platform. Every tool that offers domain authentication will tell you the selector it uses, and most publish a default. This catches the platforms that are configured but have not sent recently enough to leave a header to read.

Try the conventional names. Providers reuse a small set, so querying the obvious candidates finds orphans from tools nobody remembers connecting. This is the only method that surfaces a record belonging to a platform that has left, which is exactly the record most likely to be sitting next to a live one at a shared name.

Rotation, which is the one time two keys are correct

There is a sanctioned overlap, and it is the reason keys are separable in the first place. RFC 6376 describes the procedure: to move from one key to another, a domain "merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the february2005 private key. At the end of the transition period, the january2005 public key is removed."

Two keys, two selectors, both live, one signing. That is the correct shape, and it is not the duplicate case, because the two records answer at different names.

The ordering is what people get wrong. Publish the new key first, switch the platform to sign with it, confirm real mail is carrying the new selector, and only then remove the old record. Deleting first breaks verification for every message already in flight, which was signed with a key receivers will still ask for.

The specification also notes a subtler option, which is revoking a key rather than removing it, by publishing the record with an empty key value. It is candid that "there is no defined semantic difference between a revoked key and a removed key", so for a routine rotation, removing the record is the simpler choice.

Auditing DKIM records on a domain

• ✓Yes: Every platform that signs for this domain has a record at its own selector
• ✓Yes: Each selector name returns exactly one TXT record
• ✓Yes: The selector you are querying is the one in a real message's DKIM-Signature header
• ✓Yes: The signing domain in d= is your domain rather than the platform's
• ✓Yes: A rotation has both keys live at different selectors, with the old one removed last
• ✕No: A second record was added at an existing selector during re-onboarding
• ~Depends: An old selector is still published for a platform that no longer sends

That last row is a judgment rather than a defect. An orphaned key at a retired selector authorises nothing by itself, since no message names it, so it is untidy rather than dangerous. It becomes worth removing when nobody can say which platform it belonged to.

Why this matters more when outbound runs on many domains

None of the above inherits between domains. A key published on acme.com does nothing for try-acme.com, even when one account owns both and one platform sends from both, so a portfolio of sending domains is a portfolio of independent key sets.

Two things follow. A rotation is not one task, it is as many tasks as you have domains, which is the strongest argument for accepting a CNAME from a platform that offers one, since the key then lives on the vendor's side and rotates without a DNS edit from you. And an audit of selectors across a fleet is the only way a duplicate at one name on one domain gets found, because it produces no consistent symptom on any single domain.

The reason to care at all is alignment rather than tidiness. DMARC does not ask whether DKIM passed. It asks whether DKIM passed for the domain in the visible From header, and a signature that verifies against the platform's own domain aligns with nothing you own. That is the first entry in the six causes of DMARC failure, and it is why a correct DKIM record on your own domain is what keeps DMARC passing once SPF has stopped contributing. The tags inside the record, including the two that can disable a valid-looking key, are in the DKIM record in practice, the concept is at DKIM, and the registrar-panel version of the same handoff is in DKIM on GoDaddy.

We authenticate every sending domain before it carries a message and run one message per campaign, so a domain whose signature verifies intermittently does not get a second attempt at the same person under a different pretext. Reading the published record back is part of launching rather than part of debugging.

If you would rather not own the authentication layer across a portfolio, we run the sending infrastructure as part of the engagement.

The short version

A domain can hold as many DKIM keys as it has signing platforms, and RFC 6376 says selectors exist precisely so that it can. What a domain must not have is two TXT records at one selector name, because the specification calls that result undefined and permits a receiver to choose either record in unspecified order, which produces intermittent verification rather than a clean failure.

Give every platform its own selector, confirm each name returns exactly one record, and take the selector you audit from a real message's DKIM-Signature header rather than from the platform's documentation. During a rotation, publish the new key at a new selector, switch signing, confirm live mail carries it, and remove the old record last.

Specification behaviour verified as of August 2026 against RFC 6376, and vendor guidance against Google Workspace's published DKIM setup documentation. Verify current key and selector handling with your sending platform before relying on it.

Sources: RFC 6376, DomainKeys Identified Mail Signatures, Set up DKIM, Google Workspace Admin Help