If you searched for a dkim record generator because Gmail or Google Postmaster Tools is showing authentication failures, get the basic setup straight first. Our create email with your domain guide covers the full stack: MX, SPF, DKIM, DMARC, and the DNS mistakes that break delivery.
Here’s the part most web tools skip: a DKIM setup has two pieces. One public key goes into DNS. One private key stays on the system that signs mail. If a website generates both sides for you, that site had your private key in hand. That is not a harmless shortcut. It is the identity key for your domain.
This guide shows the only two sane ways to use a dkim record generator in 2025-2026: generate keys locally with OpenSSL if you run your own mail server, or use provider delegation if your mail is sent by TrekMail, Amazon SES, SendGrid, Mailgun, or Google Workspace.
What is a DKIM record generator?
A dkim record generator creates the DNS material used for DomainKeys Identified Mail. In practice, that means either generating an RSA key pair for a TXT record or giving you provider-owned CNAME records that point to the real DKIM key published elsewhere.
DKIM signs outbound mail with a private key. Receiving servers fetch the matching public key from DNS and verify the signature. That proves two things: the message was signed by an authorized sender, and the signed parts were not modified in transit.
Per RFC 8301, signers must use rsa-sha256, must use RSA keys of at least 1024 bits, and should use at least 2048 bits. That is why any serious dkim record generator today should be building around RSA 2048, not 1024.
Why random web generators are risky
A public website that offers to generate your DKIM keys is fine only if it never touches the private key. Most do. That means the convenience you gain up front can turn into a spoofing problem that lasts for years.
People treat DKIM like a DNS formatting task. It is not. It is a cryptographic identity task. The private key should live only on the mail system that signs your mail. If a third-party site creates it, logs it, or stores it, that site can theoretically sign mail as your domain later.
Public key in DNS. Private key on the signing server. If the same web form gives you both, it had the private key first.
That is the real test for any dkim record generator. Ask one question: where was the private key created, and who had access to it? If the answer is “some website,” stop.
The safe way: use OpenSSL locally
The safest dkim record generator is not a website. It is OpenSSL on your own machine or directly on the server that will sign the mail. That keeps the private key under your control from the first second.
Use this method if you run Postfix, Exim, Exchange, OpenDKIM, or another self-hosted mail stack. Generate the key locally, install the private key on the signing host, and publish only the public key in DNS.
Generate a 2048-bit RSA key pair:
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.keyYour public.key file will look like this:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----Now clean it up:
- Remove the
BEGIN PUBLIC KEYandEND PUBLIC KEYlines. - Remove all line breaks.
- Wrap the result in DKIM tags.
A manual TXT record usually looks like this:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."A raw key is not enough. A real dkim record generator must output a valid DKIM record with at least v=DKIM1 and p=. Optional tags like s=email or t=s exist, but most operators do not need them for a basic deployment.
The 255-character DNS trap
The DNS limit that breaks many dkim record generator outputs is older than modern DKIM practice. A 2048-bit RSA public key is long, and many DNS control panels still choke on it unless you split the TXT value into quoted chunks.
This is where otherwise correct setups fail. Old DNS panels may reject the record, silently truncate it, or save only part of the key. The result is usually permerror, invalid key format errors, or a dashboard that insists DKIM is broken even though your selector exists.
If your DNS provider cannot handle the full TXT string cleanly, split it into multiple quoted strings inside one TXT record:
default._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
"SecondPartOfTheSamePublicKey"
)Resolvers concatenate those strings. Receiving servers see one logical value. This is normal. A broken dkim record generator pretends the DNS panel does not matter. A useful one tells you when splitting is required.
The easy way: provider delegation beats manual key handling
For most businesses, the best dkim record generator is the one you never manage yourself. Modern providers hand you CNAME records, keep the private keys on their side, and rotate keys without asking you to touch DNS every six months.
This is the smarter path if you send through TrekMail, Amazon SES, Google Workspace, SendGrid, or Mailgun. Instead of pasting a giant TXT blob, you publish one or more selector CNAMEs. The provider publishes the actual DKIM TXT record at the target hostname.
| Approach | Old Way | New Way |
|---|---|---|
| Key creation | You create and store RSA keys manually | Provider manages keys |
| DNS record | Long TXT value | CNAME to provider selector |
| Rotation | Manual and easy to forget | Handled by provider |
| Failure mode | Syntax errors, truncation, stale keys | Mainly DNS typo or missing CNAME |
| Best fit | Self-hosted MTAs | Hosted email and SMTP platforms |
This is where TrekMail fits well. The old way is manual TXT management and periodic key surgery. The new way is provider-managed authentication with clear DNS checks. If you are adding a domain in TrekMail, start with the live DNS instructions in Adding a Domain.
TrekMail’s setup depends on how you send mail. On the Nano plan, outbound sending is BYO SMTP. On paid plans, Managed SMTP is included, starting at $3.50/month on Starter. Paid plans also offer a 14-day free trial, and that trial requires a credit card. The Nano plan does not use a trial and does not require a card.
For TrekMail users, the right dkim record generator depends on the sending path:
- If TrekMail signs the mail with Managed SMTP, use the DNS records shown in your dashboard.
- If you use BYO SMTP, the relay provider signs the mail, so you must publish that provider’s DKIM records.
- If your provider gives CNAME selectors, use them. Don’t convert them into TXT records just because a blog post said “DKIM means TXT.”
If you are deciding between forwarding, aliases, and real mailboxes, read domain email alias vs mailbox and email alias forwarding. Those choices affect who actually sends mail and therefore which DKIM path applies.
Where to publish the selector
A dkim record generator does not publish at the root of your domain. DKIM always lives on a selector host such as default._domainkey, google._domainkey, or tm1._domainkey.
This matters because DNS interfaces behave differently. Some expect only the host label. Others want the full hostname. If you enter the full domain in a panel that already appends the zone name, you end up with a doubled record like default._domainkey.example.com.example.com. That will never validate.
Common patterns:
default._domainkey
selector1._domainkey
tm1._domainkeyIf you manage many client domains, this problem multiplies fast. That is why agencies should care about repeatable DNS patterns, not one-off fixes. Our multi-domain email hosting guide goes deeper on operating email across large domain sets without losing control.
How to validate any DKIM record generator result
Never trust a green badge in a dashboard until DNS answers correctly from the command line. The quickest way to test a dkim record generator result is to query the selector directly with dig and read the response yourself.
Start with a direct lookup:
dig txt default._domainkey.example.com +shortIf the record exists, you should see the DKIM value or the quoted TXT chunks. If you just updated DNS and want to check public propagation, ask a public resolver:
dig txt default._domainkey.example.com @8.8.8.8 +shortWhat to watch for:
- No answer: wrong selector, wrong host field, or DNS has not propagated.
- Partial answer: the control panel truncated your TXT value.
- Multiple conflicting DKIM TXT records on the same selector: fix that before testing again.
- Good DNS but failing mail: inspect headers and confirm the sending system is using the same selector and private key.
If Gmail is still unhappy, Google’s current sender guidance is blunt: bulk senders need SPF, DKIM, and DMARC, and failing DKIM can trigger rate limits or rejections. See Google’s Email sender guidelines FAQ for the current enforcement details.
TrekMail users should also check the sending path. The platform’s IMAP and SMTP settings reference confirms that the Nano plan requires BYO SMTP for outbound mail, while paid plans can use TrekMail SMTP. If mail is going to spam after DNS looks correct, work through My Emails Go to Spam.
Bottom line: pick the right kind of DKIM setup
The best dkim record generator is the one that matches your mail architecture. Self-hosted servers should generate keys locally. Hosted platforms should publish the provider’s delegation records and let the provider rotate keys behind the scenes.
If you run your own MTA, use OpenSSL locally and protect the private key like production credentials. If you use TrekMail, SES, or another provider, use the records they give you. Don’t paste random keys from a web form just to make a warning light disappear.
The old way is manual DNS surgery on every domain. The new way is managed authentication, clear verification, and fewer breakpoints. That matters even more when you have multiple brands, multiple client domains, or migration work in flight. If you’re still building the stack, read forward domain email to Gmail before you forward mail blindly, then compare plans at TrekMail pricing.
A dkim record generator should not be a black box. It should be a controlled step in a mail system you understand.
