Emails landing in spam, getting rejected outright, or failing authentication checks at Gmail, Outlook, and Yahoo are almost always traceable to one missing piece: DKIM. DomainKeys Identified Mail is a cryptographic signature that proves an email actually came from your domain and was not tampered with in transit. Without it, receiving mail servers have no reliable way to trust your messages, and their spam filters will treat you accordingly. This guide covers exactly what DKIM is, why it matters, how to generate the keys, where to add the DNS record, how to verify the setup, and what to do when things go wrong.

What DKIM Is and Why It Matters

DKIM works by attaching a digital signature to every outgoing email. Your mail server signs the message with a private key that only you control. The receiving server then looks up your public key in DNS, uses it to verify the signature, and decides whether the message is legitimate. If the signature checks out, the email passes DKIM authentication. If there is no signature, or the signature does not match, the message is more likely to be flagged or rejected.

DKIM does not encrypt the message body. It signs a hash of selected headers and the body, so any modification during transit breaks the signature and alerts the receiving server. Combined with SPF and DMARC, DKIM forms the backbone of modern email authentication. Google and Yahoo made DKIM a hard requirement for bulk senders in 2024, and Microsoft followed with its own enforcement policies shortly after. Even for low-volume senders, missing DKIM is a direct hit to your sender reputation.

The Two Pieces of DKIM: Private Key and DNS Record

Before touching any settings, understand the architecture. DKIM requires a matched key pair:

  • Private key — stored on your mail server or email service provider. Never shared publicly.
  • Public key — published as a TXT record in your domain's DNS. Anyone can look it up to verify signatures.

The DNS record lives at a specific subdomain format: selector._domainkey.yourdomain.com. The selector is just a label you choose (common choices are default, google, s1, or mail). You can have multiple selectors for different mail streams, which is useful when you send from both your own mail server and a third-party service like Mailchimp or SendGrid.

Step 1: Generate Your DKIM Keys

How you generate keys depends on your mail platform. The three most common scenarios are covered below.

Google Workspace (Gmail)

Google generates the key pair for you. Log in to the Google Admin console at admin.google.com, go to Apps > Google Workspace > Gmail > Authenticate email, select your domain, choose a key length of 2048 bits, and click Generate New Record. Google will display the TXT record value you need to add to DNS. Do not click Start Authentication yet — add the DNS record first.

Microsoft 365 (Exchange Online)

Go to the Microsoft Defender portal at security.microsoft.com, navigate to Email and Collaboration > Policies and Rules > Threat Policies > Email Authentication Settings, then click the DKIM tab. Select your domain and click Create DKIM keys. Microsoft will provide two CNAME records (not TXT records) pointing to Microsoft's infrastructure. Publish both CNAMEs in DNS, then return to the portal and toggle DKIM signing to Enabled.

Self-Hosted Mail Servers (Postfix, Exim, Sendmail)

Use OpenDKIM to generate keys directly on the server. Install the package and generate a 2048-bit key pair with a selector of your choice:

sudo apt install opendkim opendkim-tools sudo mkdir -p /etc/opendkim/keys/yourdomain.com sudo opendkim-genkey -b 2048 -d yourdomain.com -D /etc/opendkim/keys/yourdomain.com -s mail -v sudo chown opendkim:opendkim /etc/opendkim/keys/yourdomain.com/mail.private

This produces two files: mail.private (keep this secret, used by the mail server to sign) and mail.txt (the public key formatted as a DNS TXT record, ready to copy).

Third-Party Email Services (SendGrid, Mailchimp, Postmark, etc.)

Every major ESP generates DKIM keys on your behalf and provides you with TXT or CNAME records to add to DNS. Log in to your ESP dashboard, find the domain authentication or sending domains section, and follow the prompts. SendGrid calls it Sender Authentication. Mailchimp calls it Domain Verification. Postmark calls it Sender Signatures. The pattern is the same: they give you a record, you add it to DNS.

Step 2: Add the DKIM TXT Record to DNS

Log in to wherever your domain's DNS is managed — your registrar (Namecheap, GoDaddy, Google Domains, Cloudflare, etc.) or your hosting provider's DNS panel. Create a new TXT record with the following values:

  • Name/Host: mail._domainkey (replace mail with your actual selector; some panels require the full subdomain: mail._domainkey.yourdomain.com)
  • Type: TXT
  • Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq... (paste the full public key string provided by your mail platform)
  • TTL: 3600 (one hour is fine for initial setup; you can lower it temporarily if you need to troubleshoot)

A typical DKIM TXT record value looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a7T8y3z Q4vXsL5kP1mNwRjKoHdU6bFcTeYsVpZnXqGlMrOiAeD9fWuJsBtC ...

Important: Some DNS panels break long TXT records incorrectly. If your registrar has a character limit per string, you may need to split the key into multiple quoted strings. Most modern panels handle this automatically when you paste the value, but if verification fails later, this is the first thing to check.

After adding the DKIM record, DNS changes can take minutes to 48 hours to propagate worldwide. Use the DNS Propagation Checker to monitor when your new TXT record is visible across global resolvers before enabling signing.

Step 3: Enable DKIM Signing on Your Mail Server

For Google Workspace, return to the Admin console and click Start Authentication. For Microsoft 365, toggle DKIM to enabled in the Defender portal. For self-hosted Postfix with OpenDKIM, configure the integration:

# /etc/opendkim.conf Domain yourdomain.com KeyFile /etc/opendkim/keys/yourdomain.com/mail.private Selector mail Socket inet:8891@localhost Mode sv Subdomains no # /etc/postfix/main.cf (add these lines) milter_default_action = accept milter_protocol = 6 smtpd_milters = inet:localhost:8891 non_smtpd_milters = inet:localhost:8891

Then restart both services:

sudo systemctl restart opendkim sudo systemctl restart postfix

Step 4: Verify Your DKIM Setup

Never assume the setup worked — verify it. There are two layers to check: the DNS record itself, and whether outgoing emails are actually being signed.

Check the DNS Record

Use dig or nslookup from the command line to confirm the record is published:

dig TXT mail._domainkey.yourdomain.com +short # Expected output: "v=DKIM1; k=rsa; p=MIIBIjAN..."

If you get no output, the record has not propagated yet or was entered incorrectly. Double-check the name/host field in your DNS panel — a common mistake is adding an extra domain suffix, resulting in mail._domainkey.yourdomain.com.yourdomain.com.

You can also use the DNS Lookup tool to query the TXT record from multiple locations and confirm the value matches what your mail platform expects.

Check Actual Email Signatures

Send a test email to a Gmail account and open the message. Click the three-dot menu in the top right of the message and select Show original. Look for the authentication results header near the top:

Authentication-Results: mx.google.com; dkim=pass header.i=@yourdomain.com header.s=mail header.b=Ab12Cd34; spf=pass (google.com: domain of user@yourdomain.com designates ...) dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

You want to see dkim=pass. If you see dkim=fail or dkim=neutral, move to the troubleshooting section below. You can also use mail-tester.com or MXToolbox's email header analyzer for a more detailed breakdown.

Common DKIM Problems and How to Fix Them

DKIM Signature Verification Fails

The most common cause is a mismatch between the private key used to sign and the public key published in DNS. This happens when someone regenerates the DKIM keys in the mail platform but forgets to update the DNS record, or when the DNS record was copy-pasted incorrectly and the public key value is truncated or corrupted. Regenerate the key pair, copy the new public key carefully, update the DNS record, wait for propagation, and test again.

The Record Is There But DKIM Still Fails

Some mail servers alter the message body after signing — disclaimers added by email gateways, mailing list software, or antivirus scanners are common culprits. The body hash changes, breaking the signature. If you use a mail gateway or relay, make sure DKIM signing happens after any content modification, or configure the gateway to resign messages. In Microsoft 365 environments, transport rules that add footers must be placed before the DKIM signing step.

Long Key Values Getting Truncated

2048-bit DKIM keys exceed 255 characters, which is the limit for a single DNS TXT string. The key must be split into multiple quoted strings. Most DNS providers handle this transparently when you paste the value, but some do not. If your DNS provider's panel is stripping characters, try entering the key split into two strings:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a7T8y" "3zQ4vXsL5kP1mNwRjKoHdU6bFcTeYsVpZnXqGlMrOi..."

Multiple Selectors Causing Confusion

If you have previously set up DKIM with a different selector and are now deploying a new one, both records can coexist in DNS without issue. The selector is embedded in the DKIM-Signature header of each email, so receiving servers know exactly which DNS record to look up. Clean up old, unused selectors eventually, but they will not break anything in the short term.

DKIM Alone Is Not Enough: Pair It with SPF and DMARC

DKIM is one leg of a three-legged stool. SPF (Sender Policy Framework) specifies which IP addresses are allowed to send mail for your domain. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when SPF or DKIM checks fail, and sends you reports about authentication results across the internet. A domain with only DKIM configured but no DMARC policy gives spammers more room to abuse your domain in header-from phishing attacks. The recommended deployment order is: set up SPF first, then DKIM, then publish a DMARC policy starting with p=none to collect reports, then gradually move to p=quarantine and eventually p=reject.

How to Prevent DKIM Issues Going Forward

  • Use 2048-bit keys minimum. 1024-bit keys are considered weak and some mail systems will reject them outright. Rotate to 2048-bit or 4096-bit if you are still on 1024.
  • Rotate keys annually. Best practice is to generate a new key pair once a year. Add the new selector to DNS, update your mail platform, verify signing, then remove the old selector from DNS after a few days.
  • Document your selectors. Keep a record of which selectors are active for which mail streams. As you add more sending services, this list grows quickly.
  • Monitor DMARC reports. DMARC aggregate reports (sent to the email address in your DMARC record's rua tag) will alert you immediately if a new sending source is not signing correctly.
  • Test after any infrastructure change. Migrating mail servers, changing MTAs, or updating your email service provider can break DKIM silently. Always send a test message and check the headers after any significant mail infrastructure change.

DKIM is not optional for serious email senders in 2024 and beyond. The setup takes under an hour for most platforms, the DNS change is a single TXT record, and the deliverability improvement is immediate and measurable. Get it done, verify it, then layer on DMARC to complete your authentication stack.