How to Set Up a DKIM Record Step by Step

What You Need Before Setting Up DKIM

DKIM (DomainKeys Identified Mail) verifies email integrity and origin using digital signatures. Setting it up requires three things: generating a key pair, publishing the public key in DNS, and configuring signing on your mail server. If you need a refresher on how DKIM works, read What is DKIM and How Does It Work.

Before you start, make sure you have:

• Access to your domain's DNS (DNS provider, registrar, or Cloudflare)
• Access to your email service administration (Google Workspace, Microsoft 365, or your own server)
• A working SPF record — DKIM and SPF complement each other, and both are prerequisites for deploying DMARC

Step 1: Generate a Key Pair

DKIM uses asymmetric cryptography — a private key signs outgoing messages, and a public key published in DNS allows recipients to verify the signature.

Cloud Email Services

If you use Google Workspace, Microsoft 365, or another cloud email service, you don't need to generate keys manually. The service generates them for you — you just need to activate signing in the admin console and add a DNS record. See Setting Up DKIM for Cloud Services for details.

Self-Hosted Mail Servers

On your own server, generate a key using OpenSSL or OpenDKIM. Choose a selector — a unique identifier for the key (e.g., mail2025 or s1). Selectors allow you to have multiple DKIM keys under one domain simultaneously.

Generating a 2048-bit RSA key:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -outform der | openssl base64 -A > dkim-public.txt

The first command creates a private key, the second extracts the public key in Base64 format ready for the DNS record.

Use 2048-bit keys. RFC 8301 requires a minimum of 1024-bit RSA keys and recommends 2048 bits. In practice, 2048 bits is the standard — major providers (Google, Microsoft, Yahoo) consider 1024-bit keys deprecated and are phasing out support.

Step 2: Publish the Public Key in DNS

The public key is published as a TXT record at {selector}._domainkey.{domain}:

mail2025._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM DNS Record Tags

Splitting Long Keys

DNS TXT records have a 255-character limit per string (RFC 1035). A 2048-bit key exceeds this limit. The solution depends on your DNS provider:

• Most DNS providers (Cloudflare, GoDaddy, Namecheap, and others) handle splitting automatically — you paste the entire value as one string and the system splits it for you.
• Manual splitting is only needed when editing zone files directly:

mail2025._domainkey.example.com  TXT  ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQE..."
    "...FAAOCAQ8AMIIBCgKCAQEA...")

CNAME Instead of TXT Record

Some services (Microsoft 365, SendGrid, Mailchimp) use a CNAME record instead of a direct TXT record, pointing to a DKIM key hosted on their infrastructure:

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com

The advantage of CNAME delegation: the provider can rotate keys automatically without any changes to your DNS.

Step 3: Configure Signing

Postfix + OpenDKIM (Linux)

On Postfix servers, the most common setup uses OpenDKIM:

1. Install OpenDKIM:

apt install opendkim opendkim-tools

2. Create configuration files. Main configuration /etc/opendkim.conf:

Syslog          yes
UMask           007
Domain          example.com
Selector        mail2025
KeyFile         /etc/opendkim/keys/example.com/mail2025.private
Socket          inet:8891@localhost
Canonicalization relaxed/relaxed
Mode            sv

3. Connect Postfix to OpenDKIM in /etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

4. Restart both services:

systemctl restart opendkim postfix

Key configuration parameters:

• Canonicalization relaxed/relaxed — tolerates minor changes (whitespace, header case) made by forwarding servers. Recommended over the default simple/simple.
• Mode sv — sign (outgoing) + verify (incoming).

Setting Up DKIM for Cloud Services

Google Workspace

1. Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate email
2. Select your domain and click Generate New Record
3. Choose 2048-bit key length (if your DNS provider supports it)
4. Copy the generated TXT record and add it to your domain's DNS
5. After DNS propagation (up to 48 hours), return to the Admin Console and click Start Authentication

Google uses a default selector of google. If you previously set up DKIM with a 1024-bit key, generate a new 2048-bit one and update the DNS record.

Microsoft 365

Microsoft 365 uses CNAME records instead of direct TXT records:

1. Go to Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email Authentication Settings → DKIM
2. Select your domain and click Create DKIM keys
3. Add two CNAME records to your DNS:

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com

4. After DNS propagation, toggle Sign messages for this domain with DKIM signatures to Enabled

Two selectors (selector1, selector2) allow Microsoft to rotate keys automatically.

Marketing and Transactional Platforms

If you send emails through marketing or transactional platforms (Mailchimp, SendGrid, Mailgun, Amazon SES) in addition to your main email, each service needs its own DKIM configuration:

• Each platform has a Domain Authentication section in its admin panel
• The service generates DNS records (TXT or CNAME) for you to add to your domain
• Once verified, the service signs emails with your domain's DKIM key instead of its default

Unverified services sign emails with their own domain — recipients see "signed by: sendgrid.net" instead of your domain in the headers, reducing trust and breaking DMARC alignment.

Step 4: Verify It Works

After deploying DKIM, verify that signing works correctly:

1. Send a test email to an address outside your domain (e.g., to Gmail)
2. Check the headers of the received email — look for:

Authentication-Results: mx.google.com;
    dkim=pass header.d=example.com header.s=mail2025

3. Verify the DNS record — confirm that the public key is correctly published and accessible

If the DKIM check fails, verify:

• The DNS record exists at the correct address ({selector}._domainkey.{domain})
• The p= value contains the complete public key without PEM file headers
• The selector in DNS matches the selector in the server configuration
• Enough time has passed for DNS propagation (typically under 1 hour, maximum 48 hours)

Key Rotation

You should rotate DKIM keys regularly — the recommended interval is every 6–12 months. Here's how to rotate safely:

1. Generate a new key pair with a new selector (e.g., mail2025q3)
2. Publish the new public key in DNS
3. Wait for DNS propagation
4. Switch signing to the new key
5. Keep the old DNS record for 7–14 days — emails signed with the old key may still be in delivery queues
6. After the transition period, delete the old DNS record

For cloud services:

• Google Workspace requires manual rotation — generate a new key in the Admin Console and update DNS
• Microsoft 365 rotates keys automatically thanks to the two CNAME selectors

Ed25519 as a Complement to RSA

RFC 8463 introduced Ed25519 algorithm support for DKIM signatures. Ed25519 offers shorter keys (256 bits) with higher security than RSA 2048 (comparable to RSA 3072) and significantly smaller DNS records.

Ed25519 support is not yet universal — not all receiving servers can verify it. The solution is dual signing: the server signs each message with two signatures (Ed25519 + RSA). Each algorithm requires its own selector in DNS (e.g., mail2025-ed for Ed25519 and mail2025 for RSA). Recipients that don't support Ed25519 verify the RSA signature instead.

If you run your own server and want to be future-ready, deploy dual signing. With cloud services (Google Workspace, Microsoft 365), this option is not available yet — they use RSA exclusively.

Common DKIM Setup Mistakes

Missing DKIM for All Sending Services

The most common issue: a company sets up DKIM for its main mail server but forgets about the marketing platform, helpdesk, or invoicing system. Every service sending email from your domain needs its own DKIM configuration.

Solution: Map all services that send emails from your domain. A comprehensive domain analysis shows where your emails originate from.

Outdated 1024-bit Key

If you set up DKIM years ago, you're likely using a 1024-bit key. Upgrade to 2048 bits — the process is the same as key rotation.

Syntax Error in the DNS Record

A typo in the p= value, a missing semicolon, or extra spaces in the key will cause verification to fail. Always check your record with a DNS tool after adding it.

Forgotten Step in Cloud Services

For Google Workspace, adding the DNS record is not enough — you must return to the Admin Console and click Start Authentication. For Microsoft 365, you must toggle the DKIM signing switch to Enabled. Without this step, emails are not signed even though the DNS record exists.

DKIM Setup Checklist

• All sending services mapped
• Key pairs generated (min. 2048-bit RSA)
• Public keys published in DNS
• Signing activated on server/service
• Test email sent and dkim=pass verified
• DKIM record verified with analyzer
• Key rotation schedule established (6–12 months)
• DMARC record deployed for complete protection