Copy values from the actual account
Provider selectors and targets can vary by tenant, region, or domain. Record the exact selector, owner name, target, account, and instruction date. An illustrative instruction might be:
s1._domainkey.example.com. CNAME s1.example.customer.provider.example.
Both names are reserved examples. Do not infer the target from another customer or generic blog post.
Understand the DNS control panel
Some panels expect only s1._domainkey in the host field and append the zone. Others accept a fully qualified name. A panel may also append the zone to a target that lacks a trailing dot. Preview or query the published result instead of trusting the form label.
Do not publish both CNAME and TXT data at the same owner name; DNS aliases must not coexist with other data at that name under normal DNS rules. Preserve unrelated selectors, because s1._domainkey and s2._domainkey are independent owner names.
Follow the answer chain
Query the exact selector name at an authoritative server, then through a relevant recursive resolver. Confirm that the CNAME points to the intended target and that following it returns the provider-managed DKIM key. Distinguish a missing target, resolver timeout, and invalid key syntax. Record TTLs at each step because caches can retain different parts of the chain.
A provider console showing “verified” is useful but not sufficient. It may have checked DNS before the production sender began using that selector.
Verify message use
Enable signing according to the provider’s documented workflow and send a fresh message through the real application path. In the original received message, confirm the DKIM-Signature uses the expected s= and d= values. Then inspect the trusted receiver’s result for that signature.
If the message uses another selector, fix the sender configuration rather than adding aliases at random. If the selector is correct but verification fails, separate key retrieval from body/header signature diagnostics.
Record ownership
Document who controls the alias, who controls the target key, rotation behavior, rollback, and provider offboarding. The CNAME approach delegates key publication, not organizational accountability. A successful deployment has a correct DNS chain and a verified message from the intended account.