How to Set Up DKIM

Setting up DKIM means putting two halves in place: a private key your sending system uses to sign mail, and a matching public key published in DNS so receivers can verify those signatures. This guide walks through the full sequence. If you want the concepts behind each step first, read what is DKIM. When you are done, confirm everything with the DKIM record checker.

Step 1: Get a Key Pair

There are two paths, and which one you take depends on your sending setup.

Path A: Your provider generates the key

Most senders use an email service provider, and the provider generates the key pair for you. It keeps the private key on its own infrastructure and shows you the public key (or a record to publish) during domain verification. In this case you do not generate anything yourself; you collect the selector and the value the provider gives you. For example, Google Workspace generates its key in the admin console under the selector google, and Microsoft 365 uses the selectors selector1 and selector2.

Path B: You generate the key yourself

If you run your own mail server, you generate the pair. Create a 2048-bit RSA key pair, keep the private key readable only by the mail server, and extract the public key for DNS. RFC 8301 recommends 2048 bits for new keys; 1024 bits is only the minimum that must remain supported, and its security margin is thin by current standards. Choose a selector name at this point, for example mail or a dated label like s2026, since you will need it for both the DNS hostname and the signer configuration.

Step 2: Publish the Public Key in DNS

The public key goes into a TXT record. The hostname matters as much as the value. The record must live at the selector, then the fixed label _domainkey, then your domain:

mail._domainkey.example.com

A realistic record, with the key shortened for readability, looks like this:

Type:  TXT
Name:  mail._domainkey.example.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArZ3kQm9X...IDAQAB

The tags mean:

• v=DKIM1 declares the record version. It is optional, but if present it must be the first tag.
• k=rsa states the key type. RSA is the default, so the tag is sometimes omitted.
• p= carries the public key as base64 text. This is the longest part and the one most often damaged by copy-and-paste mistakes, stray quotation marks, or line breaks added by a control panel.

A 2048-bit RSA public key, encoded as base64, is longer than the 255-character limit of a single DNS string, so it must be split into multiple quoted strings that resolvers join back together. Most DNS hosts handle this split automatically; just paste the value as one continuous string without manual line breaks.

If your provider uses CNAME delegation

Many providers ask you to publish a CNAME rather than a TXT record. Instead of placing the key in your zone, you create an alias such as em123._domainkey.example.com pointing to a hostname in the provider's DNS, where the real TXT record lives. The advantage is that the provider holds the private key and can rotate it without asking you to change DNS again. Two rules: a hostname carrying a CNAME cannot carry any other record, and watch for control panels that append your domain automatically, producing doubled names like em123._domainkey.example.com.example.com.

Step 3: Enable Signing

Publishing the public key does nothing on its own; your sending system must actually sign messages. With a provider, this is the toggle you flip once domain verification succeeds, after which it starts adding the DKIM-Signature header to outgoing mail. On a self-hosted server, you configure the signer with the private key, the selector, and the signing domain so it emits a header with matching d=, s=, and b= tags. Make sure the selector in the signer exactly matches the selector you published in DNS, or verification will fail even though both halves are correct.

Step 4: Verify

Do not assume it worked. Confirm it two ways:

1. Look up the record with the DKIM record checker, using your selector and domain. It flags syntax damage in the p= value, which is the usual culprit.
2. Send yourself a real message and open the full headers. Confirm a DKIM-Signature header is present and that its d= tag matches your domain.

Remember DNS caching: after publishing or fixing a record, verifiers may see the old version until the TTL expires, so retest after that window. If DKIM passes but DMARC still fails, the likely cause is alignment, the d= domain not matching your From domain. Enabling custom-domain signing with your provider resolves it.

Step 5: Key Length and Rotation

Use 2048-bit RSA for any new key, as RFC 8301 recommends. If a checker reports a 1024-bit key, treat it as a candidate for rotation.

DKIM keys should not live forever. A private key can leak through a compromised server, a departing employee, or a vendor you stop using, and an attacker holding it can sign mail as your domain until the public key leaves DNS. Rotation is straightforward precisely because selectors exist:

1. Generate a new key pair and publish the new public key under a new selector.
2. Switch your signer to the new key.
3. Leave the old record up briefly so messages still in transit can verify, then retire it. Deleting the old selector too soon fails mail still on the wire.

To retire a key cleanly, revoke it rather than just deleting the record. RFC 6376 defines a record with an empty p= value as an explicit revocation:

v=DKIM1; k=rsa; p=

This is clearer than removing the record outright: a missing record looks the same as a DNS outage or a typo, while an empty p= tells every verifier, unambiguously, that signatures from this selector must no longer be trusted. After a suspected compromise, publish the empty-key record immediately. Providers using CNAME delegation typically rotate for you automatically, with no action needed on your end.

Summary

Get a 2048-bit key pair, publish the public half as a TXT record at selector._domainkey.yourdomain, enable signing with a matching selector, verify with the DKIM record checker, and rotate through new selectors over time. For the cryptographic background behind each step, see what is DKIM.