DKIM records are not usually published at the bare domain. They live under selector-based names such as selector._domainkey.example.com, so a useful DKIM check starts by finding the selector used by the sender.
Run a domain scan, then use a real signed message or provider settings to confirm the DKIM selector.
Check the public sender-auth records mailbox providers expect.
Keep one URL with evidence, owner steps, and decisions.
Add human review, provider context, and verification steps.
Review DMARC policy strength before a high-volume send.
Overall sender readiness
Needs attention
Sample output: one warning and one fail mean this domain is not campaign-ready yet.
The scan becomes a focused work surface: evidence, owner action, verification, and the paid context a public lookup cannot infer.
Open the full headers of a message sent by the platform you want to check. Look for a DKIM-Signature header. RFC 6376 describes selector information as the s= tag and the signing domain as the d= tag.
If the header contains s=google and d=example.com, the matching public key is usually queried at google._domainkey.example.com. Your selector and signing domain may be different.
Do not infer a selector from another company or another tenant. DKIM values are provider-specific and often domain-specific.
Once you have the selector and signing domain, query the selector hostname. DKIM keys are commonly published as TXT records, while some hosted platforms ask you to publish CNAME records that point to provider-managed keys.
A DNS record at the selector host is only one part of the review. To confirm the message passed DKIM, inspect authentication results or verify the signed message with the public key.
DMARC cares whether authenticated SPF or DKIM aligns with the visible From domain. A message can have a DKIM signature but still miss DMARC alignment if the d=domain does not align with the From domain under the domain owner's DMARC policy.
A selector is the value in the s= tag of a DKIM-Signature header. It tells receivers which selector-specific DNS name to query for the public key.
Yes. Different platforms, key rotations, or mail streams can use different selectors. Check the actual signed message or the sending platform settings instead of assuming one default selector.
No. The selector helps locate the public key. A full DKIM check also verifies the signature, signed headers, body hash, key record, and whether the signing domain aligns for DMARC.
SenderReady readiness audits summarize public DNS findings and related authentication checks. They can support a DKIM review, but they do not replace a platform admin, provider support, or full message-header analysis.