
Setting up DKIM involves three steps:
- Generate a key pair through your email provider
- Add the public key to your DNS as a TXT record
- Verify the signature is working
The process varies slightly depending on whether you’re using Google Workspace, Microsoft 365, or a transactional email service like SendGrid. We’ll cover everything in this guide.
What is DKIM, and why does your email need it?
DKIM proves that the message originated from the claimed sender and hasn’t been tampered with during transit.
When you send an email, your server creates a unique signature based on the message content and attaches it to the header. The receiving server then checks that signature against a public key stored in your DNS.
A matching signature means the email is authentic. A failed check (or a missing signature) raises red flags that often result in messages being flagged as spam.
The impact on deliverability is direct. Emails with valid DKIM signatures pass authentication checks that protect your sender reputation. Emails without DKIM — especially from high-volume senders — are increasingly being filtered or rejected outright.
If your emails are going to spam, missing DKIM authentication is one of the first things to check.
How does DKIM authentication actually work?
Understanding the mechanism helps you troubleshoot when something breaks. DKIM relies on public-key cryptography — a pair of mathematically linked keys where one encrypts and the other decrypts.
Key generation
Your email provider generates two keys:
- A private key stays on the sending server (never shared with anyone)
- A public key gets published in your DNS (accessible to all receiving servers)
Most providers now default to 2048-bit keys, which offer stronger security than the older 1024-bit standard. If given the option, choose 2048-bit.
Signing process
When you hit send, your email server:
- Creates a hash (unique fingerprint) of the message content
- Encrypts that hash using the private key
- Attaches the encrypted signature to the email header as DKIM-Signature
The signature includes metadata that points to your domain and the specific selector (more on selectors shortly) required to locate the public key.
Verification process
The receiving server extracts the selector and domain from the signature, retrieves your public key from DNS, decrypts the signature, and compares the result against the message content. If everything matches, DKIM passes. If the content was altered or the keys don’t match, DKIM fails.
What do you need before starting?
Gather these before you begin (saves frustration mid-setup):
- DNS access for your domain (through your registrar or DNS provider)
- Admin access to your email provider or ESP dashboard
- A list of every service that sends email from your domain
That last point matters more than people realize. DKIM configuration is per-sender — your marketing platform, CRM, transactional email service, and support ticketing system each need their own DKIM setup. Miss one, and emails from that service will fail authentication.
How to set up DKIM for Google Workspace
Google Workspace handles most of the complexity for you. The process takes about 10 minutes (plus DNS propagation time).
Access settings
- Sign in to the Google Admin Console
- Navigate to Apps → Google Workspace → Gmail
- Click Authenticate email
- Select your domain from the list
Generate the key
Google shows your current DKIM status. If you see “Not authenticating email,” you need to generate a key:
- Click Generate new record
- Select 2048-bit key length (recommended)
- Leave the prefix as google unless you have a specific reason to change it
Google displays the DNS record you need to add. Copy the entire TXT record value — it’s long and contains the public key.
Add DNS record
| Field | Value |
| Record name | google._domainkey.yourdomain.com |
| Record type | TXT |
| Record value | The string Google provided (starts with v=DKIM1) |
| TTL | 3600 (or your DNS provider’s default) |
The google prefix is your selector — it tells receiving servers which DKIM key to retrieve when verifying emails from Google Workspace.
Start authentication
Return to the Google Admin Console after adding the DNS record. Click Start authentication. Google verifies the record exists and begins signing outgoing emails.
If Google can’t find the record, DNS hasn’t propagated yet. Wait 15-30 minutes and try again. Full propagation can take up to 48 hours, though most changes appear within an hour.
How to set up DKIM for Microsoft 365
Microsoft’s approach differs slightly — they use CNAME records instead of TXT, and they generate two selectors for redundancy.
Access settings
- Sign in to Microsoft 365 Defender
- Navigate to Email & collaboration → Policies & rules → Threat policies
- Select Email authentication settings
- Click the DKIM tab
Generate keys
Select your domain and click Create DKIM keys. Microsoft generates two CNAME records:
| Selector | CNAME host | CNAME target |
| selector1 | selector1._domainkey.yourdomain.com | selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com |
| selector2 | selector2._domainkey.yourdomain.com | selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com |
The actual target will replace yourdomain with your domain name (hyphens replace dots).
Add DNS records
Add both CNAME records to your DNS. Microsoft requires both for DKIM to work — they use selector rotation for security.
Enable signing
After DNS propagation, return to the DKIM settings and toggle the switch to enable DKIM signing. Microsoft validates the records before activating.
How to set up DKIM for transactional email services
Every ESP that sends email on your behalf needs its own DKIM configuration. Skipping this step is one of the most common causes of DKIM failures.
SendGrid
SendGrid uses domain authentication (which includes DKIM):
- Go to Settings → Sender Authentication
- Click Authenticate Your Domain
- Select your DNS provider from the list
- Enter your sending domain
- SendGrid generates three CNAME records
| Record purpose | Format |
| DKIM selector 1 | s1._domainkey.yourdomain.com |
| DKIM selector 2 | s2._domainkey.yourdomain.com |
| Return path | em1234.yourdomain.com |
Add all three to your DNS, then click Verify in SendGrid.
Mailgun
Mailgun provides both SPF and DKIM records when you add a domain:
- Navigate to Sending → Domains
- Click Add New Domain (or select existing)
- Copy the TXT record for DKIM
The selector varies by domain. Add the record exactly as shown — Mailgun’s verification will fail if the record name or value differs.
Mailchimp
Mailchimp uses a simplified domain authentication flow:
- Go to Settings → Domains
- Click Start Authentication for your domain
- Add the CNAME record Mailchimp provides (selector is typically k1)
Other providers
Most ESPs follow the same pattern:
- Generate records in their dashboard
- Add TXT or CNAME records to your DNS
- Verify through their interface
Check your provider’s documentation for specific selectors and record formats. The selector name and record type (TXT vs CNAME) vary, but the underlying process is consistent.
How do you add DKIM records to DNS?
Regardless of which email provider generated your DKIM keys, adding them to DNS follows the same steps. The interface varies by DNS provider, but the fields are identical.
Record format
Every DKIM TXT record follows this structure:
Record name: selector._domainkey.yourdomain.com
Record type: TXT
Record value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki... (your public key)
The selector comes from your email provider. The public key (after p=) is a long base64-encoded string — copy it exactly, without line breaks or extra spaces.
Provider-specific notes
| DNS provider | Gotchas |
| Cloudflare | Leave proxy status as “DNS only” (gray cloud) |
| GoDaddy | May auto-append domain — enter only selector._domainkey |
| Namecheap | Use @ symbol rules carefully; test record name format |
| Route 53 | Enclose TXT value in quotes |
Some DNS providers automatically add your domain to the record name. If your provider does this, enter selector._domainkey instead of selector._domainkey.yourdomain.com — otherwise you’ll end up with selector._domainkey.yourdomain.com.yourdomain.com (which won’t work).
Propagation time
DNS changes aren’t instant. Most updates propagate within 15-60 minutes, but full global propagation can take up to 48 hours. If verification fails immediately after adding records, wait an hour and try again.
How do you verify DKIM is working?
Adding DNS records is only half the job — you need to confirm emails are actually being signed and verified.
Check email headers
Send a test email to yourself (or a Gmail account you control) and view the original message headers. Look for two things:
- DKIM-Signature header (proves the email was signed)
- Authentication-Results header containing dkim=pass
If you see dkim=fail or no DKIM-Signature at all, something’s misconfigured.
Use verification tools
Online tools check your DKIM record directly:
- MXToolbox DKIM Lookup — enter your domain and selector
- mail-tester.com — send an email to their test address for a full report
- Google Admin Toolbox — specifically for Google Workspace setups
These tools query your DNS and report whether the DKIM record exists and is formatted correctly.
Run a deliverability test
A free email deliverability test shows how major mailbox providers handle your emails — including whether DKIM passes. Running one after setup confirms your configuration works across Gmail, Outlook, Yahoo, and other providers.
What are common DKIM setup mistakes?
Most DKIM problems trace back to a handful of configuration errors. Knowing them up front saves debugging time.
Forgetting third-party senders
Your main email provider might be configured, but what about your marketing platform? CRM? Support desk? Each service sending from your domain needs its own DKIM setup.
Incorrect selector in DNS
The record name must match exactly what your provider expects. google._domainkey isn’t the same as Google._domainkey (DNS is case-insensitive, but some providers’ verification checks are picky about formatting).
Extra spaces or line breaks
Copying the public key from a web interface sometimes introduces hidden characters. Paste into a plain text editor first to strip formatting.
Not waiting for propagation
Testing immediately after adding a DNS record almost always fails. Give it at least an hour — preferably a few hours — before troubleshooting.
Using 1024-bit keys
Some providers still default to 1024-bit. Choose 2048-bit when available for better security (and future-proofing as requirements tighten).
What comes after DKIM setup?
DKIM is one piece of the email authentication stack. For complete protection, you’ll also need:
- SPF to authorize which servers can send for your domain — set up your SPF record
- DMARC to tell receiving servers how to handle authentication failures — configure DMARC
- Monitoring through DMARC reports to catch problems early
Together, SPF, DKIM, and DMARC form a complete authentication system — missing any one weakens the others. If the technical setup feels overwhelming (especially across multiple sending services), a free deliverability consultation can help identify gaps and ensure everything is configured correctly.
Frequently asked questions
Here are some commonly asked questions about DKIM setup:
The actual configuration takes 10-15 minutes per email provider. DNS propagation adds anywhere from 15 minutes to 48 hours before you can verify the setup is working. Plan for same-day completion, but don’t panic if verification fails in the first hour.
Yes. Every platform sending email from your domain needs its own DKIM configuration — marketing tools, CRMs, transactional email services, and support systems. Emails from unconfigured services will fail DKIM checks and may land in spam.
SPF verifies where an email came from (the sending server’s IP address). DKIM verifies who sent it and whether the content was altered (through cryptographic signatures). Both serve authentication purposes, but they check different things. You need both.
Yes — and you likely will. Each email service uses its own selector (google, s1, k1, etc.), and each selector gets its own DNS record. Multiple DKIM records for different selectors don’t conflict.
DKIM keys themselves don’t expire, but rotating them periodically (annually or when security concerns arise) is good practice. Some providers handle rotation automatically. Check your provider’s documentation for their key rotation policy.

