DKIM Records Explained: How DKIM Works & Setup (2026)

A DKIM record publishes the public key that lets receiving mail servers verify your email was genuinely sent by your domain and was not altered on the way. Where SPF checks the sending server’s IP, DKIM adds a cryptographic signature to every message — which is why a valid DKIM record survives forwarding when SPF does not. Together with DMARC, it is one of the three authentication standards Google, Yahoo and Microsoft now require from bulk senders. This guide covers what a DKIM record is, how DKIM works, the DKIM record syntax and selector system, a real DKIM record example, setup, troubleshooting, and best practices.

What is a DKIM record?

DKIM stands for DomainKeys Identified Mail. Your mail server holds a private key and uses it to sign outgoing messages; the matching public key lives in a DKIM record — a DNS TXT record published at a special hostname. When a receiver gets your signed message, it fetches that public key and confirms two things: the message really came from your domain, and its signed headers and body were not changed in transit. DKIM is defined in RFC 6376, with cryptographic updates in RFC 8301.

How DKIM works

Understanding how DKIM works makes every later step obvious:

1. Key pair. You generate a private/public key pair. The private key stays on the signing server; the public key goes into your DKIM record.
2. Signing. For each outgoing message, the server hashes the body and a chosen set of headers, then signs that hash with the private key.
3. Header. The signature and its parameters are added as a DKIM-Signature: header on the message.
4. Verification. The receiver reads the signature’s domain (d=) and selector (s=), fetches the public key from DNS, and recomputes the hashes.
5. Result. If both the body hash and the signature verify, DKIM passes. Any change to the signed content makes it fail.

DKIM record syntax and the selector

A DKIM record is published at <selector>._domainkey.<yourdomain>. The selector is a label you choose (for example s1 or google) that lets you keep several keys live at once — essential for rotation. The signature header points the receiver at the right key with its s= (selector) and d= (domain) tags.

DKIM record example

A published DKIM record example looks like this (the key is truncated):

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

And the matching header that your server adds to each message in this DKIM record example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
    h=from:to:subject:date; bh=2jUSOH9N...; b=Hojae5Ck...

Because a 2048-bit public key is longer than the 255-character limit for a single DNS string, you split the value into multiple quoted strings within one TXT record — never across multiple records.

How to set up a DKIM record

1. Enable DKIM in your sending platform. Most ESPs and mail hosts generate the key pair for you and show you the DNS record (often as a CNAME pointing to their key).
2. Publish the DKIM record at the selector hostname they give you.
3. Use a 2048-bit key where offered (see best practices).
4. Send a test message and confirm the signature verifies.
5. Sign with your own domain (d=yourdomain.com) so DKIM aligns for DMARC.

Troubleshooting a DKIM record

• Body altered in transit. Mailing lists that append footers or change the subject break the body hash, causing DKIM to fail. This is expected behaviour, and it is why DMARC also accepts SPF.
• Missing or wrong selector. If the s= selector has no matching DNS record, verification fails with “no key for signature.”
• Key too short or unrotated. 1024-bit keys are weak; keys that are never rotated are a standing risk.
• DNS string-split errors. A 2048-bit key pasted as one over-length string will be rejected — split it correctly.
• Third-party signs with its own domain. Then DKIM passes but does not align with your From:, so DMARC fails. Configure the provider to sign as your domain.

Canonicalization, algorithms, and CNAME delegation

Two details inside the DKIM-Signature header decide how forgiving your signatures are. The first is canonicalization, set by the c= tag, which controls how the headers and body are normalised before they are hashed. The simple method tolerates almost no change — even an extra space added by a relay can break the signature — while relaxed absorbs benign reformatting such as whitespace and header folding. In practice almost everyone uses relaxed/relaxed, because mail in transit is reformatted far more often than people expect. The second detail is the signing algorithm, set by a=. Modern signatures use rsa-sha256; the older rsa-sha1 is prohibited by RFC 8301 and must not be used.

Ed25519 (RFC 8463) is a newer, much shorter elliptic-curve signature type that solves the 255-character DNS headache and is cryptographically strong at a fraction of the key size. The catch is that not every receiver verifies Ed25519 yet, so the correct approach during the transition is to publish an Ed25519 key and an RSA key under different selectors and sign with both — receivers that understand Ed25519 use it, and everyone else falls back to RSA. This dual-signing pattern is exactly what selectors were designed to make easy.

When you enable DKIM through an email service provider, you will often be asked to add a CNAME record rather than a TXT record. The CNAME points your selector hostname at a record the provider controls, which lets them rotate the underlying key for you without you ever touching DNS again. This is convenient and recommended — but be aware that it means the provider holds the private key and signs as your domain, so only delegate to services you trust, and make sure they are signing with d=yourdomain.com so the result aligns for DMARC.

DKIM and deliverability

Beyond authentication, a valid DKIM signature is one of the strongest reputation signals a mailbox provider has. Because the signing domain is cryptographically proven and survives forwarding, providers attach much of their sender-reputation tracking to the DKIM d= domain rather than to an IP address. That makes your DKIM record the anchor of your long-term sending reputation: keep the same signing domain, sign every message, and your good behaviour accumulates against an identity that follows you even if you change sending platforms or IPs. Skip DKIM, or sign inconsistently, and you forfeit that continuity. For the full picture of how authentication feeds reputation and inbox placement, see our deliverability hub.

DKIM record best practices

• Use 2048-bit RSA keys (the modern baseline; RFC 8301 recommends 2048-bit and prohibits SHA-1). Ed25519 is excellent where supported, but publish RSA too during any transition.
• Rotate keys regularly using selectors — publish a new selector, sign with it, keep the old public key live for a few weeks for in-flight mail, then retire it. Industry guidance suggests rotating roughly twice a year.
• Sign with your organizational domain so the d= aligns with your From address for DMARC.
• Avoid the l= body-length tag, which lets attackers append content below your signature.
• Pair DKIM with SPF and DMARC — see the recommended order in our email authentication hub and the broader deliverability guide.

What a DKIM record does not do

It is just as important to know DKIM’s limits. A DKIM record proves that a message was signed by the holder of the private key and that its signed content was not altered — but it says nothing about who the visible sender is. A spammer can sign their own messages with a perfectly valid DKIM record for their own domain; the signature is genuine, it just is not yours. That is why DKIM alone cannot stop someone from spoofing your brand in the From line. Binding the signature to the address your recipient actually sees is the job of DMARC alignment.

DKIM also does not encrypt your email — the body is signed, not hidden, and remains readable in transit. And a signature does not last forever: the x= expiration tag and the eventual retirement of an old selector both mean a message validated months later may no longer verify, which is normal and expected. Treat DKIM as one instrument in a set: it proves integrity and origin, SPF authorises the sending path, and DMARC ties them to your visible identity and adds policy.

Related reading

• SPF records guide
• DMARC records guide
• BIMI records guide
• MTA-STS guide
• TLS-RPT guide

DKIM record FAQ

Is a DKIM record required?

For bulk senders, yes. Since 2024, Google and Yahoo require senders of about 5,000+ messages a day to authenticate with both SPF and DKIM, and Microsoft has applied the same rule to Outlook consumer mailboxes. For lower volumes it is strongly recommended because it improves deliverability and survives forwarding.

What is a DKIM selector?

A selector is a label in the DKIM record’s hostname (selector._domainkey.yourdomain) that lets you publish more than one key at a time. The signature’s s= tag names the selector so the receiver fetches the right key. Selectors are what make safe key rotation possible.

Should I use a 1024-bit or 2048-bit DKIM key?

Use 2048-bit. 1024-bit is the minimum providers accept but is cryptographically weak. A 2048-bit key is the modern recommendation; just remember it exceeds the 255-character DNS string limit and must be split into multiple strings inside one TXT record.

Why does DKIM break on mailing lists?

Many mailing lists modify the message — adding a footer or tagging the subject — which changes the signed body and invalidates the DKIM signature. This is normal. DMARC tolerates it because it passes when either SPF or DKIM is aligned, and well-configured lists re-sign or rewrite the From address.

How often should I rotate DKIM keys?

A common best practice is roughly twice a year, automated through selector rotation. Publish the new key under a new selector, start signing with it, keep the previous public key in DNS for a few weeks so in-flight mail still verifies, then remove the old one.

Can I have more than one DKIM record?

Yes — unlike SPF, you can publish multiple DKIM records, one per selector. That is precisely how different services (and key rotation) coexist: each uses its own selector and therefore its own DKIM record. A typical domain has several DKIM records live at the same time — one for each sending platform you use, plus the previous selector kept around during a key rotation — and that is completely normal, expected, and correct.