What tools and methods are available to generate DKIM public and private keys?
Updated on 18 Oct 2026: We clarified DKIM key generation and added steps for safe selector rotation and private-key replacement.
Use OpenSSL for most manual DKIM key generation, OpenDKIM when configuring a Linux mail server, and the sending platform's own DKIM setup when it provides managed selectors with TXT or CNAME records. Use a web-based DKIM generator for testing; for production, generate keys locally or use the sender's managed setup.
The private key signs outbound mail and must stay private. The public key goes into DNS under a DKIM selector, for example selector1._domainkey.example.com. The common production choice is RSA 2048-bit, which RFC 8301 recommends. RSA 1024-bit meets the standards minimum but is not recommended for new selectors. RSA 4096-bit creates larger DNS answers and still needs explicit support from the signer and DNS host.
- Best default: Generate the key pair locally with OpenSSL, then paste only the public key into DNS.
- Server setup: Use OpenDKIM's key generator when OpenDKIM will also sign the mail.
- Managed sender: Use the sender's admin console when it gives you managed selectors with TXT or CNAME records.
- Validation step: After publishing DNS, check the selector and send a signed message.
Compare DKIM key generation methods
Microsoft Defender portal DKIM setup screen with domain selector status and CNAME values.
There are five common methods to generate or provision DKIM public and private keys: a command-line cryptographic tool, a mail-server package, a sending provider console, a hosting control panel, or a web-based DKIM generator. The right choice depends on who will sign the mail and who controls DNS. Before generating keys, confirm DNS editing access and whether the email service provider (ESP) accepts imported private keys.
|
|
|
|
|---|---|---|---|
OpenSSL | Local, scriptable generation | PEM key pair | Format choices need care |
OpenDKIM | Linux mail server setup | Private key and TXT | Package install required |
Provider console | Hosted mail and sending platforms | DNS values | Provider manages private key |
Web generator | Testing or training | Key pair | Trust boundary matters |
Control panel | Managed hosting | DNS values | Signing tied to hosting setup |
Compact comparison of DKIM key generation options.
Local generation keeps private-key custody under your control and produces repeatable commands with predictable output. Provider-generated DKIM is also appropriate when the provider keeps the private key inside its signing system and asks you to publish DNS records.
Keep control of the DKIM private key
The DKIM key generator is less important than the path the private key takes after generation. If an untrusted party receives the private key, replace it. Transfer a key to a trusted signing service only through its supported secure import process.
Local generation
- Custody: The private key stays on a trusted machine or signing service.
- Repeatability: The same command can be scripted for future selectors.
- Format control: You can output PKCS#1 or PKCS#8 as the signer requires.
Managed senders and web generators
- Speed: The setup is fast when the tool also formats the DNS value.
- Convenience: Provider consoles often publish CNAME targets instead of raw keys.
- Risk: A server-side web generator has seen the private key.
Private key rule
Never paste an existing production DKIM private key into a public tool. If a public generator creates a private key for you, treat that private key as shared with the tool operator unless you trust its code and have verified that generation happens locally in your browser with no key material transmitted.
- Safe path: Generate locally, store the private key with the signing service, and publish only DNS.
- Testing path: Use web generators for lab domains, disposable selectors, or learning the DNS format.
Keep key generation separate from DKIM validation. The generator creates the material. Validation proves that DNS, selector naming, signing, and message headers all work together.
Generate the key pair with OpenSSL
OpenSSL creates the cryptographic key pair locally. These commands use OpenSSL 3 or later. For a platform that wants a PKCS#1 RSA private key in PEM format, use -traditional so the private key begins with -----BEGIN RSA PRIVATE KEY----- rather than the generic -----BEGIN PRIVATE KEY----- header.
OpenSSL RSA DKIM key generationbash
umask 077 openssl genrsa -traditional -out selector1.private 2048 openssl rsa -in selector1.private -pubout -out selector1.public
Use unused filenames because these commands overwrite existing files. The restrictive umask limits access to newly created key files. After installation, give the signing service account access and keep other users out. Keep the private key in the mail signing system and out of source control. The public file has to be transformed into the value inside the DKIM DNS record. Remove the PEM header, footer, and line breaks from the public key before placing it after p=. Keep the DNS record syntax clean because copied quotes, spaces inside the key, and wrapped lines create hard-to-see failures.
Extract the public key bodybash
sed -n '/BEGIN PUBLIC KEY/!{/END PUBLIC KEY/!p}' selector1.public \ | tr -d '\r\n'
The public key can be derived again from the existing private key with the second command, so a missing public-key file does not require a new key pair. If a platform rejects a valid-looking key, first identify whether it wants PKCS#1 or PKCS#8. For a deeper key-size check, the related check key length workflow is useful after the DNS value is published.
Generate Ed25519 keys when the signer supports them
RFC 8463 defines Ed25519-SHA256 for DKIM, with a much shorter public key than RSA. Use it only when the signing software explicitly supports Ed25519 DKIM and accepts the private-key format produced by OpenSSL.
OpenSSL Ed25519 DKIM key generationbash
umask 077 openssl genpkey -algorithm ED25519 -out selector2.private openssl pkey -in selector2.private -pubout -outform DER \ | tail -c 32 \ | openssl base64 -A
For the Ed25519 DER output produced above, the raw public key is the final 32 bytes. The last command prints those bytes as 44 base64 characters. Put that value after p= in a record that includes k=ed25519. Do not publish the full DER or PEM public-key document as the DKIM value.
Ed25519 DKIM DNS record shapedns
selector2._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=ed25519; p=BASE64_RAW_PUBLIC_KEY" )
Transition without dropping RSA
For a compatibility transition, attach both RSA-SHA256 and Ed25519-SHA256 DKIM signatures. Each algorithm needs a different selector because one selector name must resolve to one key record.
Use OpenDKIM when the mail server is yours
OpenDKIM is a practical method when the same environment will generate the key and sign mail. The generator creates a private key file and a DNS TXT record file, which reduces manual conversion work. Configure RSA signing to use rsa-sha256; RFC 8301 prohibits rsa-sha1.
OpenDKIM selector generationbash
umask 077 opendkim-genkey -b 2048 -h sha256 -s selector1 -d example.com
That command creates files similar to selector1.private and selector1.txt. Configure the OpenDKIM KeyTable entry to reference the private file's path, and the SigningTable entry to select it for the intended mail. Set file ownership and permissions so OpenDKIM's service account can read the private key. The TXT file gives the DNS value. Inspect the TXT output before publishing because DNS panels handle quotation marks and long strings differently.
When OpenDKIM is the right fit
- Good fit: You run an MTA where OpenDKIM handles signing.
- Less fit: A third-party sender will sign mail and only needs you to publish DNS records.
Generate DKIM keys through an ESP or hosting panel
Many hosted senders do not ask you to generate a raw private key. They either create selectors for you or ask you to publish CNAME records that point to provider-managed DKIM records. In that model, the provider stores the private signing key and you publish the public key or DNS delegation that authorizes signing for your domain.
Provider-managed DKIM key generation, DNS publication, and email signing workflow.
This is usually the right answer for hosted sending platforms because the sender has to sign the message. A private key that sits outside the sender's infrastructure does not help unless the sender lets you upload it. If a platform asks for your own private key, confirm the required key type, key size, PEM format, and encryption requirements before involving the DNS administrator. In a hosting control panel, use the domain's email authentication settings when that host sends the mail.
- Confirm selector: Use the provider's selector exactly. If choosing your own, give each sender a distinct selector within the signing domain.
- Publish DNS: Add the TXT or CNAME record exactly as the sender provides it.
- Enable signing: Turn on DKIM in the sender after DNS has propagated.
- Test message: Send real mail and inspect the DKIM result in the headers.
Fix PKCS#1 and PKCS#8 private key errors
A platform can reject a key with a message like "not a valid PKCS#1 RSA private key in PEM format" even when the key material is valid, because the platform expects a specific file format.
PKCS#1 private key
This starts with -----BEGIN RSA PRIVATE KEY-----. Older mail systems and strict upload forms often ask for this format.
PKCS#8 private key
This unencrypted format starts with -----BEGIN PRIVATE KEY-----. Modern tooling often emits this wrapper by default.
Convert PKCS#8 to PKCS#1bash
umask 077 openssl rsa -traditional -in input.pem -out dkim.pkcs1.pem
Convert PKCS#1 to unencrypted PKCS#8bash
umask 077 openssl pkcs8 -topk8 -nocrypt -in dkim.pkcs1.pem -out dkim.pkcs8.pem
These examples write unencrypted private keys. Confirm the signer's encryption requirements and restrict file access. If the system still refuses the file, check whitespace before the header, the final newline, file encoding, and line endings. Also confirm the upload expects the private key, not the public DNS value.
RSA DKIM key length choices
A practical benchmark for RSA DKIM key length selection.
Standards floor
1024-bit
Do not use for new selectors.
Recommended
2048-bit
Use for most production selectors.
Extra large
4096-bit
Check signer and DNS support first.
Publish the public key cleanly
The DKIM public key becomes a DNS TXT record unless the provider gives you CNAME records. The hostname is the selector plus _domainkey plus the signing domain. The value usually starts with v=DKIM1, uses k=rsa when the default key type needs to be explicit, and must include p= followed by the public key.
RSA DKIM TXT record template (replace abbreviated key)dns
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
The example is a zone-file template; replace the abbreviated p= value with the full public key. In a DNS control panel that appends example.com automatically, enter selector1._domainkey as the host. Add either the requested CNAME or TXT record at that hostname, because a CNAME cannot coexist with TXT data.
DNS TXT character strings are limited to 255 octets, so a 2048-bit RSA record is often split into quoted chunks inside one TXT record. DNS clients concatenate those chunks without added spaces. Some DNS panels split the value automatically, while others require manual chunks. Publish only one TXT record for each selector name because multiple records make the lookup result undefined. The public key after p= must not contain literal spaces, stray quotes, or copied PEM header text.
DNS handoff checklist
- Host: Send the exact selector hostname instead of only the root domain.
- Value: Send the full TXT or CNAME value in a copy-safe format.
- TTL: Use a modest TTL during setup, then raise it after validation.
- Owner: Name the sender that will use the selector so stale records are easier to retire.
Validate the selector and watch real mail
A published DKIM record alone does not prove outbound mail is being signed. The signer has to use the matching selector, the d= signing domain has to be correct, and the signed headers and canonicalized body must still verify after transit. Validate in two passes: first DNS, then a real sent message.
After the TXT record is live, validate the selector with the DKIM checker. Then send mail through the actual platform and inspect the receiving server's Authentication-Results header to confirm DKIM passed for the expected domain. Check the s= selector and d= signing domain in DKIM-Signature against the published DNS hostname.
For a local check, query DNS with dig. On a host with OpenDKIM utilities, opendkim-testkey can also compare the published public key with the local private key. These checks do not prove that outbound mail is being signed.
Query DNS and check the local OpenDKIM key pairbash
dig +short TXT selector1._domainkey.example.com opendkim-testkey -d example.com -s selector1 -k selector1.private -vvv
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For DMARC, also check DKIM alignment. Under relaxed alignment, the d= signing domain and the visible From domain must share the same organizational domain. Under strict alignment, they must match exactly. A DKIM cryptographic pass with an unrelated signing domain does not satisfy DMARC's DKIM requirement. DMARC can also pass through SPF when SPF passes with the required domain relationship.
If the record validates but live mail fails, also check for a mismatch between the private key and the published public key. Other causes include disabled signing, an incorrect selector, a wrong signing domain, or changes to signed content in transit.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
For a broader check, use the domain health checker because DKIM rarely operates alone. A domain can have a clean DKIM record and still have weak SPF, missing DMARC reporting, or an authentication gap on a subdomain.
Rotate DKIM keys without interrupting delivery
Use a planned selector rotation process. Choose a schedule based on the sender's key-management controls and the guidance in DKIM key rotation. A lost private key cannot be recovered from its DNS public key; generate a replacement key pair.
- Generate a new key pair under an unused selector, or start the managed sender's rotation process.
- Publish the new public key and confirm it resolves through the DNS resolvers used for testing before switching signing. Allow for DNS caching.
- Switch the signer to the new key and selector, send a test message, and confirm DKIM passes for the expected domain.
- Keep the old public key available through the sender's maximum delivery-retry window and a suitable validation margin. Retire it after mail signed with the old key has cleared; DNS TTL alone is not the delivery window.
If the private key is exposed, stop using it and remove or revoke its public key promptly instead of preserving the normal overlap. A revoked key has an empty p= value. Cached DNS answers remain usable until they expire.
Where Suped fits in the workflow
Key generation is a setup task. Ongoing authentication work includes reviewing DKIM results by sending source and checking whether DKIM failures affect DMARC outcomes. Suped's DMARC reporting product supports that monitoring workflow.
Suped processes DMARC aggregate reports so teams can review SPF and DKIM results by sending source. Review results after a selector change to spot senders whose authentication has deteriorated. Aggregate reports arrive after receiving servers process mail, so use live-message checks during setup.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Use OpenSSL, OpenDKIM, or a provider console to create the DKIM material, then use Suped's DMARC monitoring to review whether reported traffic passes authentication with the required domain relationship.
Practical workflow
- Generate: Create the DKIM key pair locally or in the sender's trusted console.
- Publish: Add the DNS TXT or CNAME record exactly as required.
- Verify: Check the selector, then send a real message through the platform.
- Monitor: Review reported authentication results and investigate legitimate sources that fail.
Frequently asked questions
OpenSSL is the practical general-purpose choice because it generates keys locally and gives control over PEM format. OpenDKIM fits when it will also sign mail on the server. A provider console fits when the provider manages DKIM signing.
Use a web generator only for non-production tests or training. For production, generate the private key locally or let the sending provider manage it. The private key should not pass through an untrusted public tool.
Check the signer's required key type, PEM wrapper, and encryption requirements. PKCS#1 RSA private keys use a -----BEGIN RSA PRIVATE KEY----- header; unencrypted PKCS#8 keys use -----BEGIN PRIVATE KEY-----. Convert to the required format and retry.
No. DNS gets only the public key, usually in a TXT record under the selector hostname. The private key stays with the signing system that sends the mail. A lost private key cannot be recovered from the DNS public key; generate a replacement pair.
Yes, 2048-bit RSA is the practical default for most DKIM selectors. A 1024-bit key meets the standards minimum but should not be used for a new selector. Use 4096-bit only after confirming that the signer and DNS provider support it reliably.
Generate an Ed25519 key only when the signing software explicitly supports Ed25519-SHA256. Use a separate selector and keep an RSA-SHA256 signature during a compatibility transition.
