How to Fix DKIM Not Verified

In 2024, Google and Yahoo required bulk senders, defined by Google as domains sending 5,000 or more messages a day to Gmail addresses, to authenticate with DKIM. If your platform shows DKIM not verified, or Gmail later shows dkim=fail, the message has less proof that it really came from your domain.

In practice, this is usually a setup problem, not a mystery. The fastest fixes are checking the selector, confirming the DNS host name, publishing the right record type, and making sure signing is actually enabled in the ESP or MTA after DNS is live.

Below is the decision path most teams use to fix it quickly, test it, and avoid learning about the problem after a campaign has already gone out.

First, identify which DKIM problem you actually have

People use "DKIM not verified" for two different situations. One happens before you send, when your ESP cannot confirm the DNS record. The other happens after you send, when Gmail, Yahoo, or Outlook sees a broken or missing signature in the message headers. The fix depends on which one you are dealing with.

Related reading: dkim vs spf and spf and dkim deliverability.

If you want a quick outside-in check before you change anything, run a test send and check public DNS and message authentication in a deliverability test. That helps separate a DNS publishing issue from a signing issue fast.

The checks that fix most DKIM verification failures

1. Confirm the selector is exactly right

A DKIM record lives at a selector, not just at the root domain. If your ESP says the selector is s1, the record usually belongs at something like s1._domainkey.example.com. If you publish the key at default._domainkey or at the root by mistake, verification will fail even if the public key itself is correct.

This is the most common mismatch when multiple tools are involved, for example marketing email from one ESP and product email from another. Each sender can use a different selector, so copying the right key into the wrong selector still produces a miss.

2. Check the host name your DNS provider expects

DNS UIs handle host names differently. Some want only the left-hand label, like s1._domainkey. Others want the full name, like s1._domainkey.example.com. If you enter the full name into a UI that automatically appends your domain, you can accidentally publish s1._domainkey.example.com.example.com.

That mistake looks harmless in the DNS panel, but the ESP will not find the record. Query the exact fully qualified domain name and confirm it resolves publicly, not just inside your DNS dashboard.

3. Publish the record type your sender requires

Some platforms verify DKIM with a CNAME that points to their managed key. Others expect a TXT record that contains the public key directly. If the platform asks for CNAME and you publish TXT, or the reverse, you will keep seeing not verified.

This matters a lot when teams reuse a checklist from another tool. A self-hosted MTA often uses a TXT public key. Many SaaS senders use CNAME-based DKIM so they can manage rotation for you. The right move is simple, publish exactly the type the sending platform gave you, with no substitutions.

4. Fix TXT formatting and copy-paste errors

For TXT-based DKIM, the value normally starts with v=DKIM1; k=rsa; p= followed by a long public key. One missing character, a smart quote, an extra space inside the key, or a broken line wrap can stop verification.

Common formatting problems include:

• Adding quotes that your DNS provider does not need
• Removing quotes when your DNS provider expects long TXT values to be split into quoted strings
• Accidentally pasting a private key instead of the public key
• Leaving off the p= value entirely
• Publishing a truncated 2048-bit key because the DNS UI wrapped it badly

If you are using a 2048-bit key, pay extra attention to how your provider stores long TXT records. Some UIs display the value as multiple strings, which is normal, but the authoritative response should still reconstruct into one valid DKIM key.

5. Remove duplicate or conflicting records

Each selector should resolve to one clear DKIM answer. If the same selector returns multiple TXT records, or a stale TXT record plus a newer CNAME, different resolvers can behave in inconsistent ways. That is how one tool says verified while another still fails.

This often happens during migrations. A team moves from one ESP to another, adds a new DKIM record, but never removes the old one. Before you assume propagation is slow, make sure the selector returns only the record the active sender expects.

6. Wait for propagation, then check authoritative DNS

Some DNS changes appear in your own lookup tool before they are visible to the rest of the internet. If you just published the record, respect the TTL and test again against the authoritative nameserver or a public checker.

Do not stop at your DNS provider's preview. Your ESP verifies from the public internet, and Gmail or Yahoo will do the same. A quick retest after propagation saves a lot of unnecessary editing.

7. Make sure signing is enabled on the actual sending path

It is possible for DNS to be perfect and for mail to still leave unsigned. This happens when the sending domain is verified in the ESP, but the specific stream, subaccount, dedicated IP pool, or MTA that is sending has not been configured to sign with that selector.

If you send marketing email through one vendor and lifecycle or product email through another, check both paths. You want to see a real DKIM-Signature header on the live message, not just a green check inside an admin panel.

How to confirm the fix before you send again

Once the DNS record looks right, send a message to a Gmail inbox and inspect the original headers. Gmail will usually show whether DKIM passed and which domain signed the message. For Yahoo and Outlook, use the full headers in the received message and look for dkim=pass or dkim=fail in the authentication results.

You are looking for three things:

• A visible DKIM-Signature header
• The selector and signing domain you expected
• An authentication result of pass, not just a record that exists in DNS

Before a larger send, it is worth doing one more outside test to verify the signature path before you ramp volume. That gives you evidence from the recipient side, which is more useful than trusting the ESP alone.

If DNS verifies but Gmail still shows dkim=fail

When the record is published correctly and verification still fails at the mailbox provider, the message is usually being changed after it is signed, or the wrong domain is signing the mail.

Message changed after signing

Security gateways, footers added by downstream systems, or internal relays can modify the body or headers after DKIM signing. Even a valid key cannot help if the signed content no longer matches what the recipient receives. This is worth checking in complex B2B stacks where outbound mail passes through more than one hop.

The wrong domain is signing

Your ESP might sign with its own domain instead of yours if domain authentication is incomplete or not attached to the active stream. That can still produce a technical DKIM pass, but it will not support your domain identity the way you expect. For Gmail, Yahoo, and Outlook, that difference matters when you are trying to build consistent trust in your sending domain.

No signature on one mail stream only

If campaigns pass and lifecycle mail fails, do not troubleshoot the whole domain at once. Compare one good message with one failing message. The difference is often a single stream, subaccount, or vendor path that was never mapped to the verified domain.

How to keep DKIM verification from breaking again

Once you have fixed the immediate problem, document the selector, record type, sending platform, and the owner of each mail stream. That sounds operational, but it is what prevents repeat incidents during ESP migrations, subdomain launches, or DNS cleanups.

A practical baseline looks like this:

• Use separate subdomains for different mail streams when that fits your setup
• Keep an inventory of selectors and the platforms that use them
• Retest authentication after DNS changes, vendor changes, or key rotation
• Check live headers periodically, not just the ESP dashboard
• Remove stale selectors when a sender is retired

For RevOps and lifecycle teams, this is the real win. You move DKIM from a one-time setup task to an observable control point, so you know what changed before inbox placement shifts.

Run your first deliverability test with Mailora, then confirm the fix on the recipient side before your next send.

FAQs

How long does DKIM verification take after I publish DNS?

It depends on TTL and resolver caching. Some records verify in minutes, others take a few hours. Check the authoritative DNS response before assuming the setup is wrong.

Can I have more than one DKIM selector on the same domain?

Yes. Many teams use different selectors for different senders or for key rotation. The important part is that each selector resolves cleanly to the record that sender expects.

Why does my ESP say DKIM is verified but Gmail still shows dkim=fail?

Your DNS record is probably correct, but the message is being altered after signing, or the wrong sending path is being used. Inspect the live headers, not just the DNS setup.

Should I use 1024-bit or 2048-bit DKIM keys?

Most teams should use 2048-bit keys unless a specific provider limitation forces 1024-bit. Just make sure your DNS provider handles long TXT values correctly.

Does Apple Mail care about DKIM?

Apple Mail is a client, not the mailbox provider making the main authentication decision. The important checks usually happen at Gmail, Yahoo, Outlook, and other receiving systems before the message is displayed.