DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email — acting as a tamper-proof seal that proves the message came from your domain and wasn’t altered in transit.
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 service like SendGrid. Moreover, every platform sending email from your domain needs its own DKIM configuration — miss one, and emails from that service will fail authentication.
Why does your email need DKIM?
DKIM protects your sender reputation and improves inbox placement. Without it, receiving servers have no way to verify your emails are legitimate — and increasingly, they’re rejecting unsigned messages outright.
Deliverability impact
Gmail and Outlook now enforce DMARC for bulk senders (5,000+ emails daily). One of our users put it bluntly: “Gmail and Outlook are forcing DMARC now if you’re sending bulk. Your emails will just bounce without it.”
DMARC relies on DKIM and SPF passing and aligning with your From address. Missing DKIM breaks the chain entirely. If your emails are going to spam, missing DKIM authentication is one of the first things to check.
Security benefits
DKIM provides three layers of protection:
- Spoofing prevention — attackers can’t forge your domain without your private key
- Message integrity — any tampering after signing causes verification to fail
- Reputation tracking — receiving servers associate DKIM-signed emails with your domain’s history
As one email professional noted: “DKIM is vital. It carries reputation, proves that you own the domain you send from (when it’s aligned with the From), and proves that the email wasn’t tampered with mid-transmission.”
How does DKIM authentication 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. One sysadmin recommended: “Try and generate a 2048-bit one if you have the option, as 1024-bit isn’t recommended any longer.” If your provider still defaults to 1024-bit, switch to 2048-bit for better security.
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 pointing to your domain and the specific selector 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.
| Result | What it means |
| Pass | Content matches signature — email is authentic |
| Fail | Content was altered, or keys don’t match |
| None | No DKIM signature found |
If everything matches, DKIM passes. If the content was altered (even slightly) 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 sending 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.
For self-hosted servers, one user noted: “If you send the email from a server that you administrate, you can use OpenSSL to generate the keypair.” However, most businesses use hosted providers that handle key generation automatically.
How do you 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
Navigate to the DKIM configuration:
- Sign in to the Google Admin Console
- Go to Apps → Google Workspace → Gmail
- Click Authenticate email
- Select your domain from the list
Generate key
Google shows your current DKIM status. If you see “Not authenticating email,” generate a new key:
- Click Generate new record
- Select 2048-bit key length
- 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 |
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 do you 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
Navigate to the DKIM configuration:
- Sign in to Microsoft 365 Defender
- Go 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 replaces 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 do you set up DKIM for transactional email services?
Every ESP sending email on your behalf needs its own DKIM configuration. Skipping a service 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:
| 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 fails 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 remains consistent.
How do you add DKIM records to DNS?
Regardless of which email provider generated your keys, adding them to DNS follows the same steps. One user summed it up: “DKIM is pretty straightforward on the DNS side. It’s a TXT or a CNAME with a key as its value.”
Record format
Every DKIM TXT record follows this structure:
| Component | Value |
| 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 quirks
| DNS provider | Watch out for |
| 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 append your domain to the record name. If yours does, 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. You can use propagation checker tools to see which regions have the new record.
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 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:
- Use EmailWarmup.com’s DKIM lookup for free
- 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
As one user mentioned: “You could use this to see if your DNS entry has finished propagating.” The tools query your DNS and report whether the DKIM record exists and is formatted correctly.
What are common DKIM setup mistakes?
Most DKIM problems trace back to a handful of configuration errors. Knowing them saves debugging time.
Forgetting third-party senders
Your main email provider might be configured, but what about your marketing platform? Or the CRM? And the support desk? Each service sending from your domain needs its own DKIM setup. Emails from unconfigured services fail authentication and often land in spam.
Incorrect DNS entry
One user diagnosed a common issue: “Your DNS record has multiple quotes in it. These are not in the DKIM authentication key.” Copy the public key exactly as provided — no extra quotes, whitespace, or line breaks.
The record name must also match what your provider expects. google._domainkey isn’t the same as Google._domainkey (DNS is case-insensitive, but some verification checks are picky about 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. Full propagation can take up to 48 hours in some cases.
Using weak keys
Some providers still default to 1024-bit keys. Choose 2048-bit when available for better security (and future-proofing as requirements tighten). If your provider only offers 1024-bit, consider switching to one that supports stronger keys.
Forwarding breaking signatures
Email forwarding can break DKIM if headers are modified. One sysadmin explained: “Forwarding/relaying could break DKIM, if the headers are modified the result is hash mismatches when DKIM is checked by the recipient server.”
Mailing lists, email security gateways, and auto-forwarding rules are common culprits. If DKIM passes for direct emails but fails for forwarded ones, the forwarding service is modifying the message after signing.
What comes after DKIM setup?
DKIM is one piece of the email authentication stack. For complete protection, you need all three protocols working together.
Complete the stack
| Protocol | What it does | Link |
| SPF | Authorizes which servers can send for your domain | Set up SPF |
| DKIM | Cryptographically signs message content | You’re here |
| DMARC | Tells receiving servers how to handle authentication failures | Configure DMARC |
Missing any one weakens the others. For Gmail and Yahoo bulk sender requirements, you need all three configured and aligned.
Monitor with reports
DMARC reports show which emails pass and fail authentication. Review them weekly to catch problems early — you’ll see exactly which sending services have misconfigured DKIM.
Get help
If the technical setup feels overwhelming (especially across multiple sending services), a deliverability consultant can help identify gaps and ensure everything is configured correctly.
Frequently asked questions
Here are some commonly asked questions about DKIM:
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.
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.
