---
title: "DKIM Selector Conflicts on Whitelabeled Sending Domains"
canonical: "https://support.activedemand.com/space/EC/1162575875/DKIM+Selector+Conflicts+on+Whitelabeled+Sending+Domains"
format: markdown
---
This runbook covers the recurring escalation where a community's DKIM CNAMEs can't be verified because `s1._domainkey` / `s2._domainkey` are already claimed on that domain by a different SendGrid tenant. Worked examples: ADCS-83015 / ADCS-83198 (Dr. Bishop & Associates, account 4468411, May 2026) and ADCS-86210 / ADCS-86218 / ADCS-86368 / ADCS-86452 (Smith Senior Living, account 3689627, Aug 2026). The same procedure applies to any account.


## Symptom

A community is setting up email whitelabeling. In **Account Setup → View Whitelabeling** (`/portal/cname_records`):

- `www2`, `link`, the mail CNAME (`email2...`), SPF TXT and DMARC TXT all verify normally.
- The two DKIM CNAMEs show as **not verified** and never turn green, no matter how many times the client re-adds them.
- The DKIM records we're handing them are named `s1._domainkey.<domain>` and `s2._domainkey.<domain>`.
- The client (or their IT team) reports that `s1`/`s2` on that domain already point at **someone else's** SendGrid account — a separate vendor, agency, or web provider, unrelated to ActiveDEMAND.

Clients often ask for `s3`/`s4`. See "What to tell the client" — that's not what they'll get, and it doesn't matter.


**Fix  UI only.** This is what CS did on ADCS-83015. In the client's account, **Administration → Account Settings → Email Sending Domain** (a free-text field, `app/views/accounts/_client_form.html.erb:693`):

1. Change `email2.<domain>` to `email3.<domain>` and save. The `after_save` → `check_whitelabel` → Sidekiq `SendgridParser :setup_account` → `validate_whitelabel` → `generate_whitelabel` chain sees the mismatch, deletes the old `s1`/`s2` domain, and creates a new one with the `ad` selector.
2. Give the client the new `ad._domainkey` / `ad2._domainkey` CNAMEs and wait for them to be added and propagate.
3. Set the field back to `email2.<domain>`. This re-creates once more, still with the `ad` selector, and the CNAME host and target strings are unchanged — the target is keyed off the subuser, which doesn't change.