DKIM stands for DomainKeys Identified Mail, and it is the DNS record that proves a cold email actually left your domain unaltered. A private key signs each outgoing message, a matching public key sits in your DNS, and the receiving server checks one against the other before deciding whether to trust the mail.
This page explains what DKIM stands for, how signing and verification work, and walks through the header and record tags with labeled examples. It builds on our SPF, DKIM and DMARC setup guide, which covers the exact click-path for adding all three records; this page goes deeper on DKIM itself.
What does DKIM stand for in cold email?
DKIM stands for DomainKeys Identified Mail, a method defined in RFC 6376 that lets a domain take responsibility for a message by signing it. The RFC keeps the identity of the signer separate from the purported author, which is what lets DKIM keep working through forwarding and most relays.
DKIM does not decide whether mail is spam. It answers one narrower question: was this message sent by someone holding the private key for this domain, and has it been changed since it was signed. That answer then feeds into DMARC, covered in depth on our cold email DMARC policy guide.
How does DKIM work for a cold email sending domain?
DKIM works with a key pair: a private key that signs outgoing mail, and a public key published in your DNS that lets receivers check the signature. Your mailbox provider holds the private key; you publish the public half.
- A key pair is generated for the domain. One private key, one public key, tied to a name called the selector.
- The public key is published in DNS, as a TXT record at
selector._domainkey.yourdomain.com. - Every outgoing message gets signed. The sending server hashes a chosen set of headers and the body, then encrypts that hash with the private key, adding the result as a
DKIM-Signatureheader. - The receiving server looks up the public key using the domain and selector named in that header.
- The receiver re-hashes the message and compares it against what the signature decrypts to. A match means the message passed DKIM; any change to the signed content breaks the match.
Google's DKIM setup guide illustrates the same flow: a private key on the sending server, a public key in a DNS TXT record, and the receiving server fetching that public key to read the signature. The mechanics are identical regardless of which mailbox provider sends the mail.
What does a DKIM-Signature header look like in cold email?
A DKIM-Signature header is a set of semicolon-separated tags attached to every signed email, and five of them matter most for reading one. Here is a labeled example, adapted from the format in RFC 6376 section 3.5:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail;
h=from:to:subject:date; bh=uMixy0Bs...NgUS0s=;
b=LiIvJeRyqMo0gngiCyg...dP+DBZUcsJyS9C+vm2xRK7qyHi=
| Tag | Meaning |
|---|---|
v | DKIM version, always 1 |
a | Signing algorithm, required to be rsa-sha256 under the current standard |
d | The signing domain, the one DKIM is vouching for |
s | The selector, naming which public key in DNS to use |
h | The header fields that were included in the signature |
bh | A hash of the message body |
b | The signature itself, the encrypted hash a receiver checks |
The d= tag matters beyond the signature check itself. For DMARC to pass on DKIM, this domain has to align with the domain in your visible "From" address, not just match somewhere in the sending chain. A cold email domain that signs as itself, rather than as a shared sending platform, gets that alignment automatically.
What does a DKIM DNS record look like for cold email?
A DKIM record is a TXT record published at selector._domainkey.yourdomain.com that holds the public key receivers use to check the signature. A minimal, labeled example:
Host: mail._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA...IDAQAB
| Tag | Meaning |
|---|---|
v | Record version, always DKIM1 |
k | Key type, almost always rsa |
p | The public key itself |
RFC 6376 requires this record to be a TXT record, not a CNAME, though some providers alias it to one behind the scenes. An empty p= value is the documented way to revoke a key: a selector that still resolves but carries no key is read by verifiers as revoked, not as a passing signature.
Pipefire publishes this record automatically for every sending domain it sets up, naming a selector and a 2048-bit key without any manual key generation. The parent SPF, DKIM and DMARC guide covers the full setup order across all three records; our setup page covers what else gets configured before a mailbox can send.
DKIM works alongside DMARC, which tells receivers what to do when a check fails: see what DMARC is and how alignment works.
What is a DKIM selector in cold email, and how do you find yours?
A DKIM selector is the label in front of ._domainkey that tells a receiver which of a domain's possibly several public keys to use. One domain can run more than one selector at a time, for example a different one per mailbox provider or per department.
The selector only shows up in two places: the s= tag in a message's DKIM-Signature header, and the matching DNS record name. There is no way to find it by searching DNS blind, because nothing enumerates every selector a domain might use.
- Send a test email from your sending mailbox to an address you control.
- Open the message and view its full source or headers (in Gmail, the three-dot menu, then "Show original").
- Find the
DKIM-Signatureline and read the value afters=. That is your selector. - Look up
[selector]._domainkey.yourdomain.comas a TXT record to see the published key.
If a domain runs more than one sending tool, each may use its own selector and its own record, all coexisting under the same domain.
Does DKIM key length matter for cold email, and how often should keys rotate?
Key length matters because it sets how hard the private key is to break by brute force, and 2048-bit is the current default for a reason. A 1024-bit key is shorter, loads slightly faster in DNS, and is still accepted by most receivers, but it offers meaningfully less cryptographic margin.
| Key length | Status for a cold email domain |
|---|---|
| 1024-bit | Still works, but offers less protection; avoid for a new domain |
| 2048-bit | The current default for new DKIM setups |
Rotating the key pair periodically limits how much mail a compromised private key could be used to forge, and it is standard hygiene rather than a sign anything is wrong. A domain only being set up for cold email does not need an aggressive rotation schedule, but a key that has been in place for years without being touched is worth refreshing.
What breaks DKIM on a cold email domain?
DKIM breaks when the signed content changes in transit, the public key cannot be found, or the two domains in the signature and the From address stop matching. Four causes cover most real failures:
- The message body or signed headers change after signing. Some relays add footers or rewrite links, which breaks the body hash and fails the signature.
- The selector in the header has no matching DNS record. A typo in the selector, or a record that was never published, leaves receivers with nothing to check against.
- The key was revoked. An empty
p=value is a deliberate revocation, and mail signed with that key now fails cleanly. - The
d=domain does not align with the From address. DKIM itself still passes, but DMARC alignment fails, which is a common, confusing way a message still ends up going to spam despite a technically valid signature.
Checking headers on a real test send catches all four. Our SPF, DKIM and DMARC guide covers the exact steps to view them in Gmail and Outlook.
DKIM for cold email FAQ
What is DKIM in simple terms for cold email?
DKIM is a digital signature added to every outgoing message that proves it came from your domain and was not altered in transit. A private key signs it, and a public key published in your DNS lets the receiver check it.
What does DKIM stand for in cold email?
DomainKeys Identified Mail. The name reflects its origin as a merger of Yahoo's "DomainKeys" and Cisco's "Identified Internet Mail" efforts, now standardized as RFC 6376.
How does DKIM work with SPF and DMARC for cold email?
DKIM and SPF are two separate checks a message can pass, and DMARC reads the result of both to decide what happens to mail that fails. DKIM survives most forwarding, which SPF does not, so setting up both gives DMARC more than one way to pass a legitimate message.
What is a DKIM signature on a cold email?
It is the DKIM-Signature header attached to a signed message, containing the signing domain, the selector, the hashed content, and the encrypted signature a receiver checks against the public key in DNS.
Do I need to generate my own DKIM key for cold email?
Not if your sending platform does it for you. Pipefire publishes a DKIM record with a 2048-bit key for every sending domain it sets up, as part of getting a domain ready to send, with no manual key generation required.