DKIM CNAME delegation: the vendor convenience that needs an offboarding plan

A vendor asks you to add two or three CNAME records such as s1._domainkey.example.com. The setup looks innocuous: point the selector at a name the vendor controls, then let the vendor publish and rotate the DKIM public key. It is a useful pattern, but it has a governance consequence that is easy to miss.

The CNAME means a third party can control the public key receivers fetch when verifying mail signed for your domain and selector. That does not give the vendor your DNS account or your entire domain. It does mean the selector remains an active authentication path until you remove it. Treat it like a narrowly scoped delegation with an owner and an end date.

What the record actually delegates

A DKIM signature carries a signing domain in d= and a selector in s=. A receiver combines them to find the public key at a DNS name such as s1._domainkey.example.com. The DKIM standard describes this public-key lookup and makes DNS part of the verification path. It also explicitly supports signing by third parties.

DKIM-Signature: v=1; d=example.com; s=mailer1; ...

Receiver looks up:
mailer1._domainkey.example.com  CNAME  mailer1.example.vendor-dkim.net
mailer1.example.vendor-dkim.net TXT    "v=DKIM1; k=rsa; p=..."

The company still owns example.com and decides which selector names point away. The vendor controls what the delegated target returns. That lets the vendor rotate a public key without asking for another DNS change, which is why large sending platforms prefer CNAME-based DKIM setup.

Why this normally helps DMARC

A CNAME is not a DMARC feature by itself. Its value is that a vendor can sign using a DKIM domain aligned with your visible From domain. If the signature validates and the signing domain aligns, it can satisfy the DKIM side of DMARC even when the vendor's SPF infrastructure is shared with many customers.

That is often preferable to asking every SaaS sender to fit inside one sprawling SPF record. It also keeps key rotation on the vendor side. But it does not remove your responsibility to know who is allowed to sign as your domain. Aggregate DMARC reports still show whether the resulting traffic aligns and which sources are actually sending.

The risk is lifecycle, not the CNAME itself

An active selector says, in effect, “this target may publish the public key that verifies signatures for this sending path.” If the vendor is replaced, a product is retired, or an account changes hands and the CNAME remains, the record can outlive the business decision that justified it.

A stale selector is not automatically an active compromise. A responsible vendor may stop serving a key or return a revoked key after an account closes. The problem is that you are relying on an external lifecycle you may no longer observe. If the target is reassigned, changed, or left operational, you have an unnecessary authentication dependency under your own domain.

Three failure modes to catch early

The orphaned CNAME. The marketing platform was replaced, but its selectors remain because the DNS request was filed years ago. The immediate fix is simple: confirm there is no current traffic using the selector, then delete it. Keep the removal in the vendor offboarding checklist, not just in the DNS administrator's memory.

The wrong signing identity. The vendor signs mail with its own domain, or uses a customer subdomain that does not align with the visible From address. The CNAME can resolve perfectly while DMARC still fails. Inspect a real message header and the aggregate report result; do not treat “DKIM enabled” in a vendor dashboard as proof of alignment.

The unnoticed target change. The selector still exists, but its CNAME target no longer belongs to the expected provider namespace. It may be a migration, a vendor acquisition, or simply an error. Record the expected target and alert on changes so the team investigates instead of discovering it during an incident review.

A safe setup and offboarding pattern

1. Use a vendor-specific selector. sendgrid1 or crm-2026 makes ownership clearer than a generic default selector.
2. Store the vendor, product, business owner, ticket, approved From domains, and CNAME target in your sender inventory.
3. Test one real message. Check the d= and s= values, key lookup, and DMARC alignment rather than relying only on a setup wizard.
4. Monitor aggregate reports and the DNS target. A new unaligned source or an unexpected target change deserves a human decision.
5. On offboarding, stop the sender, confirm no recent traffic uses the selector, then remove the CNAME. If queued mail is a concern, agree a short overlap window and schedule deletion.

How to audit the estate now

List all names below _domainkey, then classify each TXT and CNAME record. For every CNAME, follow the target and assign it to a current sender or mark it for retirement. Do not assume the selector name tells the truth: vendors rename products, and migrations leave historical records behind.

Pair that DNS inventory with current DMARC data. A selector that resolves but has no recent legitimate traffic is a candidate for removal; a source that appears in reports without a documented selector is a candidate for investigation. The aim is not zero CNAME records. It is a small, explainable set of delegated authentication paths.

The standard itself is worth keeping nearby: RFC 6376 defines selector-based DKIM key retrieval and the role of delegated signers. For operational teams, the simple rule is enough: delegation is acceptable when you can name the owner, validate the traffic, and remove the record when the relationship ends.

Disclosure: AI tools were used in the process of creating this blog post.