What tools and methods are available to generate DKIM public and private keys?
The practical answer is that I use OpenSSL for most manual DKIM key generation, OpenDKIM when I am configuring a Linux mail server, and the sending platform's own DKIM setup when that platform provides managed selectors or CNAME records. Web-based generators such as Dkimcore.org, Port25 DKIM Wizard, and SocketLabs DomainKey DKIM Generation Wizard are useful for testing or simple setups, but I do not treat a public web page as the best place to create production private keys unless the trust boundary is clear.
The private key signs outbound mail and must stay private. The public key goes into DNS under a selector such as selector1 at _domainkey. The most common production choice is RSA 2048-bit. RSA 1024-bit is too small for new deployments, and 4096-bit causes DNS and provider support problems often enough that I only use it when the signer and DNS host both support it cleanly.
- 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 selectors, TXT records, or CNAME records.
- Validation step: After publishing DNS, check the selector and send a signed message.
Direct answer
Microsoft Defender portal DKIM setup screen with domain selector status and CNAME values.
There are four real methods available to generate DKIM public and private keys: a command-line cryptographic tool, a mail-server package, a sending provider console, or a web-based DKIM generator. The right choice depends on who will sign the mail and who controls DNS.
|
|
|
|
|---|---|---|---|
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 | Microsoft 365, Google Workspace, SES | DNS values | Provider controls selector |
Web generator | Testing or low-risk setup | Key pair | Trust boundary matters |
Control panel | Plesk or cPanel hosting | DNS values | Less portable |
Compact comparison of DKIM key generation options.
For production systems, the strongest method is local generation. It gives you custody of the private key, predictable output, and repeatable commands. Provider-generated DKIM is also a strong option when the provider keeps the private key inside its own signing system and asks you to publish DNS records. The weakest pattern is generating a production private key on a random public page and then uploading that same private key into another platform.
How the common methods compare
The DKIM key generator is less important than the path the private key takes after generation. If the private key leaves a controlled environment, the key has to be treated as exposed. That does not mean every web generator is broken. It means the risk model changes, and I prefer a method where the private key is created on the same host or admin workstation that will handle it.
Local generation
- Custody: The private key starts and stays on a controlled machine.
- Repeatability: The same command can be scripted for future selectors.
- Format control: You can output PKCS#1 or PKCS#8 as the signer requires.
Web or provider generation
- 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 have verified that generation happens locally in your browser and no key material is 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.
This is why I separate key generation 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 is the most flexible method because it creates the cryptographic key pair without involving a third party. For a platform that wants a PKCS#1 RSA private key in PEM format, I use the traditional RSA wrapper so the private key begins with BEGIN RSA rather than the generic BEGIN PRIVATE header.
OpenSSL RSA DKIM key generationbash
openssl genrsa -traditional -out selector1.private 2048 openssl rsa -in selector1.private -pubout -out selector1.public
The private file belongs in the mail signing system. 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 '\n'
On modern OpenSSL builds, different commands produce different PEM wrappers. If a platform rejects a valid-looking key, do not regenerate blindly. 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.
Use OpenDKIM when the mail server is yours
OpenDKIM is the cleanest 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.
OpenDKIM selector generationbash
opendkim-genkey -b 2048 -s selector1 -d example.com
That command creates files similar to selector1.private and selector1.txt. The private file goes into the OpenDKIM key table. The TXT file gives the DNS value. I still 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 Postfix, Sendmail, or another MTA where OpenDKIM handles signing.
- Less fit: A third-party sender will sign mail and only needs you to publish DNS records.
When provider consoles generate the key
Many hosted senders do not ask you to generate a raw private key. Microsoft 365, Google Workspace, Amazon SES, and many email platforms either create selectors for you or ask you to publish CNAME records that point back to provider-managed DKIM records. In that model, the provider owns the private signing key and you publish the DNS proof that authorizes it for your domain.
Flowchart showing a sender creating a DKIM key, DNS publication, signing, and DKIM passing.
This is usually the right answer for SaaS 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, and PEM format before involving the DNS administrator.
- Create selector: Use a clear name such as s1, selector1, or a date-based selector.
- 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.
Handle PEM and PKCS format problems
The error that trips people up is usually not DKIM itself. It is the private key wrapper. A platform can reject the 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. Older mail systems and strict upload forms often ask for this format.
PKCS#8 private key
This starts with BEGIN PRIVATE. Modern tooling often emits this wrapper by default.
Convert PKCS#8 to PKCS#1bash
openssl rsa -traditional -in input.pem -out dkim.pkcs1.pem
If the system still refuses the file, check for three things before blaming the generator: pasted whitespace before the header, missing final newline, and Windows line ending handling. Also confirm the upload expects the private key, not the public DNS value. I have seen all of those cause the same general class of error.
DKIM key length choices
A practical benchmark for RSA DKIM key length selection.
Legacy
1024-bit
Replace for new deployments.
Recommended
2048-bit
Use for most production selectors.
Extra large
4096-bit
Use only after checking sender and DNS support.
Key length also ties into rotation. I prefer a planned selector rotation process over emergency replacement, especially when several senders use the same domain. The related DKIM key rotation guide covers the operational part.
Publish the public key cleanly
The DKIM public key becomes a DNS TXT record unless the provider gives you CNAME records. The hostname is selector plus _domainkey plus the signing domain. The value starts with v=DKIM1 and normally includes k=rsa and p= followed by the public key.
DKIM DNS TXT record shapedns
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
DNS providers show long TXT records differently. Some require one long string. Some split the value into quoted chunks and concatenate them correctly. The critical rule is that the actual 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 DKIM DNS record can exist and still not protect mail. The signer has to use the matching selector, the domain in the d= tag has to be right, and the message has to survive body canonicalization after signing. That is why I validate in two passes: first DNS, then a real sent message.
After the TXT record is live, I validate the selector with the DKIM checker. Then I send mail through the actual platform and inspect the Authentication-Results header to confirm DKIM passed for the expected domain.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the record validates but live mail fails, the key generator was not the issue. The problem is usually signing disabled, the wrong selector in the sending system, a subdomain mismatch, or a message modification after signing.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
For a broader check, I also 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.
Where Suped fits in the workflow
Key generation is a setup task. Ongoing authentication work is the harder part: watching which sources sign, catching selector mistakes, seeing when a sender stops signing, and knowing whether DKIM failures affect DMARC outcomes. This is where Suped's product is designed to fit.
For most teams, Suped is the best overall DMARC platform because it brings DKIM, SPF, DMARC, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability signals into one workflow. In Suped's product, I can review authentication results, see verified and unverified sources, get real-time alerts, and move policy forward without turning every DNS change into a manual audit.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The practical split is simple: use OpenSSL, OpenDKIM, or a provider console to create the DKIM material, then use Suped's DMARC monitoring to see whether the real traffic is authenticated and protected. That matters more than whether the original key came from one generator or another.
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: Watch real authentication traffic and fix sources that fail.
Views from the trenches
Best practices
Local keys: Generate production private keys locally, then publish only the public value.
Format check: Confirm whether the signer expects PKCS#1, PKCS#8, or provider DNS values.
DNS handoff: Send selector, host, TTL, and TXT value together to reduce setup delays.
Common pitfalls
Wrong PEM: A valid key still fails when the platform expects a different wrapper.
Quoted key: Extra quotes inside the public key break DNS even when the record saves.
Lost signer: Publishing DKIM in DNS does nothing until outbound mail is signed properly.
Expert tips
Rotate calmly: Add the new selector, verify signing, then retire the old one later.
Keep scope: Use separate selectors so one sender change does not block all mail.
Validate live: Test a sent message because DNS checks cannot prove signing is active.
Marketer from Email Geeks says OpenSSL gives the cleanest path when a platform asks for a private key in a strict PEM format.
2025-03-18 - Email Geeks
Marketer from Email Geeks says OpenDKIM is reliable when you run the signing service and want the DNS TXT file created with the private key.
2025-05-07 - Email Geeks
My practical recommendation
If a system asks me to generate a DKIM public and private key, I start with OpenSSL and create a 2048-bit RSA key locally. If the system demands PKCS#1 PEM, I use the traditional RSA output or convert the key before upload. If I run the mail server myself, I use OpenDKIM because it creates the private key and TXT record in the same workflow.
If the sender provides managed DKIM, I use that instead of creating my own private key. That usually means publishing TXT or CNAME records and enabling signing in the sender console. Web generators are fine for testing, but for production I want local key creation or provider-managed key custody.
The key generator is only the first decision. The real finish line is a DNS record that validates, live mail that signs with the right selector, and monitoring that shows DKIM passing across actual sending sources.
