Your DKIM key is not in DNS

Which failure you have

Read the exact wording in the failure report, because it splits the problem cleanly in half and the two halves have nothing in common.

This page is about the first three. The last one is a different animal and the end of this page says what little can be said about it honestly.

Finding the name to look up

DKIM keys do not live at your domain. They live at <selector>._domainkey.<domain>, and the selector is chosen by whoever signs your mail. You do not have to guess it: it is in the message itself. Open the raw headers of a message that failed, find the DKIM-Signature header, and read the s= tag. That is the selector, and d= beside it is the domain.

A selector of s=google on d=example.com means the name to check is google._domainkey.example.com. Put that exact hostname into a DNS lookup — the whole thing, not the bare domain. Looking up the domain alone is the most common wasted step here, because the key is never there.

Reading what comes back

Our lookup prints a TTL beside A and AAAA rows only, so a DKIM record — always TXT or CNAME — comes back without one; your DNS panel is where to read the TTL you set. Nothing at all means the record was never published, or was published at the wrong name. Compare the hostname you just queried, character by character, against what your mail provider told you to create. The usual slip is a provider that gives you the selector alone and a DNS panel that appends your domain automatically, so the record lands at google._domainkey.example.com.example.com.

A CNAME rather than a TXT is normal and is not a fault. Several providers have you point the selector at a name they control so they can rotate keys without touching your zone. Our lookup returns both TXT and CNAME, and it accepts the underscore in the name, so you will see which shape you have.

A TXT record that comes back visibly cut off is the third case. A single DNS string cannot exceed 255 characters, and a 2048-bit DKIM key is longer than that, so the record has to be published as several quoted strings that resolvers join back together. Panels that accept one long value and silently truncate it produce a record that exists, looks plausible, and cannot verify. If what you see ends mid-key, that is the fault.

Things that look like DNS and are not

If the record is present and correct and signatures still fail, two causes remain on the DNS side. A key that was rotated at the provider but not updated in your zone will be found and will not match. And a record you added minutes ago may still be hidden by the answer that came before it: a resolver that asked while the name did not exist cached that absence, and goes on reporting nothing until the negative cache expires. That is usually minutes rather than hours, and nothing you do shortens it.

Past that, it stops being a DNS question. body hash did not verify means the key was found, the signature was read, and the message body did not match what was signed — something altered it in transit. Mailing lists that append a footer are the classic cause; so are some scanning gateways. That is a mail-path problem and this site does not run mail servers, so take it to whoever does.

Where DKIM sits

DKIM is one of the three records that decide whether your mail is trusted. SPF says which servers may send for your domain, DKIM proves a message was signed by you, and DMARC at _dmarc tells a receiver what to do when neither vouches for a message. All three are TXT records, and all three are easy to lose in a move — if DKIM broke at the same moment as everything else, see what happens to email when nameservers change.