DKIM Check: Verify the DNS Record and the Actual Email
Run a DKIM check using the real message selector, DNS records and receiver results. Diagnose missing signatures, failed verification and DMARC alignment.
TL;DR
- A complete DKIM check examines both the published DNS key and a message sent through your real email service. A visible DNS record alone does not prove that mail is signed correctly.
- Read the message’s DKIM signature to identify its signing domain and selector, then look up that exact selector under the signing domain.
- Use the receiving mail system’s authentication results to distinguish a passed signature, a failed signature, and no signature at all.
- DKIM passing does not guarantee inbox placement or DMARC alignment. Check the visible From domain, other authentication results, and the delivery event separately.
What does a DKIM check actually check?
DKIM lets a receiving system verify a signature created by a sending system. The sender uses a private key; the recipient retrieves the corresponding public key through DNS. The signature covers selected message headers and the message body according to its declared rules.
There are therefore two useful checks. A DNS lookup asks whether the expected public key can be found. A message check asks whether a particular received message passes verification. Run both when setting up a sending domain or diagnosing an authentication failure.
Google’s authentication guidance explains that an authenticated message can still be spam and that authentication alone does not guarantee delivery. Treat the result as evidence about a specific mechanism, not a verdict about every aspect of the email.
Start with a real message and its selector
Send a fresh test from the application or campaign service you are configuring to a mailbox you control. Keep the recipient address, send time, and provider message identifier in your private investigation notes. Do not substitute an old message sent through a different service.
Open the message’s full headers. Look for a DKIM-Signature header and identify its d= and s= values. In an illustrative signature containing d=example.com and s=mail2026, the signing domain is example.com and the selector is mail2026.
The public-key lookup name is then:
mail2026._domainkey.example.comThese are example values, not settings to paste into your domain. Your service may supply several selectors for rotation. Copy the actual domain and selector from your message or verified provider setup screen.
Check the exact DNS name
On a system with dig, inspect the TXT and CNAME answers for that name:
dig +short TXT mail2026._domainkey.example.com
dig +short CNAME mail2026._domainkey.example.comA provider may ask you to publish a TXT public key directly or a CNAME pointing to a name it manages. Follow its generated record type and value. If a CNAME is returned, inspect the target’s public-key record as well; do not replace it with a guessed TXT value.
The DKIM specification’s key-retrieval section describes how selectors and signing domains locate the key. Check spelling, the _domainkey label, and whether your DNS control panel automatically appends the domain. Accidentally creating mail2026._domainkey.example.com.example.com is a different record from the intended one.
Changing a DNS record does not rewrite the signature on an email already sent. After a correction has become visible to the resolvers you are checking, send a new message through the actual provider and repeat the message-level test.
Read the receiving system’s result
Use authentication results added by the receiving mailbox system you trust. An arbitrary header supplied by a sender is not trustworthy proof of authentication. The Authentication-Results standard explains the need for a trusted authentication boundary.
| What you find | What it establishes | Next check |
|---|---|---|
| Expected DNS key is visible | The key can be retrieved by that lookup | Send a message and inspect verification. |
| dkim=pass in trusted receiver results | That signature verified for the received message | Compare the signing domain with the visible From domain. |
| dkim=fail | Verification did not succeed | Check selector, key, and changes made after signing. |
| No DKIM signature | This message was not signed at that point | Confirm signing is enabled for this sending path. |
| A different signing domain | Another service or configuration signed the message | Identify the actual sending provider before editing DNS. |
A forwarded message or mailing-list transformation can complicate diagnosis. Compare a direct test with the transformed copy rather than treating them as the same delivery path.
A practical example of a misleading green result
Imagine a team that sends product notifications through Service A and marketing campaigns through Service B. Service A’s selector resolves correctly, so the team marks DKIM “done.” Marketing messages still fail because Service B uses another selector whose record was never published.
The fix is not to keep testing Service A’s record. Capture a message from Service B, find its selector, and verify that service’s setup. Maintain a small register with one row per sending service: domain, selector, record type, responsible owner, and last successful message test.
This same approach is useful when moving to MailBlastr: check the record set shown for the actual configured sending domain and verify mail from that path. A successful test from your personal inbox does not validate the application’s sending infrastructure.
DKIM pass versus DMARC alignment
DKIM verification and DMARC alignment answer different questions. A signature can pass using a domain that does not align with the domain in the visible From address. DMARC evaluates alignment as part of its authentication policy; a passed signature alone is not the complete check.
Compare the visible From domain with the signing domain and inspect the receiver’s DMARC result. Use the policy and alignment mode configured for the domain, rather than assuming every subdomain relationship is treated identically. The DMARC specification provides the underlying alignment rules.
For a broader setup walkthrough, continue with our SPF, DKIM, and DMARC guide. Keep DNS authentication work separate from decisions about recipient consent, content quality, and suppression handling.
Keep a repeatable verification record
After a successful test, record the time, sending service, selector, signing domain, and receiving system’s result. Retest when changing providers, rotating keys, or adding a new sending domain. Keep the private key out of screenshots, tickets, and shared notes; the public DNS record is the information recipients need.
For support, a redacted header excerpt and provider message identifier are usually more useful than “DKIM is broken.” Remove recipient information and sensitive message content before sharing. The goal is to make the exact failing path reproducible without distributing the email itself.