DKIM says failed but your DNS looks right — it's probably the selector
SPF green, DMARC green, DKIM red — on a domain where you can see the key published. Nine times out of ten you published a real key under the wrong selector, and every checker will keep telling you it's fine.
This is one of the most frustrating states in email setup: your provider says DKIM is not verified, SPF and DMARC both pass, and when you look up your DNS the DKIM key is right there. Every public DKIM checker you paste the domain into agrees the record is valid.
They are all correct. And the mail still is not signed the way your sender expects.
What a selector actually is
DKIM keys do not live at your domain root. They live under a selector, at <selector>._domainkey.yourdomain.com. The selector is a label that lets one domain publish many keys at once — one for your mailbox host, one for your invoicing system, one for your marketing platform.
That is the whole trap. A domain can legitimately have several valid DKIM keys, and a checker that finds a key will happily tell you DKIM is configured. But signature verification is not "does this domain have a key". It is:
- The sending system signs the message and stamps the selector it used into the header:
DKIM-Signature: … s=zc1; d=yourdomain.com. - The receiver reads that selector, looks up
zc1._domainkey.yourdomain.com, and verifies against that key.
If your sender signs with zc1 and the only key you published is under smtp, the receiver looks up zc1._domainkey, finds nothing, and fails the signature. Meanwhile smtp._domainkey sits there being perfectly valid and completely irrelevant.
Why this happens so often
Because the wrong key is usually a real key that something else put there for a good reason.
If your mailboxes are hosted somewhere — a webmail provider, Microsoft 365, a hosting company — that provider almost certainly set up DKIM for its own outbound mail, under its own selector. You then add a marketing or transactional sending platform, see "DKIM" already in your DNS, and reasonably conclude it is done.
It is done for your mailbox provider. It is not done for your new sender. The two are separate signatures with separate selectors, and they do not substitute for each other.
How to diagnose it in two minutes
Send yourself one real message through the sender that is failing, then read the raw headers. In Gmail: Show original. Look for:
DKIM-Signature: v=1; a=rsa-sha256; s=zc1; d=yourdomain.com; …
The s= value is the selector your sender is actually using. That is the ground truth — not what your DNS panel shows, not what a checker says. Now look up that exact name:
dig +short zc1._domainkey.yourdomain.com TXT
dig +short zc1._domainkey.yourdomain.com CNAME
Empty output is your answer. Publish the record your sender told you to publish, under the selector it signs with, and the signature verifies.
A useful sanity check while you are in the headers: Authentication-Results will say dkim=fail or dkim=none — and none specifically means "no signature to check for that selector", which is a different problem from a signature that failed cryptographically.
The bit that makes it worse: DMARC
If DKIM is failing and your DMARC policy is p=quarantine or p=reject, you are not just missing a signature — you are actively instructing mailbox providers to distrust the mail.
DMARC passes when SPF or DKIM passes and aligns with the From domain. So a broken DKIM alone is survivable if SPF aligns. But the combination people hit is: SPF aligned via one path, DKIM failing, DMARC set to reject, and a sending platform whose envelope sender is not their own domain — at which point alignment fails on both counts and the mail goes to spam or nowhere.
The order that works: publish the key, verify the signature on a real message, then tighten DMARC. Hold at p=none while you are still fixing authentication. p=none still collects reports; it just does not punish you for a setup that is not finished.
What good tooling should tell you
A verification check that returns a red cross and nothing else is close to useless here, because the failure and the fix are not visible from the same place. "Not verified" is true for at least four different reasons — no record at all, a record under a different selector, a CNAME pointing at the wrong target, or the sending platform's own key host being unreachable — and only one of those is something you can fix in your DNS panel.
That last one matters more than it sounds. If the failure is on the platform's side, a checker that phrases everything as your mistake will send you rummaging through DNS you never needed to touch.
WeZend's domain verification returns a machine-readable reason alongside each check, plus a human hint — so wrong_selector tells you which selector you published under and which one we sign with, and esp_target_unresolved says plainly that the problem is ours. See Email: domains, DNS & sending for the response shape, or run any domain through the free SPF, DKIM & DMARC checker.
The short version
- A valid DKIM key in your DNS does not mean the right key for the sender you are debugging.
- The
s=value in a real message'sDKIM-Signatureheader is the only selector that matters. digthat exact<selector>._domainkeyname. Empty means found it.- Fix authentication before tightening DMARC, not after.