DKIM Explained: How to Set Up, Test, and Troubleshoot DomainKeys Identified Mail

What DKIM Actually Does

Every time your mail server sends a message, DKIM signs it with a private cryptographic key. The receiving server then looks up the matching public key in your DNS and uses it to verify that the message body and certain headers haven't been altered in transit. If the signature checks out, the message passes DKIM authentication. If it doesn't — or if there's no signature at all — receiving servers take note, and that affects how they score your mail.

DKIM doesn't by itself prevent spam or guarantee delivery. What it does is prove that your domain sent the message and that it wasn't tampered with after leaving your server. Combined with SPF and DMARC, DKIM is one leg of the authentication tripod every serious sender needs in place.

How the DKIM Signature Works

When your mail server signs an outbound message, it selects a set of headers — typically From, Subject, Date, and To — and hashes the message body. That hash is encrypted with your private key and added to the message as a DKIM-Signature header.

The header looks something like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail;
  h=from:to:subject:date; bh=...hash...; b=...signature...

The d= tag identifies your domain, s= is the selector (which tells receiving servers which DNS record holds your public key), bh= is the body hash, and b= is the actual signature. The receiving server fetches your public key from mail._domainkey.yourdomain.com and uses it to verify the signature matches.

Setting Up DKIM: What You Actually Need to Do

The process varies slightly depending on your mail platform, but the core steps are the same everywhere.

Step 1: Generate a Key Pair

Your mail server or email provider generates a private/public key pair. The private key stays on the server — never expose it. The public key gets published in DNS. Use at least 2048-bit RSA; 1024-bit keys are increasingly rejected by major inbox providers.

Step 2: Publish the DNS TXT Record

Create a TXT record at selector._domainkey.yourdomain.com containing your public key. A typical record looks like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA...

The selector can be anything — mail, s1, google — as long as it matches what your mail server is configured to use. You can have multiple selectors active simultaneously, which makes key rotation painless.

Step 3: Enable Signing on Your Mail Server

Point your mail server at the private key and configure it to sign outbound mail for your domain. If you're using a hosted platform like MailDog's mail service, DKIM signing is handled for you — check your account's DNS records section to get the public key value you need to publish.

Testing Your DKIM Setup

Don't assume it's working — test it before any real mail goes out. There are a few reliable approaches:

• Send to a Gmail address and open the original message. Look for dkim=pass in the authentication results header.
• Query your DNS record directly: dig TXT mail._domainkey.yourdomain.com — confirms the key is published and readable.
• Use MXToolbox's DKIM checker to validate the record and flag common syntax issues.
• Send to mail-tester.com — it gives you a full authentication breakdown including what the receiving server saw.

If the record is present but DKIM still fails, the problem is almost always one of three things: a selector mismatch, a key mismatch between what you published and what the server is using, or a configuration error on the sending server itself.

Common DKIM Failures and How to Fix Them

Body Hash Did Not Verify

Something modified the message body after it was signed. This frequently happens when a mailing list or forwarding service appends a footer or rewrites content. The fix isn't on your end — it's either configuring the list software to re-sign, or moving to an ARC-aware forwarding setup. Forwarding is a well-known source of authentication problems; the email forwarding best practices guide covers what to expect and how to handle it.

No DKIM Signature Found

Your mail server isn't signing outbound messages at all. Check that DKIM signing is enabled and that the private key path is correctly configured. For hosted solutions, confirm you've published the DNS record provided by your email platform — signing won't work until both sides are in place.

Key Too Short

If your existing key is shorter than 2048 bits, rotate to a new key. Most modern mail servers and hosted platforms generate 2048-bit keys by default, but keys created several years ago may be 1024-bit.

DNS Propagation Delay

If you just published your DKIM record, it may not be visible worldwide yet. Wait up to an hour and test again. If you have a high TTL on the record, propagation takes longer — see the guide on updating DNS records without causing downtime for TTL management strategies.

DKIM Key Rotation

Most organizations set up DKIM once and never revisit it. That's a mistake. Keys should be rotated at least annually — more frequently if you have any reason to suspect a key may have been exposed. The nice thing about DKIM selectors is that rotation doesn't require downtime: add the new key under a new selector, update your mail server configuration, let DNS propagate, then remove the old selector record. Signing is never interrupted.

DKIM and the Broader Authentication Stack

DKIM alone is valuable, but it reaches its full potential alongside SPF and DMARC. SPF tells receivers which IPs are authorized to send for your domain. DKIM proves a message hasn't been tampered with in transit. DMARC ties them together with a policy that specifies what to do when either check fails — and delivers reports showing who is sending mail using your domain.

If you're working through authentication for the first time, DKIM is typically the second thing to configure after SPF. Once both are passing, you're ready to publish a DMARC record and move toward enforcement. The DNS security overview on MailDog covers all three records and how they interact. For teams using MailDog's SMTP relay, signing is handled automatically — you publish the DNS record provided in your account and outbound mail is signed from the first send. Full configuration details are in the documentation.