How can DKIM selector errors create intermittent failures?

You've set up DKIM, everything looks fine, and then a chunk of your emails fail authentication while others pass. No pattern, no warning. That's the classic fingerprint of a DKIM selector mismatch, and it's one of the trickiest authentication problems to pin down because it doesn't fail consistently.

Here's the quick version of how DKIM works. When your server signs an outgoing email, it stamps the message with a DKIM selector name inside the signature header (it looks like s=myselector). The receiving server then goes to your DNS, looks up that selector as a TXT record (something like myselector._domainkey.yourdomain.com), grabs the public key, and checks the signature. If the selector named in the header doesn't exist in DNS, verification fails. Full stop.

The reason failures go intermittent rather than total is usually one of these four situations.

Key rotation gone wrong. You rotated to a new DKIM key and updated your signing config, but you removed the old DNS record before all messages signed with the old key had been delivered. Emails in transit still carry the old selector in their header. The receiving server looks it up, finds nothing, and DKIM fails. Always keep the old DNS record live for at least 48 to 72 hours after you stop signing with the old key.

Multiple sending paths with different configs. If you send through more than one system (say your ESP handles marketing emails and your own servers handle transactional ones), each path might sign with a different selector. If one of those selectors was never added to DNS, or was added incorrectly, that stream fails while the other passes. This is especially easy to miss if you use separate sending streams and set them up at different times.

Load balancer routing inconsistency. Some sending setups route messages through multiple servers behind a load balancer. If those servers aren't all using the same signing configuration, the message that lands on Server A gets signed correctly, but the one routed to Server B uses a selector that doesn't match what's in DNS.

DNS propagation lag. You just added or changed a DKIM selector record in DNS. Propagation can take anywhere from a few minutes to 48 hours depending on TTL settings. During that window, some resolvers have the new record and some don't, so DKIM passes from one receiving server and fails from another.

How to diagnose it

Pull the full email headers from a failed message. Find the DKIM-Signature header and note the s= value. That's the selector the sending server used. Then look up whether that TXT record actually exists in DNS. You can do it from the command line (dig TXT myselector._domainkey.yourdomain.com) or with a free lookup tool.

And the mismatch will be obvious. Either the record doesn't exist, the key in DNS doesn't match the private key the server signed with, or the record exists but has a typo. Compare what's in the header against what's in DNS and that's usually the whole story.

Don't just check one failed message though. Check a few, from different sending paths if you have them. If different messages show different selector names, you've found the source: inconsistent signing configs across your infrastructure.

How to fix it without breaking live sends

Now if you're rotating keys, publish the new selector in DNS first and wait for propagation before you switch your signing config over. Then leave the old selector in DNS for a few days before removing it.

If multiple systems are sending on your behalf, audit every one of them. Check the selector each uses, then verify every selector is published correctly in your DNS. If you're unsure, our free DKIM Record Lookup can show you exactly what's in DNS for any selector you enter.

If the problem is still unclear after checking headers and DNS, grab the raw source from a failed message and run it through our Source Analyzer. It parses the full authentication chain and flags exactly where things broke. And if you're mid-crisis and nothing makes sense, the SOS hotline is free. We'll walk through your headers with you.