A DKIM record is a public DNS record that lets receiving email systems verify a cryptographic signature placed on a message by your mail provider. The record can look intimidating because it contains a long public key, but a useful check is less about reading every character and more about confirming the selector, host name, record type, and relationship to the service that sends your mail.
The two parts of DKIM
Your sending platform holds a private key and adds a DKIM signature to outgoing messages. DNS holds the matching public key. A receiving server uses the domain and selector named in the signature to find that public key and verify that the signed parts of the message have not changed. The private key never belongs in DNS.
How the record name is built
A DKIM record normally lives at selector._domainkey.example.com. The selector is chosen by the sending platform; common examples include google, selector1, or a provider-specific string. Do not assume a selector from one provider applies to another. Open a recent message header and look for the d= domain and s= selector in the DKIM-Signature line, then combine them into the DNS host name.
What a typical record contains
The value commonly begins with v=DKIM1 and includes k=rsa plus p= followed by a long public key. DNS dashboards may display the value as several quoted fragments; that is usually normal because DNS TXT values have length limits. The important question is whether the public lookup resolves to the same key the sending provider expects, not whether the dashboard wraps the line differently.
Check the real sending path
- Send a fresh message from the specific platform you want to verify.
- Open the full message headers in the receiving mailbox.
- Find the DKIM result and signature domain.
- Look up the selector record in DNS.
- Confirm the result says
dkim=passfor the current message.
A published record alone does not prove DKIM works. A provider may not have enabled signing yet, the selector may be wrong, or the platform may sign with a different domain than the one you expected.
DKIM and DMARC alignment
For DMARC, a passing DKIM signature normally needs to align with the visible From domain. A platform can sign with its own unrelated domain and still show a DKIM pass, while DMARC fails alignment. Review how email authentication works and how to check DMARC before treating a pass as the entire answer.
Common mistakes
Publishing the record at the root domain instead of the selector host, copying the private key, using an old selector after a provider migration, and editing quotation marks manually are common failures. Keep a record of the provider, selector, owner, and activation date. If a vendor rotates keys, follow its instructions rather than keeping a stale record forever.
What to do after a failure
Compare the current provider documentation, DNS host, and live header. Make one change at a time, allow DNS caches to expire, and send a new test. Do not remove a working record merely because another provider also needs DKIM; multiple selectors can coexist. Run Beacon’s free domain check to review the public SPF, DKIM, and DMARC signals for your domain.
Keep the evidence
Save the passing test header with your DNS-change record. It gives the next administrator a concrete reference if delivery changes after a vendor update.
For the policy relationship, review the DMARC implementation checklist.