DKIM Checker: What to Check When DKIM Fails

A DKIM checker helps you answer a specific but important question: can receiving mail servers find the public DKIM key for your sending domain and selector? When DKIM fails, the issue is often not the message copy. It is usually a selector mismatch, missing DNS record, wrong CNAME target, broken TXT value, disabled signing, changed sending provider, or DMARC alignment problem.

This guide explains what to check when DKIM fails, how to use a DKIM checker, how DKIM records work, what common errors mean, and how to fix the failure without breaking other senders. It is written for founders, marketers, RevOps teams, agencies, IT admins, and deliverability operators who need a practical troubleshooting workflow for cold outreach, newsletters, product updates, and transactional email.

The short version: identify the signing domain and selector from the message headers, check the DNS record at selector._domainkey.example.com, confirm the record is published as your provider expects, verify that outgoing messages are actually being signed, then check whether DKIM aligns with the visible From domain for DMARC. A DKIM checker is the fastest way to catch selector and DNS problems before a campaign turns into a deliverability incident.

Start Free with BuffSend

Try the BuffSend DKIM Checker

Use the DKIM checker below to inspect the public key record for a domain and selector. Enter the sending domain, then enter the selector used by your email provider. Common selectors include google, default, selector1, selector2, k1, and provider-specific values.

What Is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication method that lets a sending system attach a cryptographic signature to an email message. The receiving server can use the public key published in DNS to verify that the signed parts of the message were authorized by the signing domain and were not changed in a way that breaks the signature.

The official DKIM standard is RFC 6376. Most teams do not need to read the full RFC to fix everyday DKIM problems, but it is the authority behind selectors, signing domains, public keys, and verification behavior.

What DKIM proves

DKIM helps prove that a message was signed by a domain that controls the matching private key. If the public key in DNS verifies the signature, the receiver has evidence that the message was authorized by that signing domain and that the signed content was not materially altered after signing.

DKIM does not prove the email is wanted

A DKIM pass does not guarantee inbox placement. It does not prove consent, relevance, or recipient interest. It is an identity and integrity signal. Inbox providers still evaluate sender reputation, complaints, engagement, content, list quality, and compliance.

What a DKIM record looks like

A DKIM public key is usually published in DNS as a TXT record, though some providers use CNAME records that point to a provider-managed key. The lookup name follows this pattern:

selector._domainkey.example.com

A simplified TXT record looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The v=DKIM1 tag identifies the record. The k= tag identifies the key type when included. The p= tag contains the public key. If the p= value is missing, empty, cut off, or published at the wrong name, DKIM verification can fail.

DKIM vs SPF vs DMARC

DKIM is one layer of email authentication. SPF authorizes sending servers. DKIM signs messages. DMARC checks whether SPF or DKIM aligns with the visible From domain and tells receivers what policy to apply when authentication fails.

Open the Free DKIM Checker

How a DKIM Checker Works

A DKIM checker performs a DNS lookup for the selector and domain you provide. If you enter google as the selector and example.com as the domain, the checker looks for a record at google._domainkey.example.com. If the record exists, the checker can show whether it appears to be a DKIM record and whether it contains the expected public key material.

What a DKIM checker can confirm

A DKIM checker can confirm that the DNS record exists, that it is published at the expected name, that the record contains v=DKIM1 when expected, and that the public key field exists. It can also help reveal DNS propagation problems, selector typos, wrong domain checks, and provider setup mistakes.

DNS visibility is the first gate

If the public key cannot be found in DNS, receivers cannot verify the DKIM signature that references it. That makes DNS visibility the first gate in DKIM troubleshooting.

What a DKIM checker cannot confirm by itself

A DNS-only DKIM checker does not prove that your live outgoing messages are being signed correctly. It checks the public key record. To confirm live signing, you need to send a test message and inspect the headers. The DNS record can be correct while the sending platform is still not signing messages with the matching selector.

Record present does not always mean DKIM pass

If a record exists but the message is signed with a different selector, a different domain, or modified after signing, DKIM can still fail. That is why the full workflow includes both DNS checks and message header checks.

What to Check When DKIM Fails

When DKIM fails, work from the message outward. Start with the failed email's headers, identify the signing domain and selector, check DNS, then verify provider signing settings and DMARC alignment. Do not guess the selector from memory if you can inspect the actual message.

Check 1: Is the Message Actually Signed?

Open the email headers and look for a DKIM-Signature header. If there is no DKIM signature at all, DNS may not be the problem. The sending platform may not be configured to sign outgoing mail, the sender may be using the wrong domain, or the message may be leaving through a system that does not apply DKIM.

What to look for

• A DKIM-Signature header exists.
• The d= value shows the signing domain.
• The s= value shows the selector.
• The bh= value is present for the body hash.
• The b= value is present for the signature.

Check 2: Are You Testing the Right Selector?

Selector mistakes are one of the most common DKIM troubleshooting problems. The selector is not always default. Google commonly uses google. Microsoft 365 commonly uses selector1 and selector2. Other platforms may use k1, s1, smtpapi, mail, or a provider-specific selector.

Use the header, not a guess

If the failed message says s=selector1 and d=example.com, check selector1._domainkey.example.com. If you check default._domainkey.example.com, you may get a failure even though the live message used a different selector.

Check 3: Are You Testing the Right Domain?

The DKIM signing domain is the value in the d= tag, not always the visible From domain. Sometimes a provider signs with its own domain by default. Sometimes a custom domain is configured but not enabled. Sometimes a subdomain signs mail while the visible From address uses the root domain.

Domain mismatch example

If the From address is alex@example.com but the DKIM signature says d=mailservice.com, DKIM might pass for the provider domain but fail DMARC alignment for example.com. That is a different problem from a missing public key.

Check 4: Does the DNS Record Exist?

Use the DKIM checker to look up the exact selector and domain from the message header. If no record is found, the record may be missing, published at the wrong host, still propagating, or hidden behind a DNS provider formatting issue.

Common DNS publishing mistakes

• Publishing the full host twice, such as selector._domainkey.example.com.example.com.
• Publishing only selector instead of selector._domainkey.
• Adding quotes or spaces that break the key value.
• Cutting off the public key when pasting into DNS.
• Using TXT when the provider asked for CNAME, or CNAME when the provider asked for TXT.

Check 5: Is the Public Key Empty or Broken?

A DKIM record with an empty p= tag can indicate a revoked key. A record with a truncated key can fail verification. A record split incorrectly across TXT chunks can also create problems if the DNS provider does not publish the final value correctly.

What a healthy record needs

The record should contain the public key exactly as the provider expects. Do not manually edit, shorten, reformat, or wrap the key unless the DNS provider requires a specific format and the final DNS lookup still returns the correct value.

Check Your DKIM DNS Record

Common DKIM Failure Messages and What They Mean

Different tools and receiving servers report DKIM failures in different ways. The language varies, but most failures map back to a small number of causes: no signature, no key, bad key, body hash mismatch, signature verification failure, or DMARC alignment failure.

No DKIM Signature Found

This means the message did not include a DKIM-Signature header. The sender may not have DKIM enabled, the message may have left through a different system, or the platform may only sign certain domains or mail streams.

Fix

Enable DKIM signing in the sending platform. Confirm the sender domain is verified. Send a fresh test and inspect headers again.

DKIM Public Key Not Found

This means the message referenced a selector and signing domain, but the receiver could not find the matching public key in DNS.

Fix

Check the exact selector and signing domain. Publish the required DKIM TXT or CNAME record. Wait for DNS propagation, then rerun the DKIM checker.

DKIM Body Hash Did Not Verify

This usually means the body content changed after the message was signed. Some forwarding systems, footers, disclaimers, link rewriting, or security tools can modify a message enough to break the body hash.

Fix

Send a test directly from the platform and another through the route that failed. Compare whether an intermediate system adds footers, rewrites links, or changes MIME structure.

DKIM Signature Verification Failed

This means the public key was found, but the signature did not validate. Causes can include wrong key, key rotation mismatch, message modification, canonicalization issues, or a provider signing configuration problem.

Fix

Confirm the current selector and public key from the provider. Republish the key if needed. If the issue started after key rotation, make sure DNS and the sending platform are using the same active key.

DKIM Passed But DMARC Failed

This means DKIM may have validated, but not in a way that aligned with the visible From domain. DMARC requires SPF or DKIM alignment. A provider-domain DKIM pass may not be enough for your own From domain.

Fix

Configure custom-domain DKIM signing so the d= domain aligns with the visible From domain or organizational domain. Then test DMARC alignment in the message headers.

Provider-Specific DKIM Checks

Each email provider handles DKIM setup differently. Some publish TXT records. Others ask you to publish CNAME records that point to provider-managed keys. Some sign by default with a provider domain until you enable custom-domain signing. When DKIM fails, check the provider instructions rather than assuming every DKIM setup looks the same.

Google Workspace DKIM Checks

Google Workspace lets administrators generate a DKIM key in the Admin console and publish it in DNS. Google's official DKIM setup guide explains the setup flow, including generating the key and turning on authentication after the DNS record is available.

What to check for Google

• The selector matches the one configured in Google Admin.
• The DNS TXT record is published at the correct ._domainkey host.
• The public key was pasted completely.
• DKIM authentication was turned on after DNS was published.
• You waited long enough for Google and DNS propagation.

Microsoft 365 DKIM Checks

Microsoft 365 commonly uses CNAME records for selector1 and selector2 for custom domains. Microsoft's official DKIM configuration guide explains how DKIM signing works for custom domains in Microsoft 365.

What to check for Microsoft 365

• The custom domain is added and verified in Microsoft 365.
• The two selector CNAME records exist exactly as Microsoft provides them.
• DKIM signing is enabled for the custom domain.
• The message signs with your custom domain, not only the tenant domain.
• DMARC alignment passes for the visible From domain.

Sales Engagement and Marketing Platforms

Cold outreach and marketing platforms often give you DKIM records during sender setup. Some use one shared selector. Others issue a unique selector per domain or account. If you move platforms or rotate senders, old keys may stop matching new signatures.

What to check for outreach tools

• The sender domain is verified in the platform.
• The platform's DKIM record is still present in DNS.
• The platform is actually the system sending the message.
• The DKIM selector in headers matches the provider setup page.
• Tracking and routing changes did not alter the message after signing.

Yahoo and High-Volume Sender Checks

Yahoo's sender best practices emphasize authentication, DKIM, DMARC, list quality, and responsible sending behavior. If you send at volume, DKIM should not be treated as optional plumbing. It is part of the sender identity that mailbox providers use to evaluate mail.

What to check for high-volume sending

• Every marketing stream signs with a domain you control.
• DKIM keys are at least as strong as your provider recommends.
• Transactional and marketing streams are not confusing reputation signals.
• DMARC policy and reporting are monitored.
• Failed authentication is investigated before scaling volume.

Protect Your Sending Domain

DKIM DNS Troubleshooting Checklist

Use this checklist when a DKIM checker cannot find the record or when the record appears wrong. DNS issues are common because DKIM values are long, selectors are easy to mistype, and DNS providers handle host fields differently.

Host Name Checks

• Confirm the selector from the actual message header.
• Confirm the signing domain from the actual message header.
• Build the lookup name as selector._domainkey.domain.com.
• Check whether the DNS provider automatically appends the root domain.
• Make sure the record is not published under www.

Record Type Checks

• Use TXT when the provider gives a TXT public key.
• Use CNAME when the provider gives a CNAME target.
• Do not publish both TXT and CNAME at the same host.
• Do not flatten a provider CNAME into a guessed TXT value.
• Remove stale records only after confirming they are no longer used.

Value Checks

• The value starts with v=DKIM1 when expected.
• The p= public key is present and not empty.
• The key has not been truncated by the DNS interface.
• Line wrapping did not introduce invalid spaces.
• The final public DNS lookup returns the value your provider expects.

Propagation Checks

• Wait for the DNS TTL after publishing changes.
• Check from an external resolver, not only inside your DNS provider.
• Confirm that old cached records are not hiding the fix.
• Do not rotate keys and send a major campaign before propagation is stable.
• Retest with a fresh email after DNS is visible.

DKIM Header Troubleshooting Checklist

DNS can be perfect while live messages still fail. Header checks tell you what the sending platform actually did. Always test with a fresh email from the same platform, sender, domain, and campaign configuration that will be used for the real send.

Signing Domain Checks

Look at the d= tag in the DKIM-Signature header. This is the domain taking responsibility for the signature. If it is your email provider's domain instead of your own domain, DKIM may pass but not align for DMARC.

Alignment question

Ask: does the d= domain align with the visible From domain? If not, configure custom-domain DKIM signing in the provider.

Selector Checks

Look at the s= tag. This is the selector the receiver uses to find the public key. If the message uses s=k1, then checking selector1 will not explain the failure.

Rotation question

Ask: did the provider rotate from one selector to another? If yes, both old and new keys may need to exist during transition depending on how the provider signs messages.

Canonicalization Checks

The c= tag describes canonicalization. Canonicalization affects how whitespace and headers are normalized before verification. Most teams do not manually tune this, but it matters when messages are modified after signing.

Modification question

Ask: is any system adding a footer, disclaimer, tracking wrapper, or security banner after DKIM signing? If yes, the body hash or signature can fail.

Multiple DKIM Signatures

Some messages include more than one DKIM signature. This can be normal. For DMARC, at least one valid aligned DKIM signature can be enough. Do not panic just because one provider signature fails if another aligned signature passes, but investigate repeated failures from your primary sending domain.

Multiple signature question

Ask: which DKIM signature is aligned with the visible From domain, and does that one pass?

How to Fix DKIM Without Breaking Other Senders

DKIM records often support live production mail. Change them carefully. A rushed DNS edit can fix one platform while breaking another. Before deleting or replacing records, identify which systems use each selector and whether any old messages or delayed retries still depend on the current key.

Map Every Sending System

List every system that sends email for the domain: Google Workspace, Microsoft 365, CRM, sales engagement platform, marketing automation tool, transactional email service, billing platform, help desk, monitoring tool, and any legacy system. Each may sign with its own DKIM selector.

Do not assume one DKIM record covers everything

A domain can have many DKIM selectors. Each selector is a separate DNS name. Removing an old selector may be safe, or it may break a platform that still signs with it.

Make One Change at a Time

If you update DNS, enable signing, change providers, and rotate keys all at once, troubleshooting becomes harder. Make the smallest change that should fix the failure, then send a new test and inspect the result.

Retest after each change

Use the DKIM checker after DNS changes and send a fresh email after signing changes. Old test messages will not update themselves.

Keep Old Keys During Rotation When Needed

Key rotation can require overlap. If a provider starts signing with a new selector while some systems still retry or send with the old one, removing the old DNS record too early can cause failures.

Rotation rule

Follow the provider's key rotation guidance. Keep both selectors available during the transition if the provider expects overlap.

Document the Final Setup

After fixing DKIM, document the selector, DNS host, record type, provider, signing domain, setup date, and owner. Future troubleshooting is much faster when the team knows which selector belongs to which sending system.

Check SPF Next

Example: Debugging a DKIM Failure Before a Campaign

Imagine a B2B team preparing a cold outreach campaign from alex@example.com. They run a seed test and see that Gmail reports DKIM fail. The team opens the message headers and finds this simplified result:

DKIM-Signature: v=1; d=example.com; s=selector1; ...
Authentication-Results: dkim=fail header.d=example.com

Step 1: Check the selector and domain

The header says d=example.com and s=selector1, so the team checks selector1._domainkey.example.com. The DKIM checker finds no record.

Step 2: Check DNS setup

The team opens the DNS provider and finds a CNAME at selector1._domainkey.example.com.example.com. The provider automatically appended the root domain, and the person who created the record pasted the full host into a field that expected only the host prefix.

Step 3: Fix the host value

They replace the host with selector1._domainkey, keep the provider's CNAME target unchanged, and wait for DNS propagation.

Step 4: Retest DNS and headers

The DKIM checker now finds the record. The team sends a fresh seed test and sees dkim=pass. They also confirm DMARC alignment because the signing domain matches the visible From domain.

The lesson

The failure was not the campaign copy, the subject line, or the sending platform reputation. It was a DNS host formatting issue. A DKIM checker made the problem visible quickly because it tested the exact selector and domain from the headers.

DKIM Checks Before a Real Campaign

DKIM troubleshooting is not only for emergencies. The best time to check DKIM is before a campaign launches, especially when you are using a new domain, new sender, new platform, new tracking domain, or newly rotated key. A clean DKIM check before sending gives your team a clearer starting point for deliverability and makes later debugging much easier.

Google's email sender guidelines include authentication as a core expectation for senders. DKIM is one part of that expectation, alongside SPF, DMARC, low spam rates, and responsible sending. Yahoo's sender guidance makes the same practical point: authentication and sender behavior work together. A domain that signs mail correctly still needs clean lists, relevant content, low complaints, and careful volume.

Pre-Launch DKIM Test 1: Check DNS From Outside Your Provider

Do not rely only on the green status inside your email platform. Run an external DKIM checker against the selector and domain. This confirms that public resolvers can see the record, not just that the provider thinks setup is complete.

What to record

Record the domain, selector, record type, provider, lookup result, date checked, and person responsible. This takes less than a minute and prevents confusion later when someone asks which selector belongs to which platform.

Pre-Launch DKIM Test 2: Send a Real Test Message

After DNS passes, send a real test message from the same campaign platform. Do not test from your personal inbox if the real campaign will come from an outreach platform. The test must use the real sender, domain, platform, tracking configuration, template, and mail stream.

What to inspect

• The message includes a DKIM-Signature header.
• The d= domain is the expected signing domain.
• The s= selector is the selector you checked in DNS.
• The authentication result says DKIM passes.
• DMARC passes through DKIM or SPF alignment.

Pre-Launch DKIM Test 3: Check DMARC Alignment

DKIM success matters most when it contributes to DMARC alignment. DMARC is defined in RFC 7489, and in practical campaign work it answers whether authenticated mail aligns with the domain recipients see in the From address. If DKIM passes for a provider domain that does not align, the message may still fail DMARC unless SPF aligns.

Alignment example

If your visible From address is alex@example.com, but DKIM signs with d=sendplatform.net, DKIM may pass for the platform while not aligning with example.com. The fix is usually to enable custom-domain DKIM signing in the platform so d=example.com or an aligned organizational domain appears in the signature.

Pre-Launch DKIM Test 4: Test Through the Full Route

Messages can change after signing. Some organizations add legal footers, security banners, tracking wrappers, or link rewriting after a platform signs the message. If those changes affect signed content, DKIM can fail in the recipient's mailbox even though the sending platform originally signed correctly.

Full-route test

Send seed tests to Gmail, Microsoft 365, Yahoo, and at least one business inbox if your audience is B2B. Inspect the final received headers in each mailbox. If DKIM passes in one place and fails in another, compare how each route modified the message.

Pre-Launch DKIM Test 5: Confirm Key Strength and Rotation Plan

Most teams use the key size and algorithm provided by their email service. Still, it is worth knowing where your DKIM parameters come from. IANA maintains the official DKIM parameters registry, and providers document their own supported setup. In normal operations, your main job is to avoid stale keys, incomplete keys, and unmanaged rotations.

Rotation planning

If a provider rotates DKIM keys, schedule the change away from a major campaign launch. Publish the new record, wait for DNS visibility, confirm signing, and keep old records during the overlap period if the provider requires it.

Run a Pre-Launch DKIM Check

FAQ: DKIM Checker and DKIM Failures

Final Recommendation

When DKIM fails, do not guess. Open the failed message headers, find the d= signing domain and s= selector, run a DKIM checker against that exact DNS name, then confirm the sending platform is signing live messages with the same selector. If DKIM passes but DMARC fails, fix alignment by enabling custom-domain signing.

DKIM is not just a technical checkbox. It is one of the identity signals behind deliverability, DMARC, and domain trust. A clean DKIM setup makes it easier for mailbox providers to verify your mail and easier for your team to troubleshoot when something changes.

Use the DKIM checker before major campaigns, after provider changes, during domain setup, after key rotation, and whenever headers show DKIM failures. Catching the issue before you send is much cheaper than discovering it after a campaign lands in spam.

Start Free with BuffSend