What Is DKIM? Signing Email So Receivers Trust You

DKIM is what turns an outbound email into something a receiver can actually verify. Without it, the only thing stopping a spammer from sending mail that looks like it came from your domain is the SPF record, and SPF doesn't cover the visible From address. This page explains what DKIM is, how selectors and the public key in DNS work together, and the order you set DKIM up in during a migration so mail keeps signing through the cutover.

What DKIM is#

DKIM stands for DomainKeys Identified Mail. It is defined in RFC 6376. When a mail server sends a message, it computes a cryptographic signature over selected headers and the body, then attaches that signature as a DKIM-Signature: header on the outgoing message.

A receiver that wants to verify the message looks up a public key in DNS, uses it to check the signature, and learns two things:

1. The message has not been altered in transit. If anything important changed between the sender and the receiver, the signature breaks.
2. The signing domain authorised the message. Only someone with the private key paired to the published public key could have produced that signature.

DKIM does not encrypt the message. It signs it. Anyone can still read the contents in transit — DKIM is about authenticity, not privacy.

How the DNS side works#

The public half of the keypair lives in DNS as a TXT record. The record name is built from two parts: a selector, and the literal label _domainkey. For example:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

The selector is just a short label chosen by whoever runs the signing server. Common selectors include:

• Microsoft 365: selector1 and selector2
• Google Workspace: google
• Mailgun, SendGrid and other ESPs: s1, mta1, pic, and provider-specific names

The selector matters because it lets one domain publish many keys at once. The signing server tells receivers which key to use by including the selector in the DKIM-Signature: header on every message it sends.

What a DKIM signature actually proves#

When a receiver verifies a DKIM signature, the result goes into the Authentication-Results: header on the received message:

Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector1

A dkim=pass result means the signature was valid against the published key. It does not mean the message is safe — it just means the listed domain authorised this exact set of bytes. DMARC then takes that result and decides what to do with it.

For the full picture, see SPF and DMARC, which work alongside DKIM to authenticate outbound mail.

Setting up DKIM during a migration#

The mistake to avoid is enabling DKIM on the new provider after cutover. By then, every outbound message from the new tenant has already been going out unsigned for hours, and downstream receivers have noticed.

The order that actually works is this:

1. Generate DKIM keys at the new provider while the old provider is still live. Microsoft 365, Google Workspace and Zoho all expose this in the admin centre.
2. Publish the public-key TXT records at the new selectors. They will sit alongside the existing provider's records — that's fine.
3. Enable signing at the new provider with the keys generated in step 1.
4. Send a test message from a new-tenant mailbox to an external Gmail address. Confirm dkim=pass in the Authentication-Results header.
5. Flip the MX record only after DKIM verifies cleanly.
6. Leave the old provider's DKIM records in place for the first 30 days after cutover. Mail that was queued, forwarded or processed before the flip may still be evaluated against the old keys.

Verifying DKIM works#

Three checks confirm signing is healthy.

• dig TXT selector1._domainkey.example.com — confirms the public key is published and parseable.
• Send to a Gmail address and view the original. Look for dkim=pass. If you see dkim=neutral or dkim=none, the message is not being signed at all.
• Send to a strict mailbox such as a corporate Office 365 tenant. Some receivers downgrade unsigned mail more aggressively than Gmail does.

For the Microsoft-specific quirks — selector naming, CNAME publication, and how DKIM interacts with the tenant's accepted domains — see the Office 365 migration guide.

Where DKIM fits in the runbook#

DKIM is one of four DNS jobs at cutover, alongside MX, SPF and DMARC. The full sequence — including when each record changes relative to the IMAP copy and the MX flip — is in the complete email migration guide. The short version: DKIM goes live first so the new tenant is already signing before any real mail arrives at it.