A DKIM selector is scoped to a signing domain. Two services can safely use the word “default” under different d= domains, but default._domainkey.example.com is one DNS owner name. If two independent services need different keys at that same name, adding the second service can break verification for the first. Resolve the ownership collision before changing DNS.
Compare the complete names
Collect a recently received signed message from each active service and record d= and s=. Compare those values with the pending provider setup instructions. For DNS-based key retrieval, the selector and signing domain determine the lookup name. A provider label such as “selector 1” in a setup screen is not enough to identify the real DNS owner. RFC 6376 §3.5 and RFC 6376 §3.6.2.1.
Illustrative example: payroll and marketing both request s=default with d=example.com, but each holds a different private key. Both signatures lead verifiers to default._domainkey.example.com. Replacing payroll's public key with marketing's key can leave payroll messages unverifiable, including messages already in transit. Conversely, default under d=payroll.example.com and default under d=marketing.example.com are different lookup names. Alignment implications still need a separate check.
Choose a supported separation design
Prefer distinct selectors for independent signing services when the providers support them. Publish the new service's generated public-key record at its own owner name, validate it, then enable that signer and test received mail. If a service fixes its selector name, ask whether it supports a separate signing subdomain or another documented configuration. Do not invent a CNAME target or rename a selector solely in DNS: the signer must emit the matching s= value.
Changing d= to a subdomain can affect DMARC. A subdomain may align under relaxed rules while failing strict alignment with a parent Author Domain. Confirm the intended relationship before choosing the naming workaround. RFC 9989 §4.4.1 and RFC 9989 §4.10.2.
Do not rely on ambiguous key answers
Under RFC 6376 §3.6.2.2, TXT key records must be unique for a selector name; multiple-record results are undefined. Publishing multiple different keys at one owner violates that publication rule and is not a service-separation design. RFC 6376 allows a verifier to select one returned key or try several at its discretion, with unspecified ordering. A configuration that works at one receiver can therefore be unreliable elsewhere. Separate selectors provide an explicit mapping instead of relying on key-selection behaviour. RFC 6376 §6.1.2.
Multiple quoted character strings within one TXT resource record are a different issue: they can be parts of a single record. Do not mistake provider display wrapping for multiple distinct keys. Compare the actual DNS answers and the provider's generated value, using a suitable DNS tool.
Handle an existing collision safely
If a collision has already occurred, capture current DNS, configuration history, affected d/s pairs and receiver failures. Restore the previous mapping only if it is safe and still needed, then bring the new service online under a supported distinct selector. Avoid sharing private keys between unrelated services merely to make them fit one public record; that expands custody and incident impact.
Keep the old verification record for the overlap your legitimate delayed-mail path needs, subject to security considerations and the provider's rotation process. A compromised key is a different case and may require immediate revocation despite delivery impact. Test both services independently after the change, record their owners and reserve their selector names in the inventory. The acceptance test is two verifiable, intended identities, not simply two green provider setup screens.
Resolve a synthetic two-service request
Assume payroll currently signs with s=default and d=example.com, and marketing requests that same pair with a different key. The lookup owner is identical, so do not overwrite it or publish the second independent key beside it. If marketing supports s=marketing2026, publish its generated key at marketing2026._domainkey.example.com and configure that same selector in its signer. Then test payroll/default and marketing/marketing2026 independently. If only a signing-subdomain option is supported, review its alignment before changing d. These are planning steps, not a tested provider procedure.