A CNAME makes one DNS name an alias of another. It is often used for provider-managed email setup, but it does not transfer an entire subdomain in the way an NS delegation does. Before creating an alias, identify what already occupies that exact name and who controls the target.
Keep the alias owner exclusive
References: RFC 2181 §10.1, RFC 1034 §4.2.1.
At a CNAME owner, ordinary TXT, MX, A and other data cannot coexist with the alias. DNSSEC metadata is a special case; it does not make a TXT-plus-CNAME configuration valid. There is one canonical target for an alias. A zone apex already needs SOA and NS records, so a conventional apex CNAME conflicts with the zone structure.
Provider features called flattening or ALIAS may synthesize ordinary address answers instead of publishing a CNAME. Their behavior is implementation-specific. Do not assume that such a feature can synthesize arbitrary authentication TXT data or act as a standards-based delegation. Inspect the answer for the actual record type required by the consuming protocol.
Follow the dependency to its end
References: RFC 1034 §3.6.2, RFC 6376 §3.6.2.1.
For a provider-supported DKIM alias, a TXT lookup at a selector can follow the alias to the provider's key. Retain the alias owner, each target and the terminal TXT result. A CNAME pointing to another CNAME adds another dependency; loops or an absent target prevent a useful terminal answer.
This arrangement gives the target operator influence over the data resolved through the alias. That is not permission to edit the rest of your zone, but it is consequential for the configured service. Verify the generated target in the authenticated provider setup flow, keep service ownership recorded and remove obsolete dependencies through a planned retirement.
Exercise a synthetic selector lookup
Fixture A publishes s1._domainkey.example.com. 300 IN CNAME s1.keys.example.net. and a terminal TXT value at s1.keys.example.net.. For this DNS-only test use "fixture=terminal-data", which intentionally is not a valid DKIM key. Expected TXT resolution follows the alias and returns that marker. This proves the lookup dependency only, not cryptographic authentication.
Fixture B adds a TXT record at s1._domainkey.example.com. while keeping its CNAME. Expected configuration validation is a coexistence conflict; do not publish it to test receiver tolerance. Fixture C changes the target to an unconfigured name. Expected result is no usable terminal data, with the precise response depending on whether that name exists without TXT or does not exist at all.
In an isolated test environment, query the owner for CNAME and TXT and query the target for TXT. Record the response codes, authority and alias chain. For a real DKIM test, replace the marker with the provider's real generated configuration and verify a signed message separately.
Avoid aliases in routing targets
References: RFC 2181 §10.3, RFC 5321 §5.1, RFC 8767 §4.
An MX target and an NS target must name a host with address records, not an alias. A domain being looked up for mail can itself involve a CNAME under SMTP resolution rules, but that does not permit a CNAME as the exchange hostname stored in MX data. Keep those two positions distinct when reading a trace.
Before retiring an external service, check whether another active service still uses the selector or target. Removing an alias can remain invisible to cached readers for a time, and restoring it is not an instant rollback. Close the change after verifying both DNS and the intended service behavior.
Keep the evidence scope explicit
The terminal fixture marker demonstrates only a planned DNS dependency, not a usable DKIM key. Do not publish the deliberately conflicting owner to test tolerance. No CNAME deployment, resolution or cryptographic verification was performed in this review.