Setting Up a DKIM Record for Email Security

Proving that an email genuinely came from your domain — and that nobody altered it in transit — is the foundation of email trust. DomainKeys Identified Mail (DKIM) is the widely adopted standard for email authentication that provides that proof, and it's one of the strongest defenses against phishing and email spoofing. By publishing a DKIM record in your domain's DNS, you let receiving servers verify your outgoing mail and improve its deliverability. This guide walks through creating a DKIM record end to end, then covers the best practices and troubleshooting that keep it working.

Understanding DKIM

What is DKIM?

DKIM, short for DomainKeys Identified Mail, is an email authentication protocol that lets senders attach a cryptographic signature to their messages. That signature — added as a header field — lets the recipient's mail server verify the message's origin and detect any modification made in transit. When the signature validates, the recipient can be confident the mail is authentic and unaltered. DKIM works alongside SPF and DMARC: SPF authorizes which servers may send for you, DKIM proves integrity and origin, and DMARC ties both back to the visible From: address.

How does DKIM work?

DKIM relies on a pair of cryptographic keys. The private key stays on your sending mail server and is used to sign each outgoing message; the matching public key is published in your DNS for anyone to read. When you send mail, your server hashes selected headers and the message body, encrypts that hash with the private key, and inserts the result as a DKIM-Signature: header. That header also records the signing domain (d=) and the selector (s=), which tells receivers exactly where to find the public key.

On the receiving side, the mail server reads the d= and s= values, fetches the public key from ._domainkey.yourdomain.com, and recomputes the hash. If its result matches the decrypted signature, DKIM passes — the message provably came from a holder of the private key and wasn't changed. If the signature is missing, the key can't be found, or the body was altered, DKIM fails. Because the signature travels with the message, DKIM survives forwarding better than SPF does.

Creating a DKIM record

Now that the mechanism is clear, here are the steps to create a DKIM record for your domain.

The DKIM setup flow: generate a key pair, publish the public key in DNS, then test.

Step 1: Generate the key pair

• Choose a key size. Use a 2048-bit RSA key. RFC 8301 requires signers to use at least 1024 bits and recommends at least 2048, and 2048-bit keys satisfy the Gmail and Yahoo bulk-sender rules. Don't go below 1024 bits — many verifiers reject those outright.
• Generate the private key. Most email platforms generate the key pair for you when you enable DKIM; if you generate it yourself, store the private key somewhere secure, since it can sign mail on behalf of your domain.
• Derive the public key. The same tool or platform produces the matching public key that you'll publish in DNS.

Step 2: Publish the DKIM record

• Open your DNS settings. Log in to wherever you manage DNS — your registrar or DNS host.
• Add a TXT record. DKIM is published as a TXT record. Create a new one at the host ._domainkey.yourdomain.com, using the selector your sending platform assigned.
• Enter the value. The value contains v=DKIM1, the key type (k=rsa), and the public key itself in p=. Paste the exact value your platform provided — a single altered character invalidates every signature.

Step 3: Test and validate

• Wait for propagation. DNS changes take time to spread, governed by the record's TTL — often minutes, occasionally longer.
• Send a test message. Once the record is live, send mail from your domain to an address you control.
• Check the headers. Inspect the received message's headers for the DKIM-Signature and an Authentication-Results line showing dkim=pass.
• Validate with a lookup tool. Confirm the published record and signing status with the DKIM lookup tool, or check SPF, DKIM, and DMARC together with the Email Security Score.

Best practices for DKIM implementation

Ongoing practices that keep a DKIM setup secure and effective.

• Rotate keys with selectors. Publish a new key under a fresh selector, switch your signer to it, then remove the old one once no in-flight mail depends on it — zero downtime. Rotating every six to twelve months is reasonable.
• Protect the private key. Store it securely, limit access to authorized personnel, and audit that access periodically.
• Monitor authentication results. Watch for DKIM failures in your DMARC reports; a sudden rise can signal a misconfiguration or an abuse attempt.
• Combine DKIM with SPF and DMARC. DKIM is one piece of the puzzle. Pair it with SPF and a DMARC policy so receivers know what to do when a check fails.
• Sign every stream. Give each sending service — mailbox provider, marketing platform, ticketing tool — its own selector and key so each authenticates independently.

Common issues with DKIM

Why does DKIM pass but DMARC still fails?

Almost always an alignment problem. DMARC needs the DKIM d= domain to align with the visible From: domain. A message signed by d=mailer.vendor.com for a From: of yourdomain.com produces a valid signature that DMARC still rejects. See why DKIM fails alignment for the fix.

My record is published but receivers say "no key for signature."

The selector in your DNS host doesn't match the selector your mail server is signing with, or the record hasn't propagated. Confirm the host is exactly ._domainkey.yourdomain.com and that the selector matches the s= tag in your DKIM-Signature header.

The public key value was split or truncated.

Some DNS providers cap the length of a single TXT string, and a 2048-bit key can exceed it. Paste the value as your provider instructs — many accept the full string, while others require it split into quoted chunks that the resolver reassembles. A missing character breaks validation entirely.

DKIM worked, then suddenly started failing.

A gateway, mailing list, or forwarder that modifies signed headers or the body after signing invalidates the signature. It can also mean a key rotation removed the old selector while mail signed with it was still in flight. Retire old selectors only after that mail has cleared.

Frequently asked questions

Do I need a separate DKIM key for each sending service?

Yes — give each service its own selector and key. That way every stream authenticates independently, and you can revoke or rotate one without disturbing the others.

Does DKIM encrypt my email?

No. DKIM signs a hash so tampering is detectable, but the message body still travels in plain text unless the connection is separately protected with TLS. DKIM is about authenticity and integrity, not confidentiality.

How long does a DKIM DNS change take to take effect?

It's governed by the record's TTL, not a fixed clock. Resolvers that cached an older record serve it until their copy expires; with a short TTL that's minutes.

Is 1024-bit DKIM still acceptable?

It meets the bare minimum, but 2048-bit is the current recommendation and the practical standard for passing major mailbox providers. Move to 2048 bits when you next rotate keys.

Conclusion

Publishing a DKIM record is an essential step toward stronger email security and recipient trust. Generate a 2048-bit key, publish the public key as a TXT record under the right selector, and verify that receivers report dkim=pass. Then keep it healthy with key rotation, monitoring, and alignment checks alongside SPF and DMARC. If you send through Microsoft 365, follow the provider-specific steps in how to set up DKIM in Office 365.