What Is DKIM? How Email Signing Works

Every DKIM setup uses a pair of cryptographic keys — one private and one public. Your mail server holds the private key, and your public key is published as a DKIM record in your domain's DNS (the system that translates domain names into addresses).

When you send an email, your mail server uses the private key to generate a unique DKIM signature based on the message content. That signature is added to the email header — a behind-the-scenes section the recipient never sees.

A DKIM record is a DNS TXT entry that publishes your public key so receiving servers can find it. It lives at a specific address inside your domain's DNS zone, formatted like this: selector._domainkey.yourdomain.com.

The record contains the public key itself along with a few parameters that tell the receiving server which encryption method to use. You do not need to understand the technical details — your email provider usually generates this record for you.

You might have noticed the word "selector" in that DNS address. A selector is simply a label that identifies which key to use. It lets you have multiple DKIM records on the same domain — one for each email service you use.

For example, if you send marketing emails through Mailchimp and internal emails through Google Workspace, each service gets its own selector and its own key pair. Google might use a selector called "google", while Mailchimp might use "k1".

This means you can add or remove email services without disrupting the others. Each service manages its own DKIM signature independently.

Without a DKIM signature, your emails have no proof of integrity. Any server that handles your message along the way could modify the content — injecting links, changing text, or adding attachments — and the recipient would have no way to detect it.

Receiving mail servers are increasingly suspicious of unsigned emails. Messages without DKIM are more likely to land in spam folders or be rejected outright, especially by providers like Google and Microsoft.

DKIM is one of three email authentication protocols. Each one does a different job, and they are designed to work as a set.

SPF (Sender Policy Framework) checks whether the sending server is authorized to send on behalf of your domain. You can learn more in our guide to SPF.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when a message fails authentication — accept it, quarantine it, or reject it. Our DMARC explainer covers this in detail.

On its own, DKIM proves the message was not tampered with. Combined with SPF and DMARC, it gives receiving servers a complete picture: the sender is authorized, the message is intact, and there is a clear policy for handling failures.

Setting up DKIM involves generating a key pair, publishing the public key as a DKIM record in your DNS, and configuring your email service to sign outgoing messages with the private key.

Most email providers — Google Workspace, Microsoft 365, Mailchimp, and others — handle the key generation and signing for you. Your job is to add the DNS record they give you to your domain's DNS settings.

The tricky part is that every email service you use needs its own DKIM record. If you send emails from your CRM, your helpdesk, your marketing platform, and your main inbox, each one needs to be configured separately. Miss one, and those emails go out unsigned.