How to Set Up DKIM for Your Sending Domain

DKIM setup means generating a public/private key pair on your sending platform, publishing the public half as a DNS record on your domain, and turning on signing so every outgoing message carries a verifiable signature. It takes about 15 minutes of active work per sending platform, though DNS propagation can add a few hours of waiting.

This guide walks through the actual steps: on Amazon SES, Google Workspace, and Microsoft 365, the three platforms most SaaS founders touch. You will get copyable record formats, the exact place to add them, and how to confirm DKIM is really signing your mail instead of silently failing.

Key takeaways

• DKIM setup is three steps on every platform: generate a key pair, publish the public key as a DNS record, turn on signing. The differences are where you click and whether the record is a TXT or CNAME.
• Amazon SES uses "Easy DKIM," which hands you three CNAME records and rotates the keys for you, the most common path for teams running their own SES sending infrastructure.
• Google Workspace and Microsoft 365 use a single TXT record with a selector, but Microsoft ships DKIM disabled by default even after you add the records, so a separate "enable" step is easy to miss.
• DKIM alone does not fix deliverability. It has to align with your DMARC policy and sit alongside SPF, or Gmail and Yahoo's bulk sender rules will still flag you.
• Verify with a real send, not just a DNS lookup. A published record that never gets turned on for signing looks fine in a checker and still leaves your mail unauthenticated.
• If you send from more than one platform (SES for product email, Workspace for support), each one needs its own DKIM record with a distinct selector.

What DKIM setup actually involves

DKIM (DomainKeys Identified Mail) proves two things to a receiving mail server: the message came from a server that holds your domain's private key, and nobody altered it in transit. It does this with a digital signature added to the message header, verified against a public key you publish in DNS.

Setup has exactly three moving parts, regardless of platform:

1. Generate a key pair. Your sending platform (SES, Workspace, your SMTP provider) creates a private key it keeps and a public key it hands you.
2. Publish the public key in DNS. You add it to your domain's DNS zone as a TXT or CNAME record, using a "selector" (a short string like ses or google) that lets multiple DKIM keys coexist on one domain.
3. Turn on signing. The platform has to be told to actually attach the signature to outgoing mail. On some platforms this happens automatically once the record verifies; on others it is a separate switch you can forget to flip.

Miss step 3 and your DNS lookup tools will report a clean DKIM record while your actual mail goes out unsigned. That gap is the most common DKIM setup mistake, and it is invisible unless you check message headers directly.

Before you start: what you need

• Admin access to your domain's DNS zone (Cloudflare, Route 53, GoDaddy, Namecheap, whatever you use).
• Admin access to the sending platform you are authenticating (AWS SES console, Google Workspace Admin console, Microsoft 365 admin center).
• A few hours of buffer for DNS propagation. Most providers detect a new record within minutes to a few hours; AWS gives it up to 72 hours before it stops checking.
• If you are already running SPF and DMARC, have those records open in another tab. DKIM setup is one third of the SPF, DKIM, and DMARC picture, not the whole thing.

DKIM setup on Amazon SES (Easy DKIM)

SES is the most common path for SaaS teams who want to own their sending infrastructure instead of routing through a third-party platform. Amazon's "Easy DKIM" generates and rotates the keys for you, which removes the manual key-management step most other guides describe. If you have not yet finished the base setup, see how to set up Amazon SES first, since domain verification happens before DKIM configuration.

Step 1: Open the identity in SES. In the SES console, go to Configuration > Identities and select the domain identity you are sending from (not a single email address, the domain itself).

Step 2: Turn on Easy DKIM. On the Authentication tab, find the DKIM panel and choose Edit. Select Easy DKIM, choose a key length (2048-bit is the current default and the one to pick unless a specific tool of yours only supports 1024-bit), and enable DKIM signing. Save.

Step 3: Copy the three CNAME records. SES generates three CNAME records tied to your domain and selector. Expand "View DNS records" on the identity page to see them. A record looks like this in shape (values are placeholders, yours will be unique strings SES generates):

Type: CNAME
Name: abc123def456._domainkey.yourdomain.com
Value: abc123def456.dkim.amazonses.com

Step 4: Publish all three CNAMEs in your DNS zone. Add each one exactly as shown, no extra characters. A common failure here is a DNS provider that auto-appends your domain to the "Name" field, which produces a doubled domain suffix. Check your provider's docs if the record does not verify after a few hours.

Step 5: Wait for verification. SES checks for the records automatically and typically confirms within a few hours, with a hard ceiling of 72 hours. Once verified, SES starts signing outgoing mail with no further action.

One region-specific gotcha: if you send from more than one AWS region, DKIM has to be configured separately in each region. It is not a global, one-time setting.

DKIM setup on Google Workspace

Step 1: Generate the key. In the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email. Select the domain, then click Generate new record. Choose 2048-bit unless you have a specific reason to use 1024-bit.

Step 2: Copy the TXT record. Google gives you a selector (default google, or a custom one you choose) and a long TXT value starting with v=DKIM1. It looks like this in shape:

Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Step 3: Publish it in your DNS zone, then wait. Google recommends waiting at least an hour before activating, though propagation is often faster.

Step 4: Go back and click "Start authentication." This is the step people skip. Publishing the TXT record alone does not turn on signing. You have to return to the Admin console and explicitly activate it once the record is live.

DKIM setup on Microsoft 365

Microsoft's flow has one extra wrinkle: DKIM is disabled by default for custom domains, and Microsoft applies its own fallback signature (using a *.onmicrosoft.com domain) that will not align with your custom domain for DMARC purposes.

Step 1: Get the two CNAME records. In the Microsoft 365 Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, select your domain, and if DKIM has never been configured you will be prompted to create the CNAME records.

Step 2: Publish both CNAMEs. They follow this shape:

Type: CNAME
Host: selector1._domainkey
Value: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Type: CNAME
Host: selector2._domainkey
Value: selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Step 3: Enable the toggle. Back in the DKIM settings for your domain, switch "Sign messages for this domain with DKIM signatures" to Enabled. Without this explicit toggle, the CNAME records sit in DNS doing nothing.

Comparison: DKIM setup by platform

Using a DKIM or DMARC record generator

If your sending platform does not generate a key pair for you (common with self-hosted mail servers or some SMTP relays), a free DKIM record generator will produce the key pair and format the DNS record correctly. You still have to install the private key on your sending server yourself, the generator only handles the DNS side.

The same logic applies to DMARC: rather than hand-writing the tag syntax, a dmarc record generator like MxToolbox's DMARC Record Generator or EasyDMARC's DMARC Generator lets you set your policy (p=none, quarantine, or reject) and reporting addresses without hand-assembling the string. Start with p=none so you get visibility before you risk blocking your own mail.

Verifying DKIM actually works

A DNS lookup showing your record exists is not proof that signing is turned on. Verify with a real message:

1. Send a test email to a Gmail or Outlook.com address you control.
2. Open the message and view the full headers (in Gmail: More options > Show original).
3. Look for Authentication-Results. You want to see dkim=pass next to your sending domain, with the selector matching what you published.
4. If you see dkim=none or dkim=fail, the record either has not propagated yet, has a typo, or signing was never enabled on the platform side.

Tools like MXToolbox's DKIM lookup can confirm the record resolves, but the header check on a real send is the only step that confirms signing is live.

Common DKIM setup mistakes

• Publishing the record but never enabling signing (Google and Microsoft both require this as a separate step).
• Truncated TXT records. Some DNS hosts split long TXT values and require quotes around each chunk; a malformed record fails silently.
• Wrong selector. If your sending platform expects selector1._domainkey and you published selector2._domainkey, verification never completes.
• Forgetting a second sending platform. If product email goes through SES and support email goes through Workspace, both need independent DKIM records. One passing does not cover the other.
• Assuming DKIM alone is enough. DKIM proves the message was not tampered with and came from a key holder. It does not, by itself, stop someone from spoofing your visible From address using a different, aligned domain. That is DMARC's job, which is why the three records work as a set. For the fuller picture of how they interact, see SPF, DKIM, and DMARC explained.

Where DKIM fits in your bigger deliverability picture

DKIM setup is table stakes, not a finish line. Getting a green checkmark on a DNS checker tells you the record is well-formed. It does not tell you whether your sender reputation is healthy, whether your complaint rate is climbing, or whether your emails are landing in the primary inbox versus a spam folder that authenticates you fine but still filters you. Those are separate, ongoing problems covered in the full email deliverability guide and in how sender reputation is actually built over time.

If you are setting this up because you are moving your SaaS product email onto your own AWS SES account (rather than staying on a shared sending pool), this is also the moment to nail down your full authentication stack, not just DKIM in isolation. Meisa handles domain verification and DKIM/SPF/DMARC status as part of sender identity setup when you connect your own SES account, so the check is visible in one place instead of scattered across the SES console, your DNS host, and a separate checker tool. It is one of a few real deliverability levers, alongside chunked "warm send" delivery for new domains and true open-rate reporting that separates human opens from scanner opens, built for teams who send their own product email instead of hiring an agency to babysit DNS records.

Whatever platform you land on, the sequence does not change: generate the key, publish the record, flip the signing switch, and verify with a real header check before you trust it.

FAQ

How long does DKIM setup take to work?

Active setup takes 10 to 20 minutes per platform. DNS propagation adds time on top: Google Workspace recommends waiting about an hour before activating, Microsoft 365 usually confirms within a few hours, and Amazon SES can take up to 72 hours in the worst case, though it is typically much faster.

Do I need DKIM if I already have SPF?

Yes. SPF and DKIM check different things. SPF verifies which servers are allowed to send for your domain; DKIM verifies the message itself was not altered and came from a key holder. Google and Yahoo's bulk sender rules (in effect since February 2024) require both, plus a DMARC record, for anyone sending more than 5,000 messages a day to their users.

What is a DKIM selector and why does it matter?

A selector is a short label (like google or ses1) prepended to _domainkey in the DNS record name. It lets a domain host multiple DKIM keys at once, one per sending platform. If you switch providers or add a second one, you use a different selector so the old and new records do not collide.

Can I use a free DKIM record generator instead of my email platform's built-in tool?

Yes, if your platform does not generate keys for you. A generator like EasyDMARC's or PowerDMARC's creates the key pair and formats the DNS record. You are still responsible for installing the private key on your sending server, the generator only produces the public half that goes in DNS.

Why does my DKIM record look correct but still fail?

The three usual causes: signing was never explicitly enabled on the platform (common on Google Workspace and Microsoft 365), the DNS record has a formatting error such as a missing quote around a long TXT value, or the selector in the record does not match what the sending platform is actually using to sign. Check the Authentication-Results header on a real test send to confirm which one it is.