Domain and selector
Key
Private key paste into your MTA, then store it somewhere safe
Options
Your record
Split into quoted strings
Some DNS providers reject a value over 255 characters and expect it entered as separate quoted strings. Receivers concatenate them back together.
How it works
Private key → your MTA
Stays on the sending server. It signs each outgoing message. Never publish it, never paste it into a form.
Public key → DNS
Published at selector._domainkey as a TXT record so any receiver can verify the signature.
Receiver verifies
Reads the selector from the message header, fetches the matching public key, checks the signature holds.
Pick a selector
Any label works. Date-based ones like 2026a make rotation obvious later.
Generate or paste
Generation happens in your browser. Nothing is sent to this site.
Publish the public half
TXT at selector._domainkey, split into chunks if your provider needs it.
Install the private half
Load it into your MTA, send a test, then confirm the signature verifies.
Read this before you generate anything
If your mail leaves through Google Workspace, Microsoft 365, Zoho, SendGrid or any other hosted provider, do not use this tool to make a key. Those providers hold the private key themselves and give you a record to publish — generating your own produces a key nothing will ever sign with, and publishing it over the top of theirs breaks DKIM entirely. Use their admin console instead.
This tool exists for the other case: a self-hosted MTA such as Postfix with OpenDKIM, or a provider that asks you to supply your own public key. If you are unsure which situation you are in, the DKIM checker will find what is already published for your domain.
Generation happens in your browser
The keypair is produced by the Web Crypto API inside the page, using the same primitive your browser uses for TLS. No key material is transmitted to this site, because there is no request to transmit it in — the code runs locally and the private key exists only in the tab until you copy it out and close the page.
That said, the correct place to generate a production key is on the server that will use it, with opendkim-genkey or openssl. A browser-generated key is entirely valid, but it travels through your clipboard to get where it is going, and a key that has been in a clipboard is a key with more history than you would ideally like. Use this for testing, for providers that only accept a pasted public key, and for cases where the convenience genuinely outweighs the handling.
2048 or 1024
Use 2048. It has been the practical standard for years and every significant receiver verifies it. 1024-bit keys are considered weak and some receivers now discount them.
The reason 1024 still appears at all is a DNS constraint rather than a cryptographic one. A 2048-bit public key exceeds the 255-character limit on a single TXT string, so it must be published as multiple quoted strings. Most DNS providers handle that transparently. A few older ones do not, and 1024 is the workaround. If your provider is one of them, changing provider is a better answer than halving your key size.
Selectors and rotation
The selector is just a label that lets one domain carry several keys at once. The receiver reads it from the s= tag in the message signature and looks up selector._domainkey.yourdomain.com to find the matching public key.
Because keys are addressed by selector, rotation is straightforward and involves no downtime. Publish the new key under a new selector, switch your MTA to sign with it, then wait — mail signed with the old key may still be in transit, so leave the old record in place for a few days before removing it. Naming selectors by date makes it obvious which is current.
Publishing without breaking it
The most common mistake is the record arriving mangled. Line breaks from a copied PEM block, the -----BEGIN PUBLIC KEY----- header left in, or a provider that silently truncates at 255 characters will all produce a record that looks present and verifies as nothing.
The p= value is the base64 body only, with no headers and no whitespace. This tool strips those for you. Once published, confirm with the DKIM checker rather than assuming — a broken DKIM record fails quietly, and if DMARC is relying on it you find out through a delivery drop rather than an error.
Frequently asked questions
Is it safe to generate a private key in a browser?
The generation itself is sound — it uses the Web Crypto API, the same implementation behind TLS in your browser, and nothing is sent to this site. The handling is the weaker link: the key passes through your clipboard on the way to your server. For a production MTA, generating on the server with opendkim-genkey avoids that entirely.
I use Google Workspace. Should I use this?
No. Google generates and holds the DKIM key for you — you turn it on in the admin console and publish the record it gives you. A key generated here would never be used to sign anything, and publishing it under the same selector would break signing outright.
What selector should I choose?
Anything you like; it is only a label. Providers use conventions like google, selector1 or k1. For keys you manage yourself, a date-based name such as 2026a makes it obvious which is current when you rotate.
Why is my record split into several strings?
A single TXT string caps at 255 characters and a 2048-bit key is longer than that. The value is published as consecutive quoted strings which receivers join back together. Most DNS providers do the splitting for you — the chunk view here is for those that do not.
How often should I rotate DKIM keys?
Every six to twelve months is a reasonable rhythm for a self-managed key, and immediately if you suspect the private key was exposed. Publish the new key under a new selector first, switch signing, then remove the old record after a few days so mail still in transit can verify.
Can one domain have more than one DKIM key?
Yes, and that is exactly what selectors are for. Each sending service publishes its own key under its own selector and they coexist without conflict. This is unlike SPF, where a domain gets one record and one only.
Do I need DKIM if SPF already passes?
Publish both. DMARC passes if either aligns, so two working paths means one can break without your mail failing. DKIM also survives forwarding, which SPF does not — forwarded mail arrives from the forwarder's IP and fails SPF while the DKIM signature still verifies.
What does t=y actually do?
It marks the key as being in testing, telling receivers not to treat a failure as they normally would. It is useful while you confirm signing works, and easy to forget about afterwards — a key left at t=y indefinitely is weaker than it looks. Remove it once you have verified a signed message passes.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.