A DKIM setup is complete when the service signs the intended mail and a receiver can validate it. A green DNS status alone does not establish either outcome. Choose TXT or CNAME from the provider's supported key-management model, rather than treating them as interchangeable ways to paste a key.
Identify who manages the key
A directly published TXT record carries the DKIM verification data. With a CNAME arrangement, the selector name aliases another DNS name where the verification data is managed. The private signing key belongs on the signing system, never in either public record. RFC 6376 §3.6 and RFC 6376 §6.1.2 describe key discovery and retrieval; DNS alias behaviour is defined in RFC 1034 §3.6.2.
Microsoft 365’s custom-domain procedure uses CNAME records and tenant-generated destinations. Its current documentation is an example of why copying an older target pattern is unsafe. Obtain the values displayed for the actual tenant and selected domain. This example does not imply that an unrelated service accepts the same records.
Before editing DNS, record the sending account, visible From domain, intended signing domain, selector names, record type, exact generated values and responsible owner. Ask which system performs rotation and who removes the delegation when the contract ends. If the provider cannot use the required signing domain, changing the DNS record type will not create that capability.
Publish at the correct owner name
An illustrative signature with d=example.com and s=billing leads to billing._domainkey.example.com. The example identifies a DNS owner name, not a working public key or production CNAME target.
Check whether the DNS interface expects that full name or only billing._domainkey. Some interfaces append the zone name. Read back the resulting owner name instead of assuming the entry box preserved it. Inspect existing data before changing the name. A conventional CNAME cannot coexist there with a separate TXT key record; preserve unrelated selectors and follow the provider's supported migration procedure.
For TXT, publish the exact public value in the supported representation. For CNAME, use the generated destination, not a copied key discovered at the destination today. Copying the current key locally can break the provider's later rotation model. Keep screenshots or exported records in the change record, excluding credentials and private keys.
Verify resolution and actual sending separately
Query the exact owner name against authoritative DNS, then check recursive resolution through the path recipients will use. For CNAME, follow the alias to the final TXT result and record any timeout or missing target. Allow for cached old data, including negative answers, when interpreting disagreement. Publication and global cache convergence are different observations.
Next send a controlled message through the real application. Preserve its raw headers and the trusted receiving system's authentication result. Record d=, s= and DKIM verification. Check alignment with the visible From domain separately. A valid signature from a provider-owned domain can be unrelated to the customer identity you intended to authenticate.
If DNS resolves but mail is unsigned, investigate service activation and routing. If the signature names a different selector, inspect that selector rather than repeatedly editing the unused record. If verification fails after content modification, changing TXT to CNAME is not the repair.
Keep the dependency accountable
Close the change only when the record, signer and received evidence agree. Store the previous configuration and an authorised recovery plan before cutover. At offboarding, stop the sending integration and retire its verification dependency deliberately, accounting for legitimate mail still in transit. Do not leave an unexplained provider alias indefinitely or delete an active selector merely because a contract spreadsheet says the service ended.
Related reading
DKIM DNS delegation: assess the scope of control granted to a provider · DKIM public-key syntax: identify truncated or malformed DNS values.
Apply the distinction
Use a three-part acceptance record: published owner/type/value and observation time; actual received d/s and trusted verification; alignment with the intended Author Domain. If DNS is correct but mail is unsigned, investigate activation or route selection instead of changing record type. If a different selector is emitted, follow that evidence. The checklist is proposed review work, not a performed DNS or mail test.