DomainKeys Identified Mail, or DKIM, lets a sending system attach a cryptographic signature to a message. A receiving system retrieves the public key published in DNS and uses it to check whether selected signed headers and the message body still match the signature.
A DKIM pass does not prove that every statement in a message is trustworthy, and it does not replace SPF or DMARC. It provides evidence that the signed content survived transit and that the signer controlled the private key associated with the published selector record.
How the selector and DNS record fit together
The DKIM-Signature header identifies a signing domain in the d= tag and a selector in the s= tag. The receiver combines them to query a TXT record at selector._domainkey.example.com. That record normally identifies the key type and contains the public key used for verification.
Selectors allow a domain to rotate keys or operate more than one approved sending platform without publishing one shared key. Each platform should provide the exact selector name and record value its signer expects.
- Publish the selector at the precise hostname supplied by the sender.
- Keep the private key in the sending system; only the public key belongs in DNS.
- Use separate selectors when platforms or key-rotation schedules differ.
A practical verification sequence
First confirm which service sends mail for the domain and obtain its current selector. Query the selector record, confirm that one usable DKIM key is returned, and send a controlled message to a mailbox where the full authentication results can be inspected.
Check that the message contains a DKIM-Signature header, that the receiving system reports dkim=pass, and that the d= domain aligns with the visible From domain when DMARC relies on DKIM alignment.
- Verify the selector rather than guessing common names such as default or google.
- Allow for DNS caching after a record is added or replaced.
- Test each service that sends as the domain, including marketing and transaction platforms.
Why DKIM checks fail
A missing selector, a record published at the wrong DNS name, a truncated public key, or a signer using an old private key can prevent verification. Message modification after signing can also break the body or header hash.
When a record exists but mail still fails, compare the selector and signing domain in the actual message header with the DNS name being checked. That evidence is more reliable than assuming the administrative interface and production signer are using the same configuration.
Check the public evidence
The Envelaro DKIM checker retrieves the public selector record you specify and explains common record-level problems. It cannot see a provider's private key or prove that every outgoing message is being signed, so complete verification still requires a real message-header test.
Primary sources
Provider interfaces and requirements change. Check the linked source before applying a production change.