DKIM Record Checker: Fix Missing DKIM and Wrong Selectors

Quick answer: what should a DKIM checker look for?

A useful DKIM checker should check the selector-specific DNS record, not only the root domain.

The most important DKIM rule: you cannot reliably check DKIM without knowing the selector.

What is DKIM?

DKIM stands for DomainKeys Identified Mail.

It is an email authentication method that allows an email provider or sending platform to sign outgoing email with a private key. Receiving mail servers can then use a public key published in DNS to verify that signature.

In simple terms, DKIM says that the message was signed by a system authorized to send for that signing domain and that the message has not changed in a way that breaks the signature.

DKIM does not receive email, replace MX records, or guarantee inbox placement. It is one of the core signals used for email trust and DMARC alignment.

For the surrounding authentication records, use the SPF record checker and DMARC record checker alongside this DKIM guide.

DKIM explained simply

DKIM works with two keys:

The basic flow is straightforward:

1. Your email provider sends an outgoing email.
2. The provider signs the email with a private DKIM key.
3. The email includes a DKIM-Signature header.
4. The receiving server reads the DKIM selector and signing domain from that header.
5. The receiving server looks up the matching public key in DNS.
6. If the signature verifies, DKIM passes.

What does a DKIM record look like?

A DKIM record is usually published under a selector.

google._domainkey.example.com

Another common selector-based name is:

selector1._domainkey.example.com

The record may be TXT or CNAME depending on the provider.

TXT-style DKIM record

Some providers publish the DKIM public key directly as a TXT record.

v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE_HERE

Do not copy that as a real record. The p= value must come from your email provider.

CNAME-style DKIM record

Some providers ask you to publish a CNAME that points to provider-managed DKIM infrastructure.

selector1._domainkey.example.com CNAME provider-provided-target.example

Do not copy that as a real record either. The target must come from your provider.

DKIM selectors explained

A DKIM selector is a label that tells receiving mail servers where to find the DKIM public key.

In this DNS name:

google._domainkey.example.com

the selector is:

google

In this DNS name:

selector1._domainkey.example.com

the selector is:

selector1

Selectors matter because one domain can use multiple DKIM keys at the same time.

• Google Workspace
• Microsoft 365
• Mailchimp
• SendGrid
• HubSpot
• Klaviyo
• Helpdesk systems
• Transactional email platforms
• Key rotation
• Separate sending subdomains

That is why a DKIM checker should ask which selector to check, not just whether example.com has DKIM.

Where is DKIM published in DNS?

DKIM records are usually published under this pattern:

selector._domainkey.example.com

For the domain example.com and selector google, the DKIM record name is:

google._domainkey.example.com

In many DNS providers, including Cloudflare, you may only enter the host or name part:

google._domainkey

The DNS provider then appends the root domain automatically.

Common DKIM selectors

Different platforms use different selectors, and many provider values are unique to the account or domain.

Do not assume the selector. Use the exact selector shown by your email provider or sending platform.

DKIM is not checked at the root domain

This is a common misunderstanding.

SPF is usually checked at the root domain:

example.com

DMARC is checked at:

_dmarc.example.com

DKIM is checked at a selector:

selector._domainkey.example.com

If you check only example.com, you will not find DKIM. You need the selector.

How to find the DKIM selector

There are two practical ways to find a DKIM selector.

Method 1: Get it from your email provider

This is the best method. Look in the admin area of the provider that sends the email.

The provider should show the exact selector and DNS value.

Method 2: Inspect a sent email header

Send an email from the domain to an external inbox, then view the message headers.

Look for a header that starts with:

DKIM-Signature:

Inside that header, look for s= and d=.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...

In that example, the DKIM DNS lookup would be google._domainkey.example.com.

DKIM-Signature header explained

A DKIM-signed email includes a header that may look like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; h=from:to:subject:date; bh=...; b=...

For most troubleshooting, the most important tags are d= and s=. They tell you which domain and selector the receiving server uses for the DKIM check.

DKIM TXT record parts explained

A DKIM TXT record may look like this:

v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE_HERE

The p= value is the public key. It is usually long.

Common public key mistake

Long DKIM keys can be accidentally truncated, split incorrectly, pasted with extra spaces, wrapped incorrectly by a DNS interface, copied from the wrong domain, or copied from the wrong selector.

If the public key is broken, DKIM verification can fail even though a DNS record exists.

DKIM CNAME record explained

A DKIM CNAME record points your selector to a provider-managed DKIM record.

selector1._domainkey.example.com CNAME provider-provided-target.example

The benefit is that the provider can manage the public key behind the target. This is common for Microsoft 365 and many third-party sending platforms.

Important CNAME rule: use the exact CNAME target from the provider. Do not invent it or modify it unless your DNS provider specifically requires a formatting change.

TXT DKIM vs CNAME DKIM

Different providers use different DKIM record types.

Neither style is automatically better for every case. Follow the provider's setup instructions.

The biggest mistake is using the wrong record type. Microsoft 365 custom-domain DKIM uses CNAME selectors. If you create TXT records instead, Microsoft DKIM verification will not work correctly.

DKIM vs SPF vs DMARC

DKIM is one part of email authentication.

SPF asks whether the sending server is allowed. DKIM asks whether the message was signed by an authorized domain key. DMARC asks whether SPF or DKIM aligns with the visible From domain and what should happen if authentication fails.

For a complete setup, use this guide with the SPF record checker and DMARC record checker.

Why DKIM matters for DMARC

DMARC can pass if SPF or DKIM passes with alignment.

DKIM alignment means the DKIM signing domain matches or aligns with the visible From domain.

Visible From: hello@example.com
DKIM signing domain: example.com

That is aligned.

Visible From: hello@example.com
DKIM signing domain: thirdpartyservice.com

That may not align. The message may have a valid DKIM signature, but it may not help your domain pass DMARC because the signing domain is not aligned with the visible From domain.

This is why third-party platforms often ask you to authenticate your sending domain.

Missing DKIM: what it means

If a DKIM checker says DKIM is missing, it may mean one of several things.

The key point: DKIM missing is not always final proof that the domain has no DKIM. It may simply mean the wrong selector was checked.

Wrong DKIM selector: why it causes confusion

Suppose Google Workspace is signing with:

s=google

The DKIM record should be checked at:

google._domainkey.example.com

If you check selector1._domainkey.example.com, you may get missing DKIM even though Google DKIM exists.

The reverse is also true. If Microsoft 365 signs with s=selector1, checking google._domainkey.example.com does not tell you whether Microsoft DKIM is configured.

DKIM for Google Workspace

Google Workspace commonly uses a TXT record under a selector such as:

google._domainkey

The full DNS name would be:

google._domainkey.example.com

Use Google's generated value from Google Admin. Do not create your own DKIM key from a template or copy a value from another domain.

For the broader Cloudflare setup, see the Google Workspace Cloudflare DNS checklist.

Google Workspace DKIM setup flow

1. Open Google Admin.
2. Go to Gmail authentication or DKIM settings.
3. Select the domain.
4. Generate a DKIM key.
5. Copy the DNS record name and TXT value from Google.
6. Add the TXT record at the active DNS host.
7. Wait for DNS to publish.
8. Return to Google Admin.
9. Start authentication.
10. Send a test email to an external inbox.
11. Check whether DKIM passes.

Example Cloudflare record for Google DKIM

The content often starts with v=DKIM1; k=rsa; p=, but the full value must come from Google Admin.

Common Google Workspace DKIM mistakes

DKIM for Microsoft 365

Microsoft 365 custom-domain DKIM usually uses two CNAME records:

selector1._domainkey
selector2._domainkey

The CNAME targets are generated by Microsoft and are specific to your tenant and domain. Copy them from Microsoft 365 or Microsoft Defender instructions. Do not hardcode or guess tenant-specific DKIM targets.

For the broader Cloudflare setup, see the Microsoft 365 Cloudflare DNS checklist.

Microsoft 365 DKIM setup flow

1. Add and verify the domain in Microsoft 365.
2. Open Microsoft Defender or email authentication settings.
3. Find DKIM settings for the custom domain.
4. Copy the selector 1 CNAME record.
5. Copy the selector 2 CNAME record.
6. Add both CNAME records at your active DNS host.
7. Keep the CNAMEs DNS-only if using Cloudflare.
8. Wait for DNS to publish.
9. Return to Microsoft.
10. Enable DKIM signing for the custom domain.
11. Send a test email.
12. Check whether DKIM passes.

Example Cloudflare records for Microsoft 365 DKIM

Common Microsoft 365 DKIM mistakes

DKIM for third-party sending platforms

Many businesses send email from more than one system.

• Google Workspace or Microsoft 365
• Email marketing tools
• CRM platforms
• Helpdesk systems
• Ecommerce platforms
• Website contact forms
• Transactional email providers
• Booking systems
• Invoicing tools
• Cold email tools

Each platform may need its own DKIM records.

A DKIM record for Google Workspace does not automatically authenticate Mailchimp. A DKIM record for Microsoft 365 does not automatically authenticate SendGrid. Each sender must be checked separately.

Examples: multiple senders

Google Workspace plus email marketing platform

If your business sends normal email through Google Workspace and newsletters through an email marketing platform, you may need:

If Google DKIM passes but newsletter emails fail DKIM, the marketing platform's domain authentication may be missing.

Microsoft 365 plus CRM

If your team uses Microsoft 365 for normal email and a CRM for sales emails, you may need:

If Microsoft 365 emails pass DKIM but CRM emails fail DMARC, the CRM may not be signing with your domain.

DKIM and website contact forms

Website contact forms can be tricky. A form may appear to send from hello@example.com, but the actual sending system may be your web host, WordPress mail function, SMTP plugin, SendGrid, Mailgun, Amazon SES, Postmark, Brevo, or another transactional email provider.

If the form sends email using your domain, the sending service should be authenticated with SPF, DKIM, or both.

For reliable delivery, use a proper SMTP or transactional email provider and complete that provider's domain authentication steps.

DKIM and subdomains

DKIM can be set up for a root domain or a subdomain.

google._domainkey.example.com
selector1._domainkey.mail.example.com
k1._domainkey.news.example.com

If a marketing platform sends from news.example.com, the DKIM record may belong under that subdomain.

Do not assume all DKIM records belong under the root domain. Follow the exact host or name given by the sending platform.

DKIM and Cloudflare

If your DNS is managed in Cloudflare, DKIM records must be added in Cloudflare. This is true even if the domain was bought elsewhere, the website is hosted elsewhere, or the email provider is Google Workspace or Microsoft 365.

The active nameservers decide where live DNS is managed.

MX and TXT records are DNS-only in Cloudflare. DKIM CNAME records for Microsoft 365 or third-party verification should also be DNS-only.

If a DKIM CNAME is orange-clouded or proxied, change it to DNS-only unless your provider explicitly says otherwise.

DKIM and DNS propagation

After adding or changing a DKIM record, DNS may not update everywhere immediately.

• Provider says DKIM record not found.
• Checker still shows an old result.
• DKIM still fails on a test email.
• Microsoft or Google cannot enable authentication yet.

Confirm the record was added at the active DNS host, confirm the host field is correct, confirm the value is complete, wait for DNS propagation, recheck the selector, and then return to the provider to enable or verify DKIM.

Do not keep changing the record repeatedly every few minutes. That makes troubleshooting harder.

DKIM pass vs DKIM record exists

A DKIM record can exist in DNS while DKIM still fails. These are different checks.

A checker can tell you whether a DKIM DNS record exists for a selector. To confirm actual DKIM signing, send a test email and inspect the authentication results.

How to test whether DKIM is passing

Use this practical process:

1. Send an email from your domain to an external mailbox.
2. Open the message in the external mailbox.
3. View the original message or message headers.
4. Look for authentication results.
5. Check for dkim=pass.
6. Check the signing domain.
7. Check whether DMARC passes.

You may see something like:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com;
       spf=pass;
       dmarc=pass

That means DKIM passed for that message. If you see dkim=none, the message was not signed with DKIM. If you see dkim=fail, the message was signed but verification failed.

Common DKIM failures and what they mean

DKIM passes but DMARC fails

This can happen.

Visible From: hello@example.com
DKIM signing domain: emailservice.com
DKIM result: pass
DMARC result: fail

DKIM passed for emailservice.com, but the visible From domain is example.com. For DMARC, the DKIM signing domain usually needs to align with the visible From domain.

The fix is to authenticate your domain inside the sending platform so the platform signs with your domain or an aligned subdomain.

DKIM fails after forwarding or message changes

Forwarding can sometimes affect email authentication. DKIM is generally more resilient than SPF during forwarding because DKIM signs message content and headers rather than relying only on the sending IP.

However, DKIM can fail if a forwarding system modifies signed parts of the message.

• Adding a footer
• Rewriting subject lines
• Modifying body content
• Changing signed headers
• Adding disclaimers
• Mailing list modifications

Company-wide footers, disclaimers, and outbound gateways can also break DKIM if they modify the message after it is signed.

The safest setup is usually to make message modifications first, sign after final modification, and then send the final signed message out.

DKIM key rotation and old selectors

DKIM keys may need to be rotated over time. Selectors make rotation easier.

selector1._domainkey.example.com
selector2._domainkey.example.com

Safe key rotation idea

1. Generate a new DKIM key or selector.
2. Publish the new DNS record.
3. Wait for propagation.
4. Start signing with the new selector.
5. Confirm DKIM passes.
6. Keep the old selector briefly.
7. Remove the old selector only after it is no longer needed.

Do not delete old DKIM records immediately if recent emails may still be verified using the old selector.

Should you delete old DKIM records?

Not always. Old DKIM records may be harmless, but they can create confusion during audits.

Before deleting an old DKIM record, confirm the old provider no longer sends email, recent messages are not using that selector, and the domain has fully migrated to the new provider.

Multiple DKIM records: is that okay?

Yes. A domain can have multiple DKIM records if they use different selectors.

google._domainkey.example.com
selector1._domainkey.example.com
k1._domainkey.example.com

This means different systems or selectors are being used. It is not the same as duplicate SPF records.

SPF should usually have one root-domain record. DKIM can have multiple selector records.

Common DKIM mistakes

Safe DKIM setup workflow

Use this workflow:

1. Identify the sending provider.
2. Find the provider's DKIM setup page.
3. Copy the exact selector.
4. Copy the exact DNS record type.
5. Copy the exact DNS value or target.
6. Confirm the active DNS host.
7. Add the record at the active DNS host.
8. Keep DKIM CNAMEs DNS-only in Cloudflare.
9. Wait for DNS propagation.
10. Return to the sending provider.
11. Enable or verify DKIM.
12. Send a test email.
13. Inspect headers for dkim=pass.
14. Check whether DMARC also passes.
15. Repeat for each sender that sends from your domain.

DKIM checklist for Google Workspace

• Domain is verified in Google Workspace.
• Gmail is activated.
• DKIM key is generated in Google Admin.
• DKIM TXT record is added at the active DNS host.
• Selector is correct.
• Public key is copied completely.
• DNS has propagated.
• DKIM authentication is started in Google Admin.
• Test email shows dkim=pass.
• DKIM signing domain aligns with the visible From domain.
• DMARC passes after SPF or DKIM alignment.

DKIM checklist for Microsoft 365

• Domain is verified in Microsoft 365.
• DKIM settings are available for the custom domain.
• Selector 1 CNAME target is copied from Microsoft.
• Selector 2 CNAME target is copied from Microsoft.
• Both CNAME records are added at the active DNS host.
• Both CNAME records are DNS-only in Cloudflare.
• No full-domain duplication happened in the Name field.
• DNS has propagated.
• DKIM signing is enabled in Microsoft 365.
• Test email shows dkim=pass.
• DKIM signing domain aligns with the visible From domain.
• DMARC passes after SPF or DKIM alignment.

DKIM checklist for third-party senders

For each third-party sender, check:

• The platform is still used.
• The platform sends email using your domain.
• Domain authentication is started inside the platform.
• DKIM selector values are copied exactly.
• DNS record type matches the platform's instruction.
• Records are added at the active DNS host.
• CNAME records are DNS-only in Cloudflare.
• The platform shows the domain as verified or authenticated.
• A test email from that platform shows DKIM pass.
• DMARC passes or aligns correctly.
• Old records from unused platforms are reviewed.

Troubleshooting: DKIM checker says record missing

Check these first:

1. Are you using the correct selector?
2. Are you checking the correct domain?
3. Was the record added at the active DNS host?
4. Did you add the record under _domainkey correctly?
5. Did the DNS provider append the domain automatically?
6. Is the record type correct?
7. Has DNS propagated?
8. Did you copy the provider's values exactly?
9. Is the sender using a subdomain?
10. Did the provider generate the DKIM record yet?

Most missing DKIM issues come from the wrong selector, wrong DNS host, or wrong record name.

Troubleshooting: DKIM exists but email shows dkim=none

If DNS has a DKIM record but a test email shows dkim=none, the message was probably not signed.

• DKIM is enabled in the provider admin area.
• You are sending from the provider you configured.
• You are testing the correct domain.
• You are not sending through an old SMTP server.
• You are not using a third-party system that needs its own DKIM.
• The provider has finished verifying the DKIM record.
• You sent a new test email after enabling DKIM.

DNS existing is not enough. The sender must actually sign the message.

Troubleshooting: DKIM exists but email shows dkim=fail

If DNS has DKIM but a test email shows dkim=fail, check:

• Public key was copied completely.
• Selector matches the DKIM-Signature header.
• Signing domain matches the DNS record.
• Message was not modified after signing.
• Outbound gateway did not alter the message.
• Footer or disclaimer did not break the signature.
• DNS record is not malformed.
• Provider is using the current key.
• The email was sent after the DKIM fix, not before.

DKIM fail usually means there was a signature, but verification did not work.

Troubleshooting: Microsoft DKIM shows CNAME missing

If Microsoft says a DKIM CNAME is missing, check:

1. Did you add both selectors?
2. Are they CNAME records?
3. Are they DNS-only in Cloudflare?
4. Did you use the exact target Microsoft gave you?
5. Did you enter only selector1._domainkey, not the full domain twice?
6. Did you add records in the active Cloudflare zone?
7. Has enough time passed for DNS propagation?
8. Are you enabling DKIM for the correct custom domain?

Do not replace Microsoft DKIM CNAMEs with TXT records.

Troubleshooting: Google DKIM does not authenticate

If Google DKIM does not authenticate, check:

1. Was the key generated inside Google Admin?
2. Was the TXT record added at the active DNS host?
3. Is the selector correct?
4. Is the DKIM public key complete?
5. Did you wait for DNS propagation?
6. Did you return to Google Admin and start authentication?
7. Are you testing from a Google Workspace mailbox on that domain?
8. Are you checking a new email sent after DKIM was enabled?

Do not create your own Google DKIM value manually. Use the value Google provides.

Troubleshooting: DKIM passes but emails still go to spam

DKIM helps, but it does not guarantee inbox placement.

• SPF
• DMARC
• Domain reputation
• IP reputation
• Email content
• Sending volume
• Bounce rate
• Complaint rate
• Engagement
• Whether the domain is new
• Whether the email looks like cold outreach
• Whether recipients mark messages as spam

If DKIM passes but email still goes to spam, check SPF, DMARC, content quality, sending behavior, and reputation.

What not to do

• Do not check DKIM without knowing the selector.
• Do not guess DKIM records.
• Do not create Microsoft 365 DKIM as TXT records.
• Do not create Google DKIM from a random template.
• Do not add DKIM at the root domain.
• Do not proxy DKIM CNAMEs through Cloudflare.
• Do not assume one DKIM record covers every sender.
• Do not delete old selectors during an active migration.
• Do not move DMARC to p=reject before checking DKIM alignment.
• Do not assume DKIM pass means inbox guaranteed.
• Do not change MX records when only DKIM is broken.

Final DKIM checklist

• Identify the sending provider.
• Find the exact DKIM selector.
• Confirm whether the provider needs TXT or CNAME.
• Add the record at the active DNS host.
• Confirm the record is under selector._domainkey.
• Keep CNAME DKIM records DNS-only in Cloudflare.
• Copy the public key or CNAME target exactly.
• Wait for propagation.
• Enable DKIM in the provider admin area.
• Send a new test email.
• Confirm dkim=pass.
• Confirm signing domain aligns with visible From domain.
• Confirm DMARC passes.
• Repeat for every sending platform.

A clean DKIM setup is provider-specific, selector-specific, and tested with real outgoing email.

Run a DKIM check

Use Domain Email Doctor to scan your domain's public email DNS records before changing anything.

A scan can help identify whether DKIM is missing, whether the selector may be wrong, and whether SPF, DMARC, MX, and nameserver records also need attention.

For the most accurate DKIM troubleshooting, compare the DNS scan with a real test email header so you can see which selector and signing domain your email provider is actually using.