How to Set Up DKIM (Step by Step)

A practical setup guide. Email Posture.

DKIM adds a cryptographic signature to the email you send. Receiving servers use it to confirm the message really came from your domain and wasn't altered in transit. Along with SPF, it's one of the two checks that DMARC relies on, and DKIM is the more dependable of the pair because it survives forwarding.

The important thing to understand up front: DKIM isn't set in one place. You enable it inside each service that sends mail as you, and each one gives you a record to publish in DNS. Here's how to do it for the common ones, then how to confirm it worked. You can check your domain first to see what's already in place.

How DKIM works, briefly

When you turn DKIM on, your provider holds a private key and signs outgoing mail with it. You publish the matching public key in DNS at a host like selector._domainkey.yourdomain.com. The "selector" is just a label that lets you have more than one key (different services, or rotated keys). Receivers read the selector from the message header, fetch the public key, and verify the signature.

Google Workspace

In the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Authenticate email. Pick your domain, generate a new record (choose the 2048-bit key if offered), and Google shows you a TXT record with a host like google._domainkey. Publish that TXT record at your DNS host, wait for it to propagate, then come back and click Start authentication. Until you click start, Google generates the key but doesn't sign with it.

Microsoft 365

In the Microsoft Defender portal, go to Email & collaboration, then Policies & rules, then Threat policies, then Email authentication settings, then DKIM. Select your domain and enable it. Microsoft asks you to publish two CNAME records (selector1._domainkey and selector2._domainkey) that point to Microsoft-hosted keys. Add both at your DNS host, then toggle DKIM signing on for the domain.

Other senders (SendGrid, Mailchimp, your CRM, and so on)

Every reputable sending platform has a "domain authentication" or "verify your domain" step. It hands you one or more CNAME or TXT records to publish. Do this for every tool that sends mail using your domain in the From address: your marketing platform, your help desk, your invoicing app, your transactional email service. A sender you forget about is the one that fails once you turn DMARC up to enforcement.

Verify it took

After the records propagate (minutes to a few hours), run a check to confirm DKIM is detected and signing. Send yourself a test message and view the original or headers; you're looking for dkim=pass and a domain (d=) that matches your own. That match is "alignment," and it's what lets DKIM satisfy DMARC.

A few things people trip on

• The record didn't publish, or got truncated. DKIM keys are long. Some DNS hosts split TXT values across quoted strings, which is fine, but a copy-paste that drops characters will fail. Re-check the full value.
• Enabled the key but never flipped signing on. Generating the record and actually signing are two separate steps in Google and Microsoft. Make sure signing is active.
• Use 2048-bit keys. 1024 still validates but is weaker; pick 2048 where you can.
• Rotate occasionally. Good providers let you rotate keys. If you ever suspect exposure, rotate and update the published record.

What's next

With SPF and DKIM both passing and aligned, you're ready to layer DMARC on top so receivers actually act on spoofed mail. That's the step that turns "we can be verified" into "we can't be impersonated."

Related: How to Set Up DMARC · SPF Record Not Working? · Why Are My Emails Going to Spam?