What is a DKIM record and how do you set one up correctly?

A DKIM record is a DNS TXT record that publishes the public key receivers use to verify the digital signature on your outgoing email. Your mail system signs each message with a private key, and the receiver looks up the matching public key under a selector in your domain to confirm the message was not altered.

How does DKIM work in practice?

DomainKeys Identified Mail is defined in RFC 6376. The sender adds a DKIM-Signature header to each message. That header names the signing domain in the d= tag and a selector in the s= tag. It also holds a hash of the body (bh=), the list of signed headers (h=) and the signature itself (b=).

The receiver builds a DNS name from those two tags. RFC 6376 says all DKIM keys are stored in a subdomain named _domainkey, so the key for selector brisbane and domain example.com lives at brisbane._domainkey.example.com. The receiver fetches the TXT record, recomputes the body hash, and verifies the signature with the public key. If the body hash does not match, verification fails.

What goes inside the record?

The value is a list of tag and value pairs. The two that matter most are v=DKIM1 for the version and p= for the base64 public key. Many records also include k=rsa for the key type. Revoking a key is done by publishing an empty p= value. Your email provider will usually hand you the exact string to paste, or a CNAME that points to a record they host.

The selector is a label you choose. It lets one domain carry several keys at once, for example one per sending service, or an old and a new key during rotation.

What key size and algorithm should you use?

RFC 8301 updated the rules in 2018. It says the SHA-1 hash algorithm MUST NOT be used for DKIM, so signing should use rsa-sha256. Signers MUST use RSA keys of at least 1024 bits and SHOULD use keys of at least 2048 bits. Verifiers must not treat signatures from keys shorter than 1024 bits as valid.

A 2048 bit key produces a long record. Some DNS interfaces split long TXT values into several quoted strings, which is allowed, but pasting the value with stray spaces or line breaks is the most common way to break it.

What does DKIM not do?

DKIM proves that a domain that controls a key vouches for the message and that the signed parts did not change. It does not by itself say the signing domain matches the visible From address, and it does not tell receivers what to do with a failure. That is the job of DMARC, which ties the DKIM or SPF result to the From domain. RFC 6376 also treats the optional l= tag, which limits how much of the body is signed, as a risk: an attacker can append content that stays outside the signed length. Avoid it.

A constructed example

A company sends marketing mail through one service and invoices through another. It creates two selectors, mkt1 and inv1, so each service signs with its own key. Later the invoice service is replaced. The team deletes the inv1._domainkey record, and the old service can no longer sign for the domain, while marketing mail is unaffected. Separate selectors made that offboarding clean.

How to check or apply this

1. List every system that sends email as your domain, including CRM, billing, support and monitoring tools.
2. Generate a 2048 bit RSA key per sender in that sender's settings, and choose a distinct selector for each.
3. Publish the TXT or CNAME record exactly as given, then wait for DNS to propagate.
4. Send a test message to a mailbox you control and read the Authentication-Results header for dkim=pass and the expected d= domain.
5. Add a DMARC record in monitoring mode and read the reports before tightening policy.
6. Rotate keys on a schedule: publish the new selector, switch signing, leave the old record up for a few days, then remove it.

Quick check

Sources

• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM

Last reviewed: 18 October 2026.