What is DKIM?
DKIM is the part of email authentication that proves a message was signed by a domain that controls a private key. It does not encrypt the message and it does not tell you whether the sender is honest on its own. What it does is give the receiver a way to verify that important headers and the signed body were not altered after the message left the signing system.
That is why DKIM matters so much in the same conversations as SPF and DMARC. SPF tells receivers whether an IP was allowed to send. DKIM tells them whether the signed content still matches what the signer sent. DMARC then decides whether one of those authenticated identities aligns with the visible From domain. If you want to inspect that chain on a live domain, the quickest route is the CyberFurl DKIM lookup.
How DKIM works (sign → publish → verify)
A real DKIM flow is simpler than it first looks. The sending platform chooses which headers to sign, computes hashes, signs those values with its private key, and adds a DKIM-Signature header to the message. That header includes the signing domain in d= and the selector in s=.
When the message reaches the receiving server, the receiver builds the same canonicalized view of the signed content, fetches the public key from selector._domainkey.example.com, and verifies the signature. If the header list changed, if the body hash no longer matches, or if the DNS key is missing or malformed, validation fails. That is why a domain can have a DKIM record in DNS and still fail DKIM in real delivery.
DKIM selectors explained
Selectors exist so one domain can publish more than one DKIM public key at the same time. That matters when different providers sign different mail streams, when you are rotating keys, or when you want to retire one vendor without breaking another.
Operationally, a selector is just the left-hand label that sits before ._domainkey. A message signed with s=mailgun will cause the receiver to look up mailgun._domainkey.example.com. Good selector naming is less about aesthetics and more about safe change management: it should be obvious which provider or mail stream owns the key.
Key strength: 1024-bit vs 2048-bit
This choice is no longer just academic. Older deployments often still carry 1024-bit RSA keys because they were easier to fit into DNS or because a provider never forced an upgrade. Modern guidance is moving toward 2048-bit keys where providers and DNS infrastructure support them reliably.
The practical rule is simple: use 2048-bit keys for new setups unless your platform has a documented limitation, and verify that your DNS provider publishes the record cleanly without truncation or formatting errors. If a legacy provider still insists on 1024-bit keys, treat that as technical debt and track when it can be removed.
DKIM rotation best practices
Key rotation is where mature DKIM programs separate from checkbox deployments. The safe pattern is to publish a new selector, switch the sender to sign with that new selector, confirm that receivers are validating it, and only then retire the old key.
Teams get into trouble when they delete the old record too early, forget which provider owns which selector, or rotate keys without checking real signed mail afterward. Rotation should be routine enough that an employee change, vendor offboarding, or suspected compromise does not turn into a high-risk one-off project.
Common DKIM failures (signature, body hash, expired)
When DKIM fails, the reason is usually mundane rather than mysterious. A provider may be signing with the wrong domain, the public key may not match the private key in use, the body may have been modified in transit, or the selector may have been removed during a rushed cleanup.
Forwarders and mailing lists are classic failure points because they often rewrite content after the original sender signed it. Receivers also fail validation when DNS is stale, split across providers, or published with formatting issues. The fix is almost always to look at a real signed message, inspect the exact DKIM-Signature header, and then compare that evidence with the live DNS record instead of guessing.
How to publish a DKIM record (HowTo)
Publishing DKIM safely starts with knowing which system is doing the signing. Before you add anything to DNS, confirm the signing domain, the selector name, and the key size your provider expects. Then publish the TXT record exactly where the provider specifies, validate the record publicly, and only after that send test mail through the real production path.
The checklist below is the part most teams skip: verify actual signed messages after the DNS record is live. A record that exists is not the same thing as a sender that signs correctly.
- 1
Baseline DKIM on the live domain
Start by reading the exact DNS records, headers, or transport signals involved in DKIM so you know whether the domain is merely configured or actually aligned with production traffic.
- 2
Publish or correct the control safely
Implement the smallest change that improves DKIM without breaking legitimate senders, forwarders, or receiving paths. For email controls, staged rollout matters more than fast rollout.
- 3
Validate behavior end to end
DKIM and DMARC alignment
DKIM by itself proves that a domain signed the message, but DMARC decides whether that signing domain aligns closely enough with the visible From domain to count as authenticated for policy. That distinction matters because a message can pass DKIM and still fail DMARC if the signer is on a different domain or subdomain than the one the user sees.
This is why DKIM and DMARC should always be reviewed together. If the domain is trying to move from p=none to enforcement, alignment mistakes are often the reason a rollout stalls. CyberFurl is most useful here when you review the DKIM result, the DMARC policy, and the visible sender identity in the same workflow.
Tools to check your DKIM
The fastest way to turn this from theory into evidence is to run the CyberFurl DKIM lookup and compare that result with the domain's broader email authentication posture. If you are debugging a live sender, pair it with SPF, DMARC, and the public security report so you can see whether the problem is the signature itself or the surrounding trust chain.
Further reading inside CyberFurl
- CyberFurl DKIM lookup
- See the email authentication feature
- DMARC
- SPF
- ARC
- CyberFurl public security report
Standards and references
Frequently asked questions
What is a DKIM selector?
A DKIM selector is the label a mail system puts in the `s=` tag of the `DKIM-Signature` header so receivers know which public key to fetch from DNS. In practice it lets one domain publish multiple active keys, rotate them safely, and separate traffic by provider or mail stream.
How do I find my DKIM record?
Start with the selector your mail platform uses, then query `selector._domainkey.yourdomain.com` for the TXT record. If you do not know the selector, look at a real signed message first. The `DKIM-Signature` header usually tells you both the signing domain in `d=` and the selector in `s=`.