How to Configure DKIM: Generate Keys, Publish DNS, and Verify Signing

Before you generate a key

First check your sending provider's DKIM instructions. Many mailbox and email platforms generate and retain the private key themselves and give you either a TXT record or one or more CNAME records to publish. In that case, use the provider-generated records and do not create a separate key pair. Generate your own pair only when the sending system accepts a customer-supplied private key.

Inventory every system that sends as your domain and configure each separately. A mailbox provider, newsletter service, billing platform, and application mail server may each use a different selector.

1. Choose the signing domain and selector

The signing domain is the value that will appear as d= in the DKIM signature. For DMARC alignment, it normally needs to be the same as—or an organizational-domain match for—the domain in the visible From address. Confirm the exact domain with your provider.

A selector is a short DNS-safe label that identifies a key. Use a name that helps future operators understand its owner and generation date, such as google2026q3 or app1-202608. Do not reuse the same private key across unrelated providers. The complete DNS owner name will be:

SELECTOR._domainkey.EXAMPLE.COM

Example: app1-202608._domainkey.example.com

2. Generate a 2048-bit RSA key pair with OpenSSL

OpenSSL is free and available on Linux, macOS through package managers, Windows through WSL or reputable OpenSSL packages, and many server platforms. If the command is not installed, follow the OpenSSL download and installation guide. Run these commands on a trusted administrator workstation or the mail server—not in a browser-based key generator. The private key must never be pasted into an unknown website.

openssl genpkey -algorithm RSA -out dkim-private.pem \
  -pkeyopt rsa_keygen_bits:2048
openssl pkey -in dkim-private.pem -pubout -out dkim-public.pem

Use 2048 bits for new RSA keys unless your sending system or DNS host cannot support it. Do not generate a new 1024-bit key. Some providers also support Ed25519 DKIM, but support is less universal; follow the provider's instructions if it offers that option.

Restrict access to dkim-private.pem. On Linux or macOS, use chmod 600 dkim-private.pem. Store it in the sending platform's secret or key field, never in DNS, source control, a ticket, chat, or shared document. The exact private-key import interface differs by provider.

3. Convert the public key into a DKIM TXT value

The DNS value needs only the base64 data between the PEM header and footer, with all line breaks removed. This OpenSSL command prints it as one line:

openssl pkey -pubin -in dkim-public.pem -outform DER | openssl base64 -A

Put the output after p=. A typical record is:

Type:  TXT
Name:  app1-202608._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...rest_of_public_key

v=DKIM1 identifies DKIM, k=rsa identifies the key type, and p= contains the public key. Never publish the private key. Do not include the PEM header, footer, or line breaks in p=.

4. Create the DNS record

Open the authoritative DNS manager for the domain and create the record supplied by your provider or the TXT record above. Registrar interfaces differ. Some expect only app1-202608._domainkey in the Name or Host field and automatically append the domain; others accept the full name. Check the preview so the domain is not duplicated.

A 2048-bit public key makes a long TXT value. DNS permits a TXT record to contain multiple quoted character strings, each no more than 255 bytes; DNS resolvers concatenate them. If the DNS interface splits the value automatically, leave it alone. If it requires manual splitting, preserve every character and add no spaces inside the key. Create one TXT record at the selector name, not several separate TXT records.

If your provider gives you a CNAME instead, publish that CNAME exactly as supplied. A DNS name generally cannot have a CNAME alongside TXT or other record types, so remove or rename a conflicting stale selector only after confirming it is no longer used.

5. Confirm public DNS before enabling signing

Query an external resolver after the change. DNS updates may be visible quickly but cached answers can remain until their TTL expires.

# Linux or macOS
dig +short TXT app1-202608._domainkey.example.com

# Windows PowerShell
Resolve-DnsName -Type TXT app1-202608._domainkey.example.com

Confirm that the returned value begins with v=DKIM1, contains the full public key, and does not expose BEGIN PRIVATE KEY. If the lookup returns NXDOMAIN, check the authoritative nameservers and whether the DNS UI appended the domain twice.

6. Load the private key and enable DKIM signing

In the sending system, configure the signing domain, selector, canonicalization or header choices if required, and the private key. Provider screens differ, so follow its documentation for this step. Prefer the provider's defaults unless you operate your own mail transfer agent and understand the interoperability impact.

Enable signing only after the public key is resolvable. If the platform offers a verification button, use it. Keep the selector, provider, signing domain, creation date, owner, and rotation date in your sender inventory.

7. Send a real message and inspect the result

Send from the configured path to an external mailbox. View the original message headers and locate DKIM-Signature. Confirm its d= value is the intended signing domain and its s= value is the new selector. Then check the receiver's Authentication-Results header for dkim=pass.

A DNS lookup alone proves only that a key was published. A signed test message proves that the sender used the matching private key and that the signature survived delivery. Also confirm DMARC alignment rather than assuming that any DKIM pass is enough.

Common failure modes

The DNS host appended the domain twice.
Whitespace, a missing character, or a PEM header was copied into p=.
The selector in DNS does not match s= in the signature.
The sender is signing with a provider domain that does not align with the visible From domain.
A gateway or mailing-list transformation changed signed content.
Two unrelated TXT records exist at the same selector name.

Safe operating rules

Generate and handle keys only on trusted systems.
Use a unique selector and key per provider or sending system.
Back up the private key only if your recovery design requires it, and encrypt that backup.
Never email, publish, log, or commit the private key.
Rotate immediately if a private key may have been exposed.
Remove an old public key only after no mail is being signed with it.

Rotate without interrupting mail

Generate a new key under a new selector, publish it, verify DNS, and then switch the sender to the new selector. Test until new messages pass. Keep the old public key in DNS long enough for delayed or queued messages signed with the old key to be verified; use your mail-flow characteristics and provider guidance to choose the overlap. Then remove the retired selector and update the inventory.

There is no universal calendar interval mandated by DKIM itself. Follow provider policy and your organization's cryptographic key-management standard, and rotate whenever a key is suspected of compromise, an operator with key access leaves, or a sending system is replaced.

Completion checklist

Every active sender has its own documented selector.
The private key exists only in approved protected storage and the sender.
The public TXT or provider CNAME resolves externally.
A real delivered message shows the expected d= and s= values.
Authentication-Results reports dkim=pass and DKIM aligns for DMARC.
The old selector, if any, has a dated retirement plan.

Where Lappu AI fits

Teams that want help inventorying senders, validating DKIM and DMARC alignment, or planning a safe rotation can review the email security work at Lappu AI.