If you searched for , , or , you probably need to answer two questions fast: does the selector exist, and are real messages actually passing DKIM with the domain and selector you intended?

This guide shows how to validate both the DNS side and the live-message side of DKIM so you can fix failures before they turn into DMARC or inbox-placement problems.

Quick answer

A DKIM checker should confirm:

  • the selector TXT record exists
  • the DNS record is formatted correctly
  • the sender is using the expected selector
  • real messages show
  • the signing domain supports DMARC alignment

Checking only the selector record is not enough. Many DKIM failures happen after DNS is technically present.

What DKIM is validating

DKIM, or DomainKeys Identified Mail, signs outgoing email using a private key. Receivers use the public key you publish in DNS to verify the message was signed by an authorized sender and was not altered in transit.

A selector record usually looks like this:

The checker has to validate more than the presence of . It also has to help you confirm the sender is using that selector correctly.

How to run a full DKIM check

Use this workflow:

  1. Identify the selector from your sender or from a real message header.
  2. Query .
  3. Confirm the record is valid and the public key is intact.
  4. Send a live message through the sender you care about.
  5. Inspect and .
  6. Confirm the domain aligns with your DMARC strategy.

Useful companion pages:

What a DKIM checker should tell you

Selector exists and looks valid

Good. Now verify:

  • the sender is actually using that selector
  • the signature is passing on live messages
  • the signing domain is the right one for DMARC alignment

Selector not found

This usually means:

  • the selector name is wrong
  • DNS is not published yet
  • the sender is configured to use a different selector

Fix:

  1. verify the selector name in provider settings
  2. query DNS again after propagation
  3. inspect a live message to see the actual value

Record exists but the key is malformed

Long TXT values can be copied incorrectly, truncated, or wrapped badly.

Fix:

  • republish the public key carefully
  • avoid partial copy-paste from vendor dashboards
  • retest with real mail after propagation

Live messages still fail DKIM

This often means the DNS record is fine but the sending platform is:

  • signing with a different selector
  • signing with a different domain
  • sending unsigned mail through one of the platforms in the stack

That is why a DKIM checker needs to be paired with live header analysis.

How to read DKIM results in message headers

Look for:

  • in
  • the selector in
  • the signing domain in

If appears but DMARC still fails, the issue is often alignment. The domain may not align with the visible From domain.

Common DKIM failures and fixes

Wrong selector published

Teams publish but the provider signs with .

Fix:

  • inspect a live message
  • confirm the real selector
  • publish the matching selector record

Broken key rotation

The provider switches to a new selector before DNS is ready, or the old selector gets removed too early.

Safer rotation flow:

  1. publish the new selector
  2. wait for propagation
  3. switch the sender
  4. validate live messages
  5. retire the old selector later

Third-party sender signs with its own domain

A platform may pass DKIM but still not align with your DMARC policy if the signing domain is not your domain strategy.

Fix:

  • enable custom signing where possible
  • compare and visible From domain
  • confirm DMARC alignment after the change

Multiple senders, incomplete inventory

One provider passes while another still sends unsigned or misaligned mail.

Fix:

  • inventory every sender
  • validate each critical path separately
  • do not assume one passing message proves the domain is healthy

DKIM checker vs DKIM generator

A DKIM checker validates what already exists.

A generator helps you create a selector record for publication. In practice, most teams need both:

Why DKIM checking should be part of release workflow

DKIM failures often show up after:

  • domain onboarding
  • ESP migration
  • selector rotation
  • template or sender changes
  • infrastructure moves

That makes DKIM checking a release and operations concern, not just a DNS concern.

MailSlurp supports that workflow with:

If your team wants a repeatable workflow instead of occasional header debugging, create a free account at app.mailslurp.com.

FAQ

What does a DKIM checker do?

It validates the selector record in DNS and helps confirm whether real messages are using that selector successfully.

Can a DKIM record exist while DKIM still fails?

Yes. The sender may be using the wrong selector, the wrong domain, or a broken signing path.

Why does DKIM pass but DMARC still fail?

Because DKIM pass only proves the signature worked. DMARC also requires alignment between the signing domain and the visible From domain.

When should teams re-run DKIM checks?

After sender changes, custom-domain onboarding, selector rotation, DNS changes, and before major sends.

Final take

A good DKIM checker workflow validates the selector, the live signature, and the alignment story together. That is how you catch the failures that matter before the inbox does.