DKIM adds a cryptographic signature to a message and publishes the matching public key under a selector such as selector._domainkey.example.com. A DNS check can confirm whether the public key resolves and inspect its type, but a complete validation also needs a message header to show which selector and signing domain the sending service actually used.
Many domains publish an old DKIM key that no active sender uses, or configure one provider while another stream remains unsigned. That makes a simple “record found” result misleading. The sending service has to sign, the selector has to resolve, the signature has to verify, and the signing domain has to align with the visible From domain for DMARC to use it.
What the record changes
The fix sequence begins in the sending platform, which normally supplies a CNAME or TXT record and activates signing after DNS is visible. Keep each provider's selector distinct. Inspect a delivered message's Authentication-Results and DKIM-Signature headers after propagation. Do not invent a public key or copy one between providers, because the private key remains with the system that signs.
- RFC 6376 defines DKIM signatures, selectors, signing domains, and the DNS key lookup used by receivers.
- Google's sender guidelines require email authentication and use DKIM as one of the supported authentication methods.
- DMARC alignment compares the DKIM d= signing domain with the visible From domain, so a valid signature from an unrelated domain may not satisfy DMARC.
How to use this answer
An authentication check reads the domain's published SPF, DKIM, DMARC, MX, TLS reporting, MTA-STS, and related records, then validates syntax and relationships. The fix block contains proposed records for the customer's actual provider and order of operations. A domain can pass these checks and still reach spam, because reputation, volume, content, consent, and list quality live outside DNS.
- Check the visible From domain, sending service, return path, and DKIM signing domain before changing any record.
- Read the existing DNS, count SPF evaluation terms, find DKIM selectors, and evaluate DMARC alignment and reporting addresses.
- Apply one reviewed change at a time, wait for DNS propagation, and validate the published result before tightening policy.
Where the service stops
Reality Contact, LLC reads public DNS and public blocklist responses. We never log into your DNS, mail server, or sending platform, and we never send from your domain. You paste the proposed records. The scope is authentication-ready, not inboxing. List quality, content, volume, and sender reputation are outside what DNS can show. This is not legal advice, and mail-law compliance remains yours.
Sources: RFC 6376: DomainKeys Identified Mail; Google email sender guidelines; DMARC overview.