dkim=fail (no key for signature)

What you are seeing

• dkim=fail (no key for signature) header.i=@example.com
• dkim=permerror (no key for signature)
• DKIM-Signature: no key available at selector._domainkey.example.com

Why it happens

The DKIM record was never published

Generating a key in the provider's console does not publish it. The TXT or CNAME still has to be added at your DNS host, and signing usually has to be switched on afterwards.

The host name was entered with the domain appended twice

Many DNS panels append the zone automatically. Entering `google._domainkey.example.com` creates `google._domainkey.example.com.example.com`. Enter only `google._domainkey`.

The CNAME target is wrong or the delegation is broken

Microsoft 365 and most ESPs publish the key behind a CNAME. If the target is mistyped, or the provider has not finished provisioning, the chain resolves to nothing.

The selector rotated

Providers rotate selectors. Microsoft 365 alternates between `selector1` and `selector2`, so both CNAMEs must exist permanently or every rotation breaks DKIM.

The record was split or truncated

A 2048-bit key exceeds the 255-character limit of a single TXT string and must be published as multiple quoted strings in one record. Some panels mangle this and produce an unparseable key.

How to fix it

1. 1Read the selector off a real message. Open a message you sent, view the original, and find `s=` and `d=` in the DKIM-Signature header. Those two values tell you the exact name that must resolve.
2. 2Check what is published. Run the check above with that selector. MailVakt probes your providers' known selectors first, then a wider dictionary, and reports missing, revoked, weak and testing-mode keys.
3. 3Fix the host name, then wait for TTL. Re-add the record with the bare host name. DNS caches the negative answer, so allow up to the TTL of the zone before re-testing, and use a fresh check to skip our cache.
4. 4Publish both selectors for Microsoft 365. Add `selector1._domainkey` and `selector2._domainkey` as CNAMEs, then enable signing for the domain. Leaving one out works until the first rotation.
5. 5Confirm signing is actually enabled. A published key with signing turned off means no DKIM-Signature header at all, which reports as `dkim=none` rather than a key failure. Both need to be true.

Questions

Where do I find my DKIM selector?

In the `s=` tag of the DKIM-Signature header of a message you sent, or in your provider's DKIM settings page. Common values are `google`, `selector1`, `s1`, `k2` and `mail`.

I added the record but it still fails.

Check the record name for a duplicated domain suffix, confirm the key is one record rather than two, and allow for DNS TTL. Negative answers are cached, so a correct record can still fail for a while.

Should my DKIM record be a TXT or a CNAME?

Whatever your provider asks for. Google Workspace gives you a TXT; Microsoft 365, SendGrid and Mailchimp give you CNAMEs so they can rotate the key for you.

Is a 1024-bit key still acceptable?

It verifies, but 2048-bit is the current recommendation. Keys under 1024 bits are rejected by major receivers.