DKIM Setup Guide: Sign Your Email So Inboxes Trust It

DomainKeys Identified Mail, or DKIM, is the second of the three email authentication standards, sitting between SPF and DMARC. Where SPF publishes a list of servers allowed to send for your domain, DKIM goes a step further: it attaches a cryptographic signature to every message, so the receiving server can prove two things at once. First, that the message really came from your domain. Second, that nobody altered the important parts of it along the way.

Get DKIM right and you give Gmail, Outlook, and Yahoo a strong, tamper-proof reason to trust your mail. Get it wrong, or skip it entirely, and you leave a gap that hurts deliverability and blocks you from running a real DMARC policy. This guide walks through what DKIM actually does, how to publish the record, and the mistakes that silently break signing.

What DKIM actually is

DKIM works with a pair of cryptographic keys. You keep a private key on your sending platform, and you publish the matching public key in your domain’s DNS. When you send a message, your provider uses the private key to generate a signature over selected headers and the body, then stamps that signature into the message as a DKIM-Signature header.

When the message arrives, the receiving server reads the signature header, sees which domain and selector to check, looks up the public key in DNS, and verifies the signature. If the math checks out, the server knows the message was signed by someone holding your private key and that the signed content was not changed in transit.

A published DKIM record is a TXT record at a special hostname built from a selector. It looks something like this:

selector1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg..."

The p= value is the public key. The selector (here selector1) lets you run more than one key at a time, which matters when you rotate keys or send through multiple platforms. The receiving server learns the exact selector to use from the DKIM-Signature header on the message itself, so it always knows where to look.

Why DKIM is worth setting up today

Three reasons stand out.

First, deliverability. The major mailbox providers now treat authentication as a baseline expectation. Since Google and Yahoo tightened their bulk sender rules, unsigned mail is far more likely to be filtered or throttled. DKIM is one of the strongest trust signals you can send, because it proves message integrity, not just server identity.

Second, tamper protection. SPF can confirm that a message came from an approved server, but it says nothing about whether the content changed. DKIM covers that gap. If a forwarder or attacker rewrites the signed headers or body, the signature breaks and the receiver knows the message is no longer trustworthy.

Third, it is required for DMARC alignment. A DMARC policy only passes when SPF or DKIM authenticates and aligns with the visible From domain. In practice DKIM is the more reliable of the two for alignment, because it survives forwarding far better than SPF does. If you want DMARC to actually protect your domain, DKIM is not optional.

How to publish a DKIM record, step by step

The exact clicks differ by platform, but the shape of the process is always the same.

1. Generate the key pair in your sending platform. In Google Workspace, Microsoft 365, SendGrid, Mailgun, or whatever you use to send, find the DKIM or email authentication settings and generate a signing key. The platform keeps the private key and hands you a public key plus a selector.

2. Publish the public key in DNS. The platform will show you a hostname (something like selector1._domainkey.yourdomain.com) and a value starting with v=DKIM1. Add that as a TXT record, or a CNAME pointing to the provider if that is what they give you, in your DNS host.

3. Wait for propagation, then turn on signing. DNS changes can take anywhere from a few minutes to a few hours to spread. Once the record resolves, return to your platform and enable DKIM signing so it starts stamping the header on outgoing mail.

4. Verify with a real message. Send a test to an inbox you control, open the message headers, and confirm you see dkim=pass. Most providers also expose a check button that queries DNS and confirms the key is live.

If you use more than one platform to send (say a marketing tool plus your regular mailbox), each one needs its own selector and its own published key. Do not try to force two platforms through a single selector.

The mistakes that quietly break DKIM

DKIM tends to fail in ways that are easy to miss, because a broken signature does not bounce the message. It just erodes trust in the background.

• Truncated public key. RSA keys are long, and some DNS interfaces split them into multiple quoted strings or cut them off. If even one character is wrong, verification fails. Copy the full value carefully.
• Wrong record type. Some providers give you a CNAME to point at their hosted key rather than a TXT record with the key inline. Publish exactly what they specify.
• Signing turned off after setup. Plenty of teams publish the DNS record but forget the final switch that tells the platform to actually sign. No signature header means nothing to verify.
• Weak or stale keys. A 512-bit or 768-bit key is too weak to trust. Use at least 1024-bit, and 2048-bit where your platform supports it. Rotate keys periodically and retire old selectors.
• Body changes in transit. Aggressive footer injection by a mailing list or a security appliance can alter the signed body and break the signature. Keep signing as close to the final send as possible.

A quick habit that saves headaches: whenever you add a new sending tool, treat DKIM setup as part of onboarding that tool, not an afterthought. The selector, the key, and the verified dkim=pass should all be confirmed before you send your first real campaign.

Where authentication ends and list quality begins

DKIM, SPF, and DMARC together prove that your mail is genuinely yours and arrives intact. That is a huge part of deliverability, but it is only half the story. Authentication tells a mailbox provider the message is legitimate. It does nothing about whether the address you are sending to is real.

You can sign every message perfectly and still tank your sender reputation by blasting a list full of dead, mistyped, or catch-all addresses. High bounce rates and spam-trap hits tell providers you do not maintain your list, and no amount of DKIM will outrun that signal. This is where list hygiene does the work that authentication cannot. Running your contacts through Scrubby before a send clears out invalid and risky addresses, including the catch-all addresses that most verification tools skip, so the clean, authenticated mail you send actually has somewhere trustworthy to land.

The same discipline applies to cold outreach, where reputation is even more fragile. If you book meetings by sending calendar invites through a tool like Kali, pairing that outreach with validated recipient lists keeps your signing domain healthy and your invites out of the spam folder. Authentication and clean data are not competing priorities. They are two halves of the same deliverability strategy, and you need both.

The short version

DKIM signs your outgoing mail with a private key and publishes the matching public key in DNS, so receivers can confirm the message came from you and was not altered. Generate the key in your sending platform, publish the TXT or CNAME record it gives you, enable signing, and verify a real message shows dkim=pass. Watch for truncated keys, the forgotten signing switch, and weak key lengths. Then finish the job on the data side: authenticate every message, keep your list clean with Scrubby, and your domain earns the inbox placement it deserves.