DKIM is one of the main checks that helps receiving email systems decide whether a message is legitimate. It works by adding a digital signature to an email. The sending service signs the message with a private key, and the receiving server checks a matching public key published in your DNS records. You do not need to understand cryptography to check whether DKIM is working. You need to know which service sent the email, which DKIM selector it uses, and whether the matching DNS record is published correctly.
What DKIM protects
DKIM stands for DomainKeys Identified Mail. When a message is sent through a properly configured provider, that provider adds a DKIM signature. The signature helps the receiving server verify two things:
- The message was sent through a service authorized to sign for the domain.
- Important parts of the message were not changed after it was signed.
DKIM is useful because email can pass through multiple systems before reaching the recipient. It gives mailbox providers another trust signal beyond the sending server's IP address. DKIM works alongside SPF and DMARC. It does not replace them.
Start with the sending service
Before checking DNS, identify the platform that sent the message. A business may use several email services:
- Google Workspace or Microsoft 365 for employee email
- A newsletter platform for campaigns
- A support desk for customer replies
- A transactional-email provider for receipts and password resets
- A CRM for automated sequences
Each service may use its own DKIM selector and public key. A common mistake is checking one DKIM record, seeing that it exists, and assuming every message from the business is signed correctly. A working Google Workspace setup does not automatically mean a marketing platform or ecommerce system is correctly configured. Make a list of every platform that sends email using your domain.
Understand the DKIM selector
A DKIM record is usually not stored directly at your main domain. Instead, it is published at a selector-specific address that looks like this:
selector._domainkey.yourdomain.comThe selector is a label chosen by the sending provider. It helps the receiving server find the correct public key. For example, a provider might instruct you to add a record at:
google._domainkey.example.comor:
s1._domainkey.example.comThe exact selector is not something you should guess. Use the provider's current setup instructions or inspect a real sent message.
How to find a DKIM selector in an email header
Send a test message from the platform you want to check to an inbox you control. Open the full message headers. Different mailbox providers use different labels, but you are looking for a DKIM signature that includes fields like:
d=example.com;
s=selector-name;The d= value is the signing domain. The s= value is the selector. If the header says:
d=example.com;
s=s1;the receiving server looks for a public key at:
s1._domainkey.example.comThis gives you the exact hostname to check.
Run a selector-based lookup
After reading s= and d= from the DKIM-Signature header, replace the placeholders and run:
dig +short TXT selector._domainkey.yourdomain.comFor s=s1 and d=example.com, use dig +short TXT s1._domainkey.example.com. On Windows:
nslookup -type=TXT s1._domainkey.example.comSome providers delegate this hostname with a CNAME. Inspect that alias and its target when troubleshooting a missing key. The receiver’s Authentication-Results header may also show header.s and header.d, but the DKIM-Signature is the direct source for the selector and signing domain.
Check the public DNS record
Once you know the selector, look up the corresponding DNS TXT record. A valid DKIM record normally contains a version and a public key. It may look broadly like this:
v=DKIM1; k=rsa; p=MIIBIjANBg...The long p= value is the public key. It is normal for it to look unreadable. What matters is that:
- The record exists at the correct selector hostname.
- The value matches the provider's instructions.
- The key was not accidentally shortened or split incorrectly.
- The record belongs to the provider that is actually sending the message.
A free domain check can help identify public records, but a real message header remains important because it shows which selector the sending service actually used.
Common DKIM setup problems
The selector is wrong
The provider may tell you to create a record at one hostname, but the DNS provider's interface can make it easy to add the domain twice or omit part of the selector. For example, if your DNS provider automatically adds your domain name, entering the full hostname can accidentally create:
s1._domainkey.example.com.example.comAlways check the final hostname that was published.
The public key is incomplete
DKIM keys can be long. A copied key may be truncated, contain extra quotation marks, or be split into multiple fields incorrectly. Use the exact record supplied by the provider. Do not edit the key manually unless the provider's instructions explicitly require a particular DNS format.
The provider was never authenticated
Many newsletter, support, and transactional-email platforms initially send using their own domain until you complete domain authentication. A message may still arrive, but it may not have DKIM aligned with your business domain. That can weaken DMARC results and inbox placement.
A key was rotated
Providers sometimes rotate DKIM keys for security or infrastructure changes. If the new DNS record is not published, signatures can fail. Do not remove an old selector immediately. Some providers use multiple selectors during a transition.
A different service sent the message
A business may believe a message came from its primary email provider, when it actually came from a CRM, website plugin, or billing tool. The header identifies the real sender. Check that source before changing DNS.
Check whether DKIM actually passes
A published DKIM record is not enough by itself. Send a fresh test message and inspect the authentication results. Look for something similar to:
dkim=passA pass means the recipient successfully validated the signature using the public key. If you see dkim=fail, check:
- Which domain appears in
d=. - Which selector appears in
s=. - Whether the matching DNS record exists.
- Whether the record matches the provider's current instructions.
- Whether the message was sent through the expected platform.
If DKIM is missing entirely, check whether that platform supports custom-domain DKIM and whether its domain-authentication setup was completed. Read DKIM failure causes and diagnosis for a more focused troubleshooting guide.
DKIM alignment matters for DMARC
A DKIM signature can pass but still not fully help your DMARC result. DMARC checks whether the signing domain aligns with the visible From domain. For example, a newsletter tool might sign mail with its own domain. The signature may be valid, but if your visible From address is you@yourbusiness.com, that vendor domain may not align with your business domain. Many providers offer custom-domain DKIM setup specifically to solve this problem. Read DKIM alignment explained before assuming that a DKIM pass means every authentication issue is resolved.
A safe process for making DKIM changes
Use this order:
- Identify the sending platform.
- Send a test message.
- Find the
d=ands=values in its header. - Check the matching DNS record.
- Compare it with the provider's current instructions.
- Save the old DNS value before changing anything.
- Make one change at a time.
- Wait for DNS propagation.
- Send a new test message.
- Confirm DKIM passes and aligns appropriately.
This approach prevents one of the most common mistakes: deleting or replacing a key before knowing which service still relies on it.
Frequently asked questions
Can I have more than one DKIM selector? Yes. Different services can use different selectors, and one provider may temporarily use more than one during key rotation. Is the DKIM public key secret? No. The public key belongs in DNS. The private signing key stays with the sending provider and should never be shared. Why does my DKIM record exist but DKIM still fail? The selector may be wrong, the key may not match the provider's current key, the message may be coming from a different service, or the provider may not be signing the message as expected. Should I delete old DKIM records? Only after confirming that no active provider uses them. Old records can be harmless, but deleting an active one can break authentication immediately.
The practical next step
Run a free check to review the public records for your domain, then send a real test message from every platform that sends email on your behalf. A correct DKIM setup is not a one-time job. Provider migrations, key rotations, and DNS changes can break a record later. Monitoring the important selectors can help you catch that change before customers start seeing delivery problems. Run a free Beacon domain check →