What Is DKIM (DomainKeys Identified Mail)?

DomainKeys Identified Mail (DKIM) is an email authentication standard in which the sending system adds a digital signature to each message using a private key, and receiving servers check it against a public key published in the sender’s DNS. A valid signature shows that a specific domain took responsibility for the message and that the signed headers and body weren’t changed on the way. DKIM is one of the two checks, with SPF, that DMARC relies on.

At a glance

• DKIM signs outgoing mail with a private key; receivers verify it using the public key in a DNS record.
• The signing domain (d=) can be any domain, so DKIM alone doesn’t prove the visible From address; DMARC alignment does that.
• The signature usually survives simple forwarding, but mailing lists and gateways that change messages can break it.
• For DMARC, each service that sends as your domain, such as marketing, billing and help desk platforms, needs at least one aligned check, preferably DKIM signing as your domain, otherwise aligned SPF; a central outbound relay can sign for several services.
• Keys need managing: 2048-bit RSA is common today, and keys should be rotated and retired.

What problem it solves

Email was designed without any way to prove who sent a message. DKIM adds that proof at the domain level. When a message carries a valid DKIM signature for your domain, receivers know your domain authorized it and that the signed content wasn’t tampered with, which supports both security and deliverability: mailbox providers use authentication results when deciding whether mail reaches the inbox.

DKIM also fills a gap in SPF. SPF checks the connecting server, so it typically fails when mail is forwarded through another server. A DKIM signature travels inside the message and usually survives that hop, which is why aligned DKIM is often the more dependable way to pass DMARC.

How it works

1. Generate keys. A public/private key pair is created for the system that signs, whether a central outbound relay or each platform that sends directly; separate selectors per directly signing platform are recommended. The private key stays with the sending system; many cloud email and marketing services generate and hold it for you.
2. Publish the public key. It goes in a DNS TXT record at selector._domainkey.yourdomain.com, where the selector is a label you choose (for example s1 or marketing). Many SaaS senders ask you to publish a CNAME pointing to a record they manage, which lets them rotate keys.
3. Sign outgoing mail. The sending system hashes selected headers, always including From, and the body, signs the result, and adds a DKIM-Signature header listing the signing domain (d=), the selector (s=), the algorithm and the signed headers.
4. Verify on receipt. The receiver reads the header, looks up the public key in DNS using the selector and domain, recomputes the hashes and checks the signature.
5. Feed DMARC. The result, pass or fail, and the signing domain are passed to DMARC, which checks whether that domain aligns with the From address.

Signatures fail when the DNS record is missing or malformed, when the message is modified after signing, or when the public key is removed from DNS while mail signed with it is still being delivered.

When it matters for buyers

• When moving to enforced DMARC. Each legitimate sender needs at least one aligned check, preferably DKIM, otherwise aligned SPF, or enforcement will quarantine or reject its mail.
• When adding a SaaS platform that sends email. Confirm it can sign as your domain (d=yourdomain.com) rather than its own before it goes live.
• When deliverability drops. Missing or failing signatures are a common cause, especially after a platform change.
• When mailbox providers’ bulk sender rules apply. High-volume senders are generally expected to sign with DKIM; see bulk sender requirements.
• When staff or vendors change. Keys held by a departed administrator or a retired platform should be rotated or removed.

Questions to ask vendors

These apply to any platform that sends email in your name.

• Can you sign with our domain in d=, and how do we publish the key (TXT or CNAME)?
• What key length and algorithm do you use, and do you rotate keys for us?
• Can we use a separate selector or subdomain for your service?
• Do you modify messages after signing, for example adding footers or tracking links?
• What happens to our DKIM records if we stop using your service?

How it differs from SPF

SPF publishes the list of servers allowed to send for a domain and checks the connecting server’s IP address against it. DKIM checks a signature inside the message, so it doesn’t depend on which server delivered it. SPF checks the envelope sender (return-path) domain and DKIM checks the signing domain; neither on its own checks the From address people see, which is what DMARC adds. Many organizations set up all three, and BIMI logos depend on DMARC at enforcement. For filtering and protecting inbound mail, see our secure email gateway overview.