DKIM Key Generator: Create, Publish, and Test It Right

If you need a dkim key generator, you probably have one of two problems: your domain isn’t signing mail yet, or it is signing mail and receivers still don’t trust it. Both are bad. Unsigned mail gets filtered harder. Misconfigured DKIM breaks DMARC. At that point, password resets, invoices, and sales mail start landing in spam or disappearing into quarantine.

That’s the ugly part. The fix is simpler than most guides make it sound. A dkim key generator creates a private key for your mail server and a matching public key you publish in DNS. Receiving servers use that public key to verify that the message really came from a system allowed to sign for your domain and that the signed content wasn’t changed in transit.

If you’re still setting up your full mail stack, start with our pillar on business email. If you already run mail on your own domain, this guide will show you what a dkim key generator should output, which key size to use, how selectors work, and how to publish the record without breaking delivery.

What a DKIM key generator actually does

A dkim key generator creates a cryptographic key pair. The private key stays on the sending system and signs outgoing messages. The public key goes into DNS under a selector so receiving servers can verify the DKIM signature in each message header.

A lot of tools pretend this is magic. It isn’t. A good dkim key generator does three things:

1. Creates a private key your sender can use.
2. Extracts the matching public key.
3. Formats that public key into a DNS TXT record you can publish under selector._domainkey.example.com.

That’s it. The hard part is not the math. The hard part is getting the selector, DNS host, line wrapping, and sending system lined up so the signature validates in production.

Per RFC 6376, DKIM relies on selectors so you can publish more than one key and rotate them cleanly. Per RFC 8301, signers must use RSA keys of at least 1024 bits, and 2048-bit keys are the better default now. If your dkim key generator still pushes 512-bit or SHA-1-era advice, close the tab.

What the output should look like

A proper dkim key generator gives you a private key for signing and a DNS-safe public key record. The DNS record lives at a selector hostname, not at the root of your domain, and it must contain the public key in the p= tag.

Here’s the shape you’re aiming for.

Host: tm2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

And here’s a basic OpenSSL workflow if you want to generate the pair yourself instead of relying on a web-based dkim key generator.

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
openssl rsa -in dkim-private.pem -text -noout

Then convert the public key to the single-line value most DNS panels want:

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' dkim-public.pem \
| sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//g'

If your DNS provider splits long TXT values into quoted chunks, that’s usually fine. If it inserts spaces into the middle of the key, that’s not fine. That one mistake wastes hours.

Conceptual example: the selector is the label on the key, not the key itself. If your signature says s=tm2026, the receiver will look up tm2026._domainkey.yourdomain.com. If that record doesn’t exist, DKIM fails.

How to choose the right selector and key size

The best dkim key generator is the one that produces a 2048-bit key, uses RSA with SHA-256, and lets you pick sane selector names for rotation. Selectors are operational labels. Treat them like version tags, not random decoration.

Use selector names that tell you when and where the key is used. Good examples:

• tm2026
• app1q1
• marketing2026

Bad examples:

• default forever
• test in production
• dkim reused across every sender

RFC 8301 is blunt: 1024 bits is minimum, 2048 bits should be used. Google is blunt too. Its sender guidance says bulk senders need DKIM and SPF, and at least one of SPF or DKIM must align with the From domain for direct mail to personal Gmail accounts. You can read that in Google’s sender guidelines FAQ.

So when you pick a dkim key generator, don’t ask whether it can create a key. Every tool can. Ask whether it pushes you toward a 2048-bit key, clear selector naming, and easy rotation. That’s what matters in production.

How to publish the DNS record without breaking mail

A dkim key generator is only half the job. The other half is publishing the TXT record at the exact selector hostname your sender uses, waiting for DNS to propagate, and then turning signing on only after the public key is reachable.

This is where people break things:

1. They publish the TXT record at @ instead of selector._domainkey.
2. They paste the full PEM wrapper into DNS instead of only the base64 key.
3. They enable signing before DNS is live.
4. They use the wrong selector in the mail platform.

If you’re setting up a domain inside TrekMail, the platform already expects the right record pattern in the DNS workflow. TrekMail’s domain setup docs show the required records, including a unique DKIM TXT value under Adding a Domain. After you save the records, use the built-in verification flow. If DNS still looks wrong, the DNS status checker is the next stop.

TrekMail also calls out a detail many admins miss: if your SPF fails on forwarded mail but DKIM passes, DMARC can still pass. That matters because forwarding is where SPF alone falls apart. Their spam troubleshooting guide says exactly that in plain language: SPF fail plus DKIM pass is often expected on forwarded traffic. See forward domain email to Gmail if you want the forwarding side of that problem.

How to test whether the DKIM key is actually working

After you use a dkim key generator and publish the record, test with real headers. Don’t stop at “DNS looks fine.” The only result that counts is a message with dkim=pass and domain alignment that satisfies DMARC for the mail you actually send.

Send a message to a Gmail mailbox and inspect the original headers. You want to see something like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tm2026 header.b=...
       spf=pass smtp.mailfrom=example.com
       dmarc=pass header.from=example.com

If DKIM fails, work the checklist in order:

1. Check the s= selector in the DKIM-Signature header.
2. Look up that exact DNS host with dig.
3. Confirm the public key in DNS matches the private key loaded on the sender.
4. Confirm your sender is signing the right domain in d=.
5. Check whether a mailing list, footer injector, or relay modified signed headers or body content.

dig +short TXT tm2026._domainkey.example.com

This is where a bad dkim key generator wastes time. Some tools generate the key but don’t explain what the selector host should be, how to validate it, or what alignment means. You end up with a key in DNS and still fail DMARC because the d= domain doesn’t match the visible From domain.

If you’re debugging a broader setup, these related guides help fill in the gaps: create email with your domain, email forwarding, and TrekMail’s spam troubleshooting doc.

Old way vs new way: DIY DKIM across tools vs one controlled workflow

The old way is juggling a random dkim key generator, a DNS panel, one SMTP vendor for app mail, another for newsletters, and a half-finished DMARC policy. It works until someone changes providers, rotates a key badly, or forwards mail through a path that breaks SPF and exposes that DKIM was never set up right.

The new way is using one platform to manage the domain, mailbox layer, DNS checks, and sender configuration in the same workflow.

With TrekMail, that means:

• Custom domains and IMAP mailboxes in one dashboard.
• BYO SMTP on the Nano plan, or included managed SMTP on paid plans.
• Built-in migration for pulling old mail over IMAP.
• Catch-all, mailbox forwarding, and API access where the plan includes it.
• A DNS/authentication workflow built for SPF, DKIM, and DMARC instead of bolting them on later.

That matters more if you manage multiple domains. If you’re an agency or MSP, per-user pricing is already annoying. Broken authentication across dozens of domains is worse. TrekMail’s pricing starts at $3.50/month for Starter, with a free plan at $0 for up to 10 domains and 5GB if you bring your own SMTP. Paid plans include a 14-day free trial, and that trial does require a credit card. The Nano plan does not.

If you also need to migrate old mail while fixing authentication, TrekMail’s IMAP migration workflow pulls mail from Gmail, Microsoft 365, or generic IMAP into a TrekMail mailbox without forcing you to rebuild the whole estate by hand.

Best practices for rotation, revocation, and long-term maintenance

A dkim key generator is not a one-time checkbox. You should rotate keys on purpose, retire old selectors cleanly, and keep separate selectors for different senders when that reduces blast radius and makes troubleshooting easier.

Use this operating model:

1. Generate a new 2048-bit key with a new selector.
2. Publish the new public key in DNS.
3. Switch the sender to sign with the new selector.
4. Verify new mail shows dkim=pass.
5. Keep the old selector published long enough for queued mail to clear.
6. Remove the old public key after the transition period.

If a private key is ever exposed, don’t debate it. Replace it. That’s another reason a versioned selector strategy beats default forever.

A final point: a dkim key generator won’t fix bad sending practices. Authentication is table stakes. Reputation still matters. Google’s current guidance says bulk senders should keep spam complaints under control, authenticate with SPF and DKIM, and use DMARC. TrekMail’s own deliverability docs say the same thing in practical terms: keep DNS green, warm up the domain, and don’t blast cold traffic on day one.

Conclusion: use a DKIM key generator, but don’t stop there

A dkim key generator is the start, not the win. The win is a working selector, a published public key, a sender using the matching private key, and live mail that returns dkim=pass with DMARC alignment.

If you want the shortest path, generate a 2048-bit key, use a versioned selector, publish the TXT record correctly, and test against real headers. If you’re tired of doing that across multiple providers and domains, move the workflow into one place. TrekMail gives you custom domains, IMAP mailboxes, pooled storage, built-in IMAP migration, and a standards-first DNS/auth setup without per-user fees. You can start free at trekmail.net or compare plans at trekmail.net/pricing.