DKIM is a cryptographic signature on your outbound email that proves it came from your domain and was not altered in transit. How it works, step by step.
DKIM is a digital signature added to every email your domain sends. The sending server signs the message with a private key; the receiving server looks up the matching public key, published in your DNS, and checks the signature. If it verifies, two things are proven: the message really came from your domain, and it was not altered in transit. DKIM does not check the sending server's address, that is SPF, and it does not decide what to do on failure, that is DMARC. For cold email, DKIM is mandatory: unsigned mail from a domain looks unauthenticated and gets filtered. For setup steps, see our SPF DKIM DMARC setup guide.
DKIM (DomainKeys Identified Mail) is an email authentication method in which the sending server attaches a cryptographic signature to each outgoing message using a private key. The receiving server retrieves the corresponding public key from a DNS record and verifies the signature, confirming that the message originated from the stated domain and that key parts of it were not modified after sending.
Two things at once. First, origin: the message was signed by a server that holds your domain's private key, so it genuinely came from your domain's mail system. Second, integrity: the signed portions of the message, typically the body and important headers like From, Subject, and Date, were not changed between sending and delivery. If a mail relay or an attacker altered a signed header or the body, the signature no longer matches and DKIM fails.
What DKIM does not do: it does not encrypt the email, so the contents are still readable in transit; it does not verify the sending IP address; and it does not tell the receiving server what to do if the check fails. It is a proof of authenticity for the message, nothing more. See cold email deliverability guide.
For cold outreach, DKIM matters because receiving providers treat a valid signature as a strong trust signal and unsigned bulk-style mail as a weak one. A domain sending cold email without DKIM is starting from a deficit. See how to set up cold email infrastructure.
The private key never leaves your infrastructure, which is what makes forgery hard: an attacker would need your private key to produce a valid signature. See our setup guide for how to publish the public key correctly.
The public key is published as a TXT record (or a CNAME that points to one, if your provider hosts the key). At selector1._domainkey.yourdomain.com you might have a value like v=DKIM1; k=rsa; p=MIGfMA0GCSq... where p= is the long public key string.
The most common DKIM mistake is a broken p= value: pasted with line breaks, truncated, or with a stray space. DKIM keys are long, and a single wrong character makes every signature fail verification. Paste exactly what your provider supplies, as one unbroken string. See the common errors section of our setup guide.
DKIM on its own passes if any valid signature verifies, even one added by your email provider using the provider's own domain. That is a technical pass, but DMARC adds a stricter requirement called alignment: the domain in the DKIM signature must match the domain in the visible From address.
For cold email, this means you should set up domain-aligned DKIM: sign with your sending domain's own key, not just rely on your provider's shared signing domain. Provider-signed-only DKIM can pass DKIM but fail DMARC alignment, which weakens delivery. Most providers offer a "custom domain DKIM" or "authenticated domain" setup for exactly this.
Two operational details decide how strong your DKIM actually is over time.
Key length. DKIM keys are RSA keys, and the current standard is 2048-bit. Older setups sometimes still use 1024-bit keys, which are considered weak by modern standards and which some providers now flag. If your DKIM key is 1024-bit, regenerate it at 2048-bit. The only historical reason to use 1024 was a DNS record-size limit that most providers have long since worked around by splitting the record.
Key rotation. A DKIM private key that never changes is a long-lived secret. Best practice is to rotate DKIM keys periodically, every few months to once a year, so that a key compromised at some point in the past cannot be used indefinitely. This is where selectors earn their keep: you publish a new key at a new selector, switch signing to it, confirm mail still passes, then remove the old selector's record after a grace period so any in-flight mail signed with the old key still verifies. Many managed sending platforms handle rotation automatically; if yours does not, put it on a calendar.
Neither of these changes what DKIM does day to day, but both affect how a receiving provider scores your domain and how exposed you are if a key ever leaks. See how to set up cold email infrastructure and cold email deliverability guide.
No, and this is a common misread. DKIM proves a message was signed by a particular domain and not altered. It says nothing about whether that domain, or its owner, is honest.
A spammer can register a throwaway domain, set up perfectly valid DKIM on it, and send signed spam all day. Their mail passes DKIM. What DKIM gives receiving providers is not a trust verdict but a reliable identity: it lets them attach reputation to a real, verified domain rather than to a forgeable From header. A domain that consistently sends signed mail that recipients complain about builds a bad reputation, and DKIM is what makes that reputation stick to the right party.
So DKIM is a prerequisite for a reputation system, not a trust badge. For your own domain, that is exactly why you want it: it ensures the good reputation you build from clean, wanted mail actually accrues to you and cannot be diluted by someone spoofing your name. Combined with DMARC, it also stops that spoofing at the door. See cold email deliverability guide.
The Tamper-Evident Seal: DKIM is a wax seal on an envelope. It proves who sealed it and shows immediately if anyone opened or altered the contents on the way. It does not hide what is inside.
The seal analogy captures both what DKIM guarantees and what it does not. A wax seal with your crest proves the letter came from you and that the envelope was not tampered with, because breaking the seal is obvious. It does not encrypt the letter; anyone who opens it can read it. And it does not tell the recipient what to do if the seal is broken; they decide that themselves, or follow a rule you gave them separately.
DKIM is the same. The signature proves origin and integrity. The message is still plain text in transit. And the "what to do on a broken seal" decision belongs to DMARC. This is why the three records are always discussed together: SPF checks the courier, DKIM is the seal, DMARC is the standing instruction for what happens when a check fails.
The quotable version: "DKIM does not lock your email. It makes tampering with it obvious."
A valid seal on a letter sent to a wrong address still does not get delivered. DKIM makes your mail trustworthy; a clean recipient list makes it deliverable. See how to reduce email bounce rate for cold outreach and what is DMARC.
Valid DKIM proves your email is authentic. It does nothing about whether the address exists. Bounces from a stale list still erode the domain reputation your DKIM setup is protecting.
InboundLabs is a sales intelligence platform built on a database of 280M verified B2B contacts with 98% email deliverability on verified contacts. It lets you filter by industry, headcount, region, and title, so your signed mail reaches real inboxes and its reputation compounds. Monthly plans, no annual lock-in. Free to start, no credit card required.
See how InboundLabs finds verified contacts instantly → inboundlabs.app
DKIM adds a cryptographic signature to your outbound mail that proves it came from your domain and was not altered on the way. The private key stays on your server; the public key goes in DNS at a selector subdomain. Paste the key value exactly, set up domain-aligned signing so it also satisfies DMARC, and verify a Gmail test shows DKIM PASS. DKIM is one of three authentication records, and none of them help if you send to bad addresses.
What is DKIM in simple terms?
DKIM is a digital signature your mail server adds to every email it sends. The receiving server checks that signature against a public key you publish in DNS. If it verifies, the email is confirmed to have come from your domain and to have arrived unaltered.
What is the difference between SPF and DKIM?
SPF checks whether the sending server's IP address is authorized for your domain. DKIM checks whether the message itself was signed by your domain and not modified in transit. SPF validates the courier; DKIM validates the sealed letter. You need both, plus DMARC.
Do I need DKIM for cold email?
Yes. Receiving providers treat a valid DKIM signature as a strong trust signal and unsigned bulk-style mail as suspicious. A domain sending cold email without DKIM starts at a disadvantage and is more likely to be filtered to spam.
Why is my DKIM failing?
Usually the published public key is wrong: pasted with line breaks, truncated, or containing a stray space. DKIM keys are long and unforgiving of a single wrong character. Other causes include a mail relay altering a signed header, or the DNS record not having propagated yet.
What is a DKIM selector?
A selector is a label in the DKIM DNS record path, like selector1._domainkey.yourdomain.com. It lets a domain publish multiple DKIM keys at once, one per sending service, so your marketing tool and your cold email tool can each sign with their own key without conflict.
Does DKIM encrypt my email?
No. DKIM signs the message so tampering is detectable, but the contents remain readable in transit. Encryption in transit is handled separately by TLS between mail servers. DKIM is about authenticity and integrity, not confidentiality.
LSI keywords: DKIM, DomainKeys Identified Mail, cryptographic signature, public key, private key, DKIM selector, message integrity, email authentication, DKIM alignment, DKIM-Signature header, SPF, DMARC
Yahoo sender requirements mirror Gmail's, with one sharper edge: Yahoo rejects non-compliant bulk mail outright instead of foldering it.
Google bulk sender requirements apply at 5,000 emails a day, but the thresholds that filter you apply to everyone. The full 2026 checklist.
How to get off an email blacklist: fix the root cause first, then request delisting. Skip the fix and you get relisted, often faster.
No commitment. No credit card. Just 50 free verified contact lookups.