DKIM cannot be discovered by checking the root domain
The public key lives at <selector>._domainkey.<domain>. Standard DNS does not provide a directory of every selector in use. That means generic domain scans can try common selectors, but only a real DKIM-Signature tells you which selector a specific production message used.
CNAME delegation is normal
Many email platforms ask customers to publish a CNAME for the selector rather than a TXT key directly. This delegates key management to the sending platform and can simplify rotation. A selector checker should therefore follow both direct TXT records and CNAME delegation before reporting the key as missing.
Rotation needs overlap
A safe rotation keeps the old public key available long enough for messages signed before the switch to complete delivery and verification. Removing a selector immediately after changing the signing configuration can cause delayed messages to fail verification. Treat selector cleanup as a staged change rather than an instantaneous swap.
Verify strength and revocation state
An empty p= value represents a revoked DKIM key. A non-empty key should also be reviewed for modern key strength and provider compatibility. Use the selector from a current message, verify the published record and then inspect a newly delivered message after rotation to confirm the sender is actually using the new selector.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.