A DKIM record won’t verify when the DNS record your email system expects is missing, malformed, published in the wrong place, or does not match the key used to sign mail. The fastest fix is to stop guessing: identify the exact signing domain and selector, query the authoritative DNS record, then confirm a real delivered message passes DKIM.

What DKIM verification is actually checking

DomainKeys Identified Mail, or DKIM, lets a sending system add a cryptographic signature to an email. The sending system keeps a private key; the corresponding public key is published in DNS. A receiving server reads the DKIM signature in the message, retrieves the public key from DNS, and checks whether the signature matches the message it received.

A DKIM setup has two distinct parts:

DNS publication: A public key or provider-managed CNAME must be available at the expected selector hostname.
Message signing: The mail system must sign outgoing messages using the matching private key, selector, domain, and algorithm.

That distinction matters because a provider dashboard can fail to verify a DNS record even before any message is sent. Conversely, a DNS lookup can look perfect while real messages still fail DKIM because the sender is using a different selector, the private key changed, or something modifies the message after signing.

DKIM verification normally begins with values in the message's DKIM-Signature header. A simplified example looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
 c=relaxed/relaxed; h=from:to:subject:date:message-id;
 bh=base64-body-hash; b=base64-signature

The two fields that tell receivers where to find the public key are:

d=example.com — the signing domain.
s=mail2026 — the selector.

The DNS query name is constructed as:

mail2026._domainkey.example.com

If your configuration screen tells you to create selector._domainkey.example.com, do not substitute your visible From address, your SMTP hostname, or your website hostname. The exact selector and signing domain supplied by the system doing the signing are what matter.

Start by identifying what “won’t verify” means

The wording can describe several different failures. Treating all of them as a generic DNS propagation issue wastes time.

A provider cannot verify the DNS record

This means the sending platform performed a DNS lookup and did not find the expected record or CNAME. Common results include a missing record, an incorrect hostname, a copied value with altered characters, or DNS hosted somewhere other than the place where you edited it.

In this situation, sending may still be possible through an SMTP relay or REST API, but the provider may not sign mail with your domain until validation completes. A successful 250 SMTP response only means the relay accepted a message; it does not prove the message was signed with DKIM or will pass at the recipient.

A DNS lookup tool cannot find a valid DKIM key

Tools such as MXToolbox's DKIM lookup require both the domain and selector because DKIM records are selector-specific. If you enter the correct domain but the wrong selector, the lookup will report a failure even if another selector for the same domain works.

A lookup failure usually falls into one of these technical categories:

NXDOMAIN: The DNS name does not exist.
NOERROR with no usable TXT or CNAME answer: The name exists but does not publish the expected DKIM data.
SERVFAIL: The resolver could not get a usable answer, potentially because of authoritative DNS, delegation, or DNSSEC trouble.
A record is returned but fails parsing: The host is correct, but the value is malformed, incomplete, or not the key expected by the verifier.

A real delivered message says `dkim=fail`

This is a signing or verification failure at the recipient. The record may exist, but the actual message could be signed with another selector, signed with a stale private key, altered after signing, or signed using an incompatible or weak algorithm.

Inspect the recipient's full headers. Look for both DKIM-Signature and Authentication-Results. A passing example commonly resembles:

Authentication-Results: mx.example-recipient.net;
 dkim=pass header.i=@example.com header.s=mail2026 header.b=AbCdEf;
 spf=pass smtp.mailfrom=bounces.example.com;
 dmarc=pass header.from=example.com

A failure may say dkim=fail, dkim=neutral, dkim=temperror, or dkim=permerror. Those labels point to different next steps, so save the full header rather than relying only on a dashboard badge.

Confirm the exact DKIM DNS record you should publish

Do not create a DKIM record from a generic template if your email platform generated an exact host and value for you. DKIM keys are paired cryptographic material: the public key in DNS must correspond to the private key used by the sender.

There are two legitimate provisioning models.

Model 1: A TXT record containing the public key

A direct DKIM key record typically looks like this in zone-file form:

mail2026._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The key parts are:

mail2026 is the selector.
_domainkey is the DKIM namespace.
example.com is the signing domain.
TXT is the DNS record type.
v=DKIM1 identifies the record as DKIM version 1.
k=rsa identifies the public-key type when present.
p= contains the Base64-encoded public key.

The p= value is required for an active key record. It must contain the exact public-key material supplied by the signing service, with no line-wrap spaces, missing characters, copied quotation marks, or added punctuation.

Model 2: A CNAME record pointing to a provider-managed key

Many sending services use a CNAME so they can host and rotate the public key without asking you to paste a long TXT value. A generic example is:

mail2026._domainkey.example.com. 3600 IN CNAME mail2026.example.provider-dkim.net.

In this model, publish the CNAME exactly as given. Do not convert it into a TXT record, do not add v=DKIM1 to your own DNS value, and do not change the destination to match an assumed pattern.

A DNS name that has a CNAME cannot also publish a TXT record or other ordinary record type at that exact same name. If you previously created a TXT record at mail2026._domainkey.example.com, remove it before adding the provider's CNAME. Leaving both in place is a common reason a record appears inconsistent across control panels and lookup tools.

Copy the host field correctly for your DNS provider

The most frequent DKIM mistake is an accidental doubled domain name. DNS interfaces vary:

Some expect only the relative host, such as mail2026._domainkey.
Some expect a full hostname, such as mail2026._domainkey.example.com.
Some display a full hostname but automatically append your zone name behind the scenes.

If your DNS zone is example.com and you enter mail2026._domainkey.example.com into a field that automatically appends the zone, you may accidentally publish:

mail2026._domainkey.example.com.example.com

That record is valid DNS syntax, but it is the wrong DNS name and no DKIM verifier looking for mail2026._domainkey.example.com will find it.

After saving, never trust the DNS editor's abbreviated display alone. Query the full hostname independently.

Query public DNS before pressing Verify again

A dashboard verification button is useful, but command-line DNS checks show exactly what public resolvers can see. Run these commands from a terminal, replacing the selector and domain with yours.

Use `dig` on macOS, Linux, or Windows with DNS tools installed

For a TXT-based DKIM record:

dig +short TXT mail2026._domainkey.example.com

For a CNAME-based DKIM record:

dig +short CNAME mail2026._domainkey.example.com
dig +short TXT mail2026.example.provider-dkim.net

A valid TXT result should include a value beginning with v=DKIM1 and a nonempty p= field. A valid CNAME result should exactly match the target supplied by the sender.

To bypass your local DNS resolver and compare public resolvers, query specific servers:

dig @1.1.1.1 +short TXT mail2026._domainkey.example.com
dig @8.8.8.8 +short TXT mail2026._domainkey.example.com

If one resolver sees the new record and another sees an old answer, wait for caches to expire. If neither sees it, the problem is not ordinary propagation; revisit the DNS zone, host field, record type, and nameserver delegation.

Use `nslookup` when `dig` is unavailable

On many Windows installations, nslookup is available by default:

nslookup -type=TXT mail2026._domainkey.example.com
nslookup -type=CNAME mail2026._domainkey.example.com

For a CNAME deployment, first verify that the CNAME is present, then query the target for its TXT key. A CNAME target that returns no usable DKIM TXT record may be a provider-side configuration problem, a copied target typo, or a still-pending setup.

Use browser-based checkers as a second opinion

MXToolbox's DKIM lookup checks a selector and domain for a published DKIM key. Mail-tester also offers SPF and DKIM record checks and a mailbox-based deliverability test. These tools are useful because they test from outside your network, but they still need the right selector.

A browser checker confirms public DNS visibility. It does not prove that your application, SMTP relay, or email API is signing live messages with that selector. Follow the lookup with a real send and header inspection.

Fix the DNS mistakes that cause most verification failures

A correct-looking key pasted into the wrong DNS shape still fails. Work through the following failure modes in order.

Wrong record type

If your provider says TXT, create a TXT record. If it says CNAME, create a CNAME record. Do not decide based on what another email provider uses for a different domain.

Multiple systems can sign mail for the same domain, but each needs its own selector hostname. For example, these can coexist:

product._domainkey.example.com  TXT
workspace._domainkey.example.com TXT
mailer._domainkey.example.com   CNAME

What cannot coexist is a TXT and CNAME at the same owner name, such as two different record types both at mailer._domainkey.example.com.

Wrong hostname or selector

A record at _domainkey.example.com is not the same as a record at mail2026._domainkey.example.com. Likewise, mail2026._domainkey.mail.example.com is different from mail2026._domainkey.example.com.

Selectors are case-insensitive for normal DNS purposes, but do not rely on that as a reason to modify a generated name. Copy the selector exactly. More importantly, do not confuse a selector label with a subdomain used in the visible From address.

Extra quotes, spaces, or split-key errors

DNS providers commonly display TXT values with quotation marks. Those quotes are often a presentation or zone-file convention, not part of the DKIM key itself.

Long RSA public keys can exceed a single DNS character-string's 255-octet limit. DNS supports a TXT record as multiple quoted character-strings, and resolvers concatenate them without adding spaces. A valid zone-file representation can look like this:

mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A"
 "MIIBCgKCAQEAuExampleContinuationWithoutInsertedWhitespace"

However, your DNS provider's interface may handle segmentation automatically. Do not manually split a value unless its documentation explicitly supports that format. If you do split it, do not introduce a literal space, newline, comma, or extra quote inside the Base64 key.

A stale or duplicate key

A selector maps to one active key. If you regenerate a key in the sending platform but leave the old DNS public key published, the platform may sign with the new private key while recipients retrieve the old public key. The resulting message contains a DKIM signature but fails cryptographic verification.

Duplicate TXT records at the same selector can also confuse validation. Remove obsolete DKIM records at the precise selector hostname unless your provider explicitly instructs you to publish a particular multi-string value as one logical record.

Editing DNS in the wrong account or zone

It is possible to log into a domain registrar, add a correct record, and still change nothing public because DNS is delegated to another provider. Find the domain's authoritative nameservers and make edits in the DNS service that those nameservers actually serve.

This problem is especially common after moving a website to a CDN, changing registrars, or delegating a subdomain. If example.com is managed in one DNS zone but mail.example.com is separately delegated, a DKIM record under that delegated subtree may need to be created in the child zone.

Account for DNS caching, TTLs, and DNSSEC failures

DNS changes are not instantaneous across every resolver. The practical delay depends on the prior TTL, resolver caches, provider update timing, and whether an older answer was already cached before you made the change.

A low TTL does not erase existing caches. If the old record had a TTL of 3,600 seconds, a resolver that cached it immediately before your edit can continue returning it for up to an hour. Changing the TTL after the fact affects future answers, not already-cached ones.

Use this sequence instead of repeatedly deleting and recreating records:

Publish the exact requested TXT or CNAME record once.
Query the full hostname with dig or nslookup.
Compare answers from more than one public resolver.
Wait at least through the previous record's TTL if a replacement was made.
Retry provider verification only after public DNS returns the intended answer.

Do not use browser cache clears, local computer reboots, or email application restarts as a DNS troubleshooting strategy. They do not reliably clear the external recursive resolvers that a provider or mailbox service uses.

If lookups return SERVFAIL rather than an old or missing answer, investigate DNS health. Broken DNSSEC validation, expired DNS provider configuration, unreachable authoritative nameservers, and malformed zone data can produce SERVFAIL. In that case, the DKIM value itself may be correct but unavailable to resolvers.

Verify that your messages are actually signed

A verified domain state is only the beginning. Send a fresh email through the exact path your application uses in production.

That means testing the real sending mechanism:

Your production REST email API credentials and sender domain.
Your production SMTP hostname, username, and authenticated account.
The same From address and message construction process used by your app.
Any queue, worker, CRM, marketing automation, ticketing system, or outbound gateway that touches the message.

If your provider offers both REST API sending and SMTP relay, test both if your systems use both. A domain configuration can be correct while a legacy application is still routing through a different SMTP provider or using a different From domain. Consult your provider's email API reference and setup guides for the exact sender-domain and authentication requirements that apply to its REST and SMTP paths.

Read the message headers, not just inbox placement

Send a test message to a mailbox you control and open the original or full message source. Search for:

DKIM-Signature:
Authentication-Results:

Confirm these details:

The message has at least one DKIM-Signature header.
The d= value is a domain you control or expect the provider to sign for.
The s= value corresponds to a DNS record you can query.
Authentication-Results reports dkim=pass.
The visible From domain can align with the DKIM d= domain for DMARC.

A common surprise is seeing a valid DKIM pass for a provider-owned domain rather than your own domain. That can authenticate the message at a technical level, but it may not satisfy DMARC alignment for mail claiming to be from example.com.

Understand the difference between DKIM and DMARC alignment

DKIM can pass while DMARC fails. DMARC compares the visible From: domain with the DKIM signing domain and/or the SPF-authenticated envelope sender domain.

For relaxed DKIM alignment, a subdomain can align with its organizational domain. For example, a message with From: notices@example.com can generally align with d=mail.example.com under relaxed alignment. Under strict alignment, the domains must match exactly.

This is why a dkim=pass result alone is not a complete deliverability diagnosis. Review dmarc=pass as well, especially if Gmail, Yahoo, or enterprise recipient systems are rejecting or filtering messages.

Diagnose signature failures after DNS verifies

If a dashboard can see the record but recipient headers show dkim=fail, focus on the signing path rather than the DNS editor.

The message is signed with another selector

Compare the header's s= field with the DNS hostname you published. If the message says:

s=transactional2025; d=example.com

the receiver queries:

transactional2025._domainkey.example.com

Publishing a key at mail2026._domainkey.example.com will not help. This often happens after changing providers, switching between sandbox and production credentials, or retaining an old mail library configuration.

The private and public keys no longer match

Key rotation is valuable, but it must be coordinated. A safe rotation process is:

Generate or enable a new selector and its matching key pair.
Publish the new record and confirm it resolves publicly.
Change the sender to sign with the new selector.
Test real mail and confirm dkim=pass.
Keep the prior selector published long enough for messages signed before the cutover to be verifiable.
Retire the old selector only after the transition window.

Never overwrite an existing selector's public key before all senders using its private key have stopped. Old queued messages, background jobs, and secondary sending systems may still use that selector.

Something changes the email after DKIM signing

DKIM protects selected headers and a canonicalized version of the body. If a gateway changes a signed part of the message after signing, verification can fail.

Typical causes include:

An outbound gateway appends a legal disclaimer or tracking footer.
A security appliance rewrites URLs after the message was signed.
A mail relay changes MIME boundaries, encodings, or line endings.
A forwarding workflow alters the message in a non-DKIM-safe way.
An application adds headers covered by the signature after a local signer runs.

The c= tag in the signature defines canonicalization. relaxed/relaxed is commonly used because it tolerates some harmless whitespace changes better than simple/simple, but it cannot protect against substantive content changes. The operational fix is usually to sign as late as possible—after the final message transformation—or configure downstream systems not to alter signed content.

The sender uses weak or unsupported cryptography

Modern DKIM deployments should use SHA-256-based signing. RFC 8301 updates DKIM algorithm guidance and deprecates rsa-sha1; it also raises the operational floor by requiring verifiers not to treat RSA keys shorter than 1,024 bits as valid. RSA keys in the 1,024- to 2,048-bit range remain common, while Ed25519-SHA256 is also standardized for DKIM.

Do not change algorithms solely to fix a DNS verification badge. Use the key type and record format supplied by your sender, and update old self-hosted signing configurations when headers show obsolete algorithms such as a=rsa-sha1.

Know what SMTP and API responses can—and cannot—tell you

A transactional email system commonly returns an immediate response when it accepts your request, not when every recipient has completed DKIM verification.

For SMTP, a response such as this is an acceptance result:

250 2.0.0 Queued

It means the relay accepted the message for processing. It does not prove that DNS verification succeeded, that a DKIM signature was added, or that the recipient will accept the message.

For an HTTP email API, a 200, 201, or 202 response similarly usually means the API accepted or queued the request. The exact response code and JSON schema are provider-specific, so avoid assuming that a generic 202 Accepted confirms deliverability or authentication.

At the recipient side, a persistent SMTP rejection might appear as something like:

550 5.7.26 This mail has been blocked because the sender is unauthenticated

That type of reply can indicate that both SPF and DKIM failed for a message path, but the complete bounce text matters. A DKIM issue does not always create an SMTP rejection; it may instead affect spam placement, reputation, or DMARC evaluation.

Treat the evidence in this order:

API or SMTP acceptance proves only that your sending service accepted the submission.
Delivery events or SMTP bounces show recipient-level acceptance or rejection.
Full message headers show whether DKIM, SPF, and DMARC passed.
DNS lookups show whether the relevant public record is available.

A practical 15-minute DKIM troubleshooting checklist

Use this checklist when a DKIM record will not verify. It intentionally moves from the most objective evidence to the more complex causes.

Copy the exact DNS hostname and expected record value from the active sending configuration.
Confirm whether the required type is TXT or CNAME.
Check that the selector hostname is exactly selector._domainkey.signing-domain.
Make sure the DNS interface did not append the domain twice.
Check for an old TXT record where a CNAME must exist, or a CNAME where a TXT record must exist.
Query the full hostname with dig +short TXT and, if relevant, dig +short CNAME.
Query at least two public resolvers to identify cache differences.
Verify you edited the zone served by the domain's authoritative nameservers.
Confirm that p= is nonempty for a direct TXT key and that no whitespace was added inside the key.
Wait through the old TTL after replacing an existing record.
Retry the provider's DNS verification process.
Send a fresh production-like message.
Inspect DKIM-Signature for its d= and s= values.
Inspect Authentication-Results for dkim=pass and dmarc=pass.
If DNS passes but mail fails, examine key rotation, multiple senders, and post-signing message changes.

This sequence prevents a common loop: changing DNS repeatedly when the real issue is that the application is still sending through another service or signing with a different selector.

Prevent the next DKIM verification outage

DKIM is easier to operate when it is treated as production infrastructure rather than a one-time domain setup task.

Maintain an inventory of every system that can send mail using your domain: product notifications, password resets, support desk messages, invoices, CRM campaigns, employee mail, status alerts, and third-party forms. Record the From domain, envelope domain, DKIM signing domain, selector, DNS record type, and owner for each system.

Use distinct, descriptive selectors instead of reusing a vague selector such as default across unrelated systems. Names such as app1, support, workspace, or tx2026q1 make header investigations and staged key rotations much easier.

Before a DNS migration, export the zone and specifically audit _domainkey records. Before changing email providers, add the new provider's selector without deleting the prior one. Before enabling a footer, link rewriting appliance, or outbound security gateway, retest DKIM after the message has travelled through the full route.

Finally, monitor more than a setup screen. Periodically send a test to a controlled mailbox or a service such as mail-tester, inspect authentication headers, and review DMARC aggregate reports when available. A record that verified once can later fail because of a DNS migration, expired provider configuration, key rotation, or a newly introduced sending path.

FAQ

Why does my DKIM record still not verify after I added it?

First query the exact selector._domainkey.domain hostname publicly. The usual causes are the wrong record type, a doubled domain in the host field, a typo in the selector, a stale conflicting record, editing DNS at a non-authoritative provider, or resolver caching after a replacement.

How long does DKIM verification take after changing DNS?

It depends on the old TTL, DNS provider update time, and recursive resolver caches. A new record can appear quickly, but a replaced record may continue returning old data until cached answers expire. Verify with public DNS queries instead of relying only on elapsed time.

Can I have more than one DKIM record for the same domain?

Yes. You can publish multiple DKIM records for different selectors, which is normal when multiple systems send mail or when rotating keys. You cannot publish a TXT record and CNAME record at the same exact selector hostname.

My DKIM lookup works, but email still says `dkim=fail`. What now?

Read the message's DKIM-Signature header. Confirm that its d= domain and s= selector match the record you tested. Then investigate mismatched private and public keys, outdated senders, and gateways that modify content after it is signed.

Does a successful SMTP `250` response prove DKIM works?

No. 250 means the SMTP server accepted the message for processing. Confirm DKIM by inspecting the delivered message's Authentication-Results header for dkim=pass, then check DMARC alignment as well.

DKIM Record Won’t Verify? A Practical DNS Troubleshooting Guide