MXCorrect

← Blog · August 9, 2026

DKIM Explained: How It Works and How to Set It Up

DKIM (DomainKeys Identified Mail) proves a message wasn’t altered in transit and really did come from a server authorized to send on your domain’s behalf. Unlike SPF, which checks the sending IP, DKIM checks a cryptographic signature — which makes it survive forwarding, something SPF can’t do.

How DKIM actually works

  1. Your mail server generates a public/private key pair.
  2. The public key is published in DNS as a TXT record at selector._domainkey.yourdomain.com.
  3. Every outgoing message gets signed with the private key, adding a DKIM-Signature header containing the signature and which headers/body were signed.
  4. The receiving server looks up the public key using the selector named in that header, and verifies the signature matches.

If the signature verifies, the receiver knows the message wasn’t tampered with after signing, and that it genuinely passed through a server holding the private key.

What a DKIM record looks like

default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

The selector (here, “default”) lets you run multiple keys at once — useful for key rotation or for giving different sending platforms their own key.

Setting it up

1. Generate a key pair through your sending platform

Most email services (Google Workspace, Microsoft 365, SendGrid, Postfix/OpenDKIM) generate the key pair and give you the exact DNS record to publish — you rarely write the raw key yourself.

2. Publish the TXT record

Add it exactly as provided, at the selector subdomain given. A single extra space or line break in the public key value is enough to break verification.

3. Verify propagation before enabling signing

Query the record directly before turning on signing at the sending platform, so you’re not signing mail with a key nobody can verify yet:

dig TXT default._domainkey.yourdomain.com

4. Rotate keys periodically

Because the private key lives on your sending infrastructure, rotate it if you switch providers or on a routine schedule (yearly is common). Publish the new selector’s public key before switching signing over, so there’s no gap.

Common DKIM mistakes

  • Missing selector record — the sending platform is signing mail, but the DNS record was never published or was published at the wrong hostname.
  • Truncated public key — some DNS providers split long TXT values incorrectly. Verify the full key resolves as one continuous string.
  • Signing headers that get rewritten — mailing list software and some forwarders modify the Subject or body, breaking the signature. Use relaxed canonicalization (c=relaxed/relaxed) to tolerate minor formatting changes.
  • Forgetting DKIM ≠ DMARC alignment — DKIM passing isn’t enough on its own; the signing domain (the d= value) needs to align with your visible From: domain for DMARC to count it.