How to Set Up a DKIM Record Correctly (Step-by-Step Guide)

If you've set up SPF and found your forwarded mail failing authentication, or wondered why your DMARC reports show DKIM failures, you're not alone. DKIM (DomainKeys Identified Mail) is the piece of email authentication that most people skip — and it's the one that actually proves your email hasn't been tampered with.

Here's how to set it up properly, step by step.

What DKIM Actually Does

DKIM adds a cryptographic signature to every email your domain sends. The receiving server looks up your public key in DNS, decrypts the signature, and checks that the headers and body haven't been changed in transit.

The key difference from SPF: DKIM survives forwarding. When a message is forwarded, SPF breaks because the check runs against the forwarding server's IP. But the DKIM signature is embedded in the email itself — it stays valid through any number of forwards. That's why you need both.

Step 1: Understand the DKIM Components

A DKIM setup involves three pieces:

• Private key — stored on your sending server (never published). Used to sign outgoing emails.
• Public key — published as a DNS TXT record. Used by receiving servers to verify signatures.
• Selector — a label that identifies which public key to use. This lets you have multiple keys for different services or rotate keys without disruption.

The DNS record lives at {selector}._domainkey.yourdomain.com. For example, if Google Workspace uses the selector google, the record is at google._domainkey.yourdomain.com.

Step 2: Get Your DKIM Values from Your Email Provider

Every major email provider generates DKIM keys for you. You don't create the keys yourself — your provider gives you the public key value (or a CNAME) to publish in DNS.

Google Workspace

1. Open the Google Admin console.
2. Go to Apps > Google Workspace > Gmail > Authenticate email.
3. Select your domain and click Generate new record.
4. Choose a key length (2048 bits is recommended; 1024 is the minimum).
5. Copy the displayed TXT record value. It looks like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

6. Click Start authentication — but don't turn it on yet. Publish the DNS record first.

Microsoft 365

1. Open the Microsoft Defender portal.
2. Go to Email & Collaboration > Policies & Rules > Threat policies > Email authentication settings > DKIM.
3. Select your domain and choose Create DKIM keys.
4. Microsoft displays two CNAME records for two selectors (selector1 and selector2). The second selector is for automatic key rotation — publish both.
5. The CNAME records look like:

Host: selector1._domainkey.yourdomain.com
Points to: selector1-yourdomain-com._domainkey.initialdomain.onmicrosoft.com

Host: selector2._domainkey.yourdomain.com
Points to: selector2-yourdomain-com._domainkey.initialdomain.onmicrosoft.com

Other Providers

Most providers follow the same pattern: they generate a key pair, show you the public key, and tell you where to publish it. Common selectors used by different services:

If you're not sure, your provider's DKIM setup guide will tell you the exact selector name.

Step 3: Publish the Public Key in DNS

Add the DKIM record as a TXT record at the selector subdomain. Your provider either gives you a TXT record value (a string starting with v=DKIM1;) or a CNAME pointing to their infrastructure.

If it's a TXT record:

If it's a CNAME record (Microsoft 365, some managed providers):

Important: Do not use the same selector for multiple services. Each sending service (Google Workspace, Mailchimp, SendGrid) needs its own DKIM record under its own selector. They can all live under the same domain — just with different selectors.

Step 4: Enable DKIM Signing

After publishing the DNS record, go back to your email provider and enable DKIM signing. Most providers will check for the DNS record and confirm it's valid before allowing you to turn signing on.

Once enabled, every outgoing email from that service will include a DKIM-Signature header. You can verify this by sending a test email and viewing the raw headers.

Step 5: Test Your DKIM Configuration

Send a test email to a Gmail address and check the headers:

1. In Gmail, open the email and click the three dots in the top-right corner.
2. Select Show original.
3. Look for DKIM-Signature in the headers.
4. Check that the status line reads PASS.

For example, a passing DKIM result in Gmail looks like:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@yourdomain.com

If you see dkim=neutral or dkim=fail, the record isn't published correctly or the signature doesn't match. Common causes:

• The DNS record hasn't propagated yet (can take a few minutes to an hour).
• The selector doesn't match what your provider is using to sign.
• The key content has a typo (extra spaces, newlines, or missing characters).

You can also use a free DKIM lookup tool to verify your record is published correctly. Just enter your domain and selector.

Step 6: Set Up DKIM for Each Sending Service

This is the step most people miss. Every service that sends email as your domain needs its own DKIM configuration. If you use Google Workspace for day-to-day email and Mailchimp for newsletters, both need DKIM enabled — each under its own selector.

The DMARC reports you receive will show you which sources are and aren't DKIM-signing. If you see a source failing DKIM, find its DKIM setup guide and configure it.

Step 7: Move to DMARC Enforcement

With SPF and DKIM both configured, your DMARC checks will have two paths to pass. Mail that passes either SPF alignment or DKIM alignment will pass DMARC — and that's the foundation for moving your DMARC policy from p=none to p=quarantine and eventually p=reject.

Without DKIM, forwarded mail fails SPF and has no fallback, which means DMARC enforcement would break forwarding. With DKIM, the signature survives the forward, and DMARC passes on DKIM alignment.

Common DKIM Mistakes to Avoid

Using too short a key. Some providers default to 1024-bit keys. Use 2048-bit where available. A few email providers reject 1024-bit keys as insufficient.

Publishing the private key. The public key starts with p= and contains only the public half. Never publish the private key — it should remain on your sending server and nowhere else.

Not rotating keys. DKIM keys should be rotated periodically. Microsoft 365 does this automatically with two selectors. For other providers, rotate manually every 6-12 months.

Sharing a selector across services. Each service needs its own selector. If Google Workspace and Mailchimp both use the same selector, the second one you publish will overwrite the first.

Skipping the propagation check. DNS changes don't take effect instantly. Wait a few minutes after publishing before enabling signing, and test with a real email before declaring it done.

How to Check Your DKIM Right Now

If you're not sure whether your DKIM is set up correctly — or even whether it exists — the fastest way to find out is to scan your domain. A good email security checker will tell you whether DKIM is published, whether the key is a valid length, and whether it's properly aligned with your sending domain.

That's exactly what this tool does: enter your domain and get an instant A–F grade on your SPF, DKIM, DMARC, and MX records, with a clear fix plan for anything that's failing.

How does your domain score?

Check your DMARC, SPF, DKIM & MX records in seconds — free, no signup.

Scan your domain