What Is DKIM? How Email Signing Works and Why It Matters

Every email you send passes through servers you do not control. Any of them could alter the message, and anyone on the internet can type your domain into a From field. DKIM exists to solve both problems. It lets a receiving mail server confirm that a message really was sent by the domain it claims to come from, and that nobody changed it along the way.

If you have already read our guides on SPF and DMARC, DKIM is the third piece of the same puzzle. This guide explains what it is, how the signing process works, how to set it up, and the mistakes that most often break it.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication standard, defined in RFC 6376, that attaches a cryptographic signature to every outgoing message. The signature is created with a private key that only the sender holds, and it can be verified by anyone using a public key published in the sender's DNS.

A useful way to think about it is a wax seal on a letter. The seal does not hide what the letter says, but it proves two things: who sealed it, and that it has not been opened and rewritten since. DKIM gives email the same guarantee.

How DKIM works, step by step

The process runs automatically on every message, and it takes a fraction of a second.

1. You generate a key pair. The private key stays on your mail server or with your email provider. The public key is published as a TXT record in your DNS.
2. Your server signs each outgoing email. It builds a hash of the message body and of selected headers such as From, Subject and Date, then signs that hash with the private key.
3. The signature travels with the message. It is added as a header called DKIM-Signature.
4. The receiving server looks up your public key. It reads the domain and selector from the signature and queries DNS for the matching record.
5. The receiver checks the signature. If the hash it calculates matches the one in the signature, DKIM passes. If the message was changed in transit, or the key does not match, DKIM fails.

What a DKIM signature looks like

Open the original source of any email and you will find a header like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

The tags that matter most are:

• d= is the signing domain. This is the domain taking responsibility for the message.
• s= is the selector, which tells the receiver which key to fetch.
• h= lists the headers covered by the signature.
• bh= is the hash of the message body.
• b= is the signature itself.

The DKIM record and selectors

The public key lives in DNS at a predictable address: the selector, then _domainkey, then your domain. With the example above, a receiver would query selector1._domainkey.example.com and expect a TXT record that begins with v=DKIM1; k=rsa; p= followed by the public key.

Selectors exist so that one domain can hold several keys at the same time. That is how your Google Workspace mail, your marketing platform and your billing system can each sign with their own key without stepping on each other. It also makes key rotation painless, because you can publish a new key under a new selector before retiring the old one.

Why DKIM matters for deliverability

It is no longer optional. Gmail, Yahoo and Microsoft all require bulk senders to authenticate with both SPF and DKIM. Mail that fails is deferred or rejected outright. We cover the full list in our bulk sender requirements checklist.

It survives forwarding. SPF checks the IP address of the server that delivered the message, so it usually breaks when an email is forwarded. A DKIM signature travels inside the message, so it keeps passing as long as the content is untouched.

It carries your reputation. Mailbox providers build reputation around the signing domain. Signing with your own domain means the reputation you earn stays with you, even if you change email providers or IP addresses.

DMARC depends on it. DMARC passes only when SPF or DKIM passes and aligns with the domain in the From address. Because DKIM survives forwarding, it is the more dependable of the two.

DKIM alignment: the detail most senders miss

Passing DKIM is not the same as passing DMARC. Many email platforms sign your mail with their own domain by default, so the signature reads d=mailprovider.com while your From address reads you@yourcompany.com. DKIM technically passes, but the domains do not match, so DMARC alignment fails.

The fix is to set up custom DKIM, sometimes called domain authentication, in every platform that sends on your behalf. Once the signature shows d=yourcompany.com, or a subdomain of it, alignment is satisfied.

How to set up DKIM

The exact clicks differ by provider, but the sequence is always the same.

1. List every system that sends email as your domain. Include your mailbox provider, marketing automation, CRM, helpdesk, invoicing tool and any application that sends notifications.
2. Generate a key in each system. In Google Workspace this is under Apps, Google Workspace, Gmail, Authenticate email. In Microsoft 365 it is in the Defender portal under email authentication settings. Most marketing platforms call it domain authentication.
3. Publish the records in DNS. You will be given either a TXT record containing the key, or CNAME records that point to keys the provider hosts and rotates for you.
4. Turn signing on. Publishing the record is not enough. In several platforms, signing stays off until you enable it.
5. Test it. Send a message to a Gmail address, open it, choose Show original, and confirm that DKIM shows PASS with your own domain.

Key length and rotation

Use 2048-bit RSA keys. The standard still permits 1024-bit keys, but they are considered weak, and Google recommends 2048. One practical catch: a 2048-bit key is longer than the 255 characters a single DNS string can hold, so it has to be split into multiple quoted strings inside one TXT record. Most DNS hosts handle this for you, but a truncated key is a classic cause of silent DKIM failure.

There is no official rotation schedule. Rotating every 6 to 12 months is common practice. Publish the new key under a new selector, switch signing over, and remove the old record only after mail signed with the old key has finished delivering.

Common DKIM mistakes

• Signing with the provider's domain instead of your own, which breaks DMARC alignment.
• Forgetting a sending source. One unsigned system is enough to send a share of your mail to spam.
• Truncated or badly formatted keys after a copy and paste into DNS.
• Publishing the record but never enabling signing.
• Leaving test mode on. A t=y flag tells receivers to treat the signature as a test.
• Never rotating keys, or deleting the old key too early during a rotation.
• Content changes in transit. Mailing lists and security gateways that add footers or rewrite links can invalidate the signature.

DKIM vs SPF vs DMARC

The three standards answer different questions.

• SPF asks whether the sending server is authorized to send for the domain.
• DKIM asks whether the message is intact and signed by the domain.
• DMARC asks whether either result lines up with the visible From address, and tells receivers what to do when it does not.

You need all three. SPF and DKIM do the checking, and DMARC turns the results into a policy and a set of reports.

Final thoughts

DKIM takes an hour to set up and protects every message you send afterwards. If you are not sure whether all of your sending sources are signing with your own domain, check the headers of a recent message from each one. It is the quickest deliverability audit you can run, and it often explains why some of your mail is landing in spam while the rest is not.

At ImpactQuill, DKIM and alignment checks are the first thing we look at in every deliverability audit, because they are the most common root cause we find.