Free tool · no signup
Free DKIM record generator
Generate a DKIM key pair in your browser and get the record to publish. First it asks who signs your mail, because most email platforms make the key themselves and will not accept one you built. Finding that out here costs a click. Finding it out after publishing costs a working selector.
Ungated · no email required · nothing is ever transmitted
In short
- This is a free, ungated DKIM record generator. It creates the key pair your mail is signed with and builds the TXT record that publishes the public half at selector._domainkey on your domain.
- Most people searching for a DKIM generator should not use one. Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, Brevo, Mailchimp, Zoho, Klaviyo and HubSpot all generate the key pair themselves and offer no way to install one you made. You need a generator when you run the signer yourself, on Postfix with OpenDKIM, Rspamd, Exim or PowerMTA, or when the platform takes a key you supply, which among the large platforms means Amazon SES through its BYODKIM option.
- The key pair is generated in your browser with the Web Crypto API. The private key is never transmitted, stored or logged, which also means it cannot be recovered once the tab is closed. For a production signer, generating the key with OpenSSL on the machine that will use it remains the better habit, and those commands are printed on this page.
- RSA at 2048 bits is the right default. RFC 8301 requires verifiers to support it, every major provider now issues it, and it is the largest key Amazon SES accepts for BYODKIM. Keys below 1024 bits must be rejected by verifiers, so they authenticate nothing.
- Publishing a key on a selector that is already in use replaces the working key, and every signature made with the old one fails until the old record expires from resolver caches. Nothing warns you, because from your own DNS the new record looks correct. This generator checks the selector against live DNS while you type it.
- Every record this tool emits carries h=sha256. The h tag lists the hash algorithms a key may be used with, and its default is to permit all of them, including the SHA-1 that RFC 8301 deprecated for DKIM in 2018.
- At 2048 bits the record is about 392 characters, past the 255 octets a single DNS character-string may carry, so it is published as two adjacent strings. Most DNS panels do that for you; the BIND output on this page is already split correctly for the ones that do not.
Who signs your mail?
This decides whether you should generate a key at all. Most email platforms create the pair themselves and give you no way to install one you made, so a key built here would authenticate nothing.
Start by saying who signs your mail
It is the question that decides everything else on this page. For most email platforms the answer is that you do not need a generator at all, and finding that out here costs a click rather than a broken selector.
Authentication gets you accepted, not delivered
A verified signature stops your mail being rejected. Reputation decides whether it reaches the primary inbox. SmartReach warms your mailboxes, rotates them, and verifies every address before a campaign sends.
14-day free trial · no credit card
The question nobody asks first
How to generate a DKIM record, in four steps
An SPF record is yours to write. A DMARC record is yours to write. A DKIM record is the public half of a key pair, and it is worth exactly nothing unless the private half is installed wherever your mail is signed. That is why a DKIM key generator should open with a question rather than a key length dropdown, and why the first of these four steps is the one that decides the other three.
Say who signs your mail
This comes first because for most answers it ends the process. If your platform generates its own key, we send you to their instructions rather than handing you one you cannot install.
Name the selector
The label the key is published under, and the thing that makes rotation possible later. We check live DNS while you type it, so you never publish over a key something is already signing with.
Generate the pair
RSA at 2048 bits by default, created in your browser and never transmitted. The public half becomes the record, and the private half is yours to install and to keep.
Publish, then check what landed
Publish the TXT record and ask the tool to read it back. It compares what your DNS actually serves against the key generated here, which is the only way to catch a value your panel quietly truncated.
Checked against each vendor's own documentation
Can I use my own DKIM key with Google Workspace, Microsoft 365 or my sending platform?
Eleven of the platforms below make the key themselves, so nothing built here can be installed on them. Read your own row before you generate anything. This table answers one question only, which is who holds the private key. For the steps to switch DKIM on where your mail lives, each row links to whoever owns that answer, and our own walkthroughs for Google Workspace and Microsoft 365 go step by step.
You run the signer
Nobody is going to hand you a key, because the software doing the signing is yours. This is the case this page exists for.
| Platform | What it does instead |
|---|---|
| Postfix with OpenDKIM | OpenDKIM signs with a private key file you point it at in KeyTable. Nothing generates it for you, which is exactly the case this generator is for. Their setup guide |
| Rspamd | The dkim_signing module reads keys from a path or a map you provide. The key is yours to create and to rotate. Their setup guide |
| Exim | Exim signs when dkim_private_key is set on the remote_smtp transport, alongside dkim_domain and dkim_selector. You supply the file. Their setup guide |
| PowerMTA | PowerMTA signs from a key file named in the domain-key directive, one per selector and domain. You create the pair. |
| Something else, or my own code | Whether the generator is right for you comes down to one question: does the thing that sends your mail have a field or a file path for a DKIM private key? If it does, generate the pair below. If it only shows you a record to publish, the key is already theirs and you must use the one they give you. |
They sign with a key you supply
The platform does the signing, and takes a private key you generated. This is what a generator is for.
| Platform | What it does instead |
|---|---|
| Amazon SES | SES is the exception among the big platforms. Easy DKIM generates the key for you, but BYODKIM takes a private key you supply, in PKCS #1 or PKCS #8 PEM at 1024 to 2048 bits, and then you publish one TXT record at the selector you chose. Generate a 2048-bit RSA key below. Their setup guide |
They generate the key, and will not take yours
These platforms create the pair themselves and never show you the private half. A key generated anywhere else cannot be installed on them, so publishing one produces a selector that verifies nothing.
| Platform | What it does instead |
|---|---|
| Google Workspacekey is theirs | Google generates the key pair in the Admin console and never shows you the private half. You choose the selector and the key length there, then publish the TXT record it prints. There is no field to load a key of your own. Their setup guide |
| Microsoft 365key is theirs | Microsoft holds and rotates the keys itself. You publish two CNAME records, at selector1._domainkey and selector2._domainkey, pointing into your tenant, and Microsoft swaps the key behind them. Nothing you generate can be installed. Their setup guide |
| SendGridkey is theirs | Domain authentication issues CNAME records pointing at keys SendGrid hosts and rotates. The key is theirs by design, which is what lets them rotate it without you touching DNS. Their setup guide |
| Mailgunkey is theirs | Mailgun generates the key when you add a domain and gives you the record to publish, either as a TXT record it prints or as a CNAME it can rotate behind. Their setup guide |
| Postmarkkey is theirs | Postmark generates the key with the sender signature or domain, and offers a hosted CNAME so it can rotate the key for you. Their setup guide |
| Brevokey is theirs | Brevo issues the records to publish when you authenticate a domain, using a key it generates and holds. |
| Mailchimpkey is theirs | Mailchimp has you publish a CNAME that delegates the selector into its own zone, where it hosts the key. Their setup guide |
| Zoho Mailkey is theirs | Zoho generates the key in its admin console when you add a selector, and prints the record for you to publish. Their setup guide |
| Klaviyokey is theirs | Klaviyo issues CNAME records for a sending subdomain and hosts the key behind them. Their setup guide |
| HubSpotkey is theirs | HubSpot generates the key when you connect a sending domain and gives you the records to publish. Their setup guide |
| SmartReachkey is theirs | For a mailbox connected over SMTP, SmartReach generates the key itself: Settings, then Team settings, then Email Accounts, then Configure DKIM Signature, then Generate DKIM Record. You publish the TXT record it prints and there is no field to load a key of your own. A mailbox connected through Google Workspace or Microsoft 365 is signed by them instead, so their row above is the one that applies. Their setup guide |
Every row was read from the vendor's own documentation on . Who holds a private key is a product decision other companies make and occasionally change, so if your platform now offers a private-key field that this table says it does not, believe the platform.
Deliberate omissions
What this DKIM generator will not do
DKIM's failure mode is quieter than SPF's or DMARC's. A key that authenticates nothing looks exactly like a key that works, from your own DNS, indefinitely. These six exist for that reason.
It will not generate a key your platform cannot accept
Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, Brevo, Mailchimp, Zoho, Klaviyo and HubSpot all generate the key pair themselves and offer no way to install one you made. Tell the tool who signs your mail and it sends you to their setup instead of handing you a key that can only do harm.
It will not let you publish over a working selector
Replacing the record at a selector something already signs with breaks every signature made with the old key, for as long as the old record is cached. We ask live DNS whether the selector is free while you type it, and say so before you copy anything.
It will not emit a key that permits SHA-1
The h tag defaults to allowing any hash algorithm, which includes SHA-1. RFC 8301 deprecated SHA-1 for DKIM in 2018, so every record here carries h=sha256, which narrows the key to the only algorithm a current signer uses.
It will not add testing mode quietly
The t=y flag asks receivers to behave as though your domain does not sign at all, so a failure costs nothing and a success proves nothing. It has a real use for a few days during a rollout. It is available under the advanced options with that warning attached, never on by default, and never left behind.
It will not offer a key below 1024 bits
RFC 8301 requires verifiers to treat keys shorter than 1024 bits as unacceptable, so a 512-bit key is not a weaker signature. It is no signature at all, published in a form that looks like one.
It will not send your private key anywhere
The pair is generated in your browser with the Web Crypto API and never leaves the page. Nothing is posted, stored or logged, and closing the tab destroys it. That also means we cannot recover it for you, so download it before you leave.
The one worth reading twice is the selector check. RFC 6376 §3.1 lets a domain publish as many keys as it likes, each under its own selector, which means there is never a reason to overwrite a working one. The cost of doing it anyway is every signature made with the old key failing for the length of your TTL, with no error anywhere to tell you why.
The step with no feedback
What a DNS lookup can and cannot prove
Publishing a DKIM record tells you nothing. A value your panel cut short, a record pasted at the wrong selector, and a key published with an empty p all look the same from your own DNS: a record is there, and it is green. The signature just stops verifying, and the first anyone hears of it is a deliverability problem weeks later. This tool still holds the key it gave you, so it can read the record back and compare it character for character. That is a comparison a checker cannot make, because a checker has nothing to compare against.
The key that published is the key you were given
Every character survived. That settles the DNS half. It does not settle whether the system sending your mail actually holds the private key, which nothing in DNS can tell you, so send a message to yourself and read the DKIM-Signature header before you call it done.
Your DNS provider cut the value short
What is published is the beginning of your key and then nothing. That is the 255-octet character-string limit: the panel took the value, kept the first string, and discarded the rest without an error. Nothing signed with this key can verify. Republish using the BIND output, which is already split into strings of the right length.
The record published with an empty key
An empty p value is a deliberate signal that this selector must not be trusted, so receivers treat every signature made with it as a failure. Usually it means the key was pasted without its p= value, or a panel dropped it. Republish the full record.
A different key is published at this name
What is there is not what was generated here, and it is not a shortened version of it either. Either a different record was pasted, or something else already owns this selector and your paste never took effect. Check which, rather than republishing over it.
A record is there, but it carries no key
Something is published at this name and it has no p tag at all, so there is nothing for a receiver to verify against. Republish the whole record rather than editing the one that is there.
Nothing is published at that name yet
DNS is not instant. A new record usually appears within a few minutes, and can take as long as the TTL on the zone. If it is still missing after an hour, the most likely cause is the host field: check it reads the selector followed by ._domainkey, and that your panel has not appended your domain twice.
Read the first one carefully, because it is the one people over-read. A match proves the record landed intact. It cannot prove the system sending your mail holds the matching private key, because the private half is not in DNS and no lookup anywhere can see it. The only things that settle that are opendkim-testkey against your key file and a test message whose DKIM-Signature you read yourself. Both are printed in the tool rather than left as an exercise.
Two decisions, made once
Key length, and the name you publish it under
1024-bit
Still verifies everywhere and fits in a single 255-character string, which is why old setups are full of them. Choose it only if something in your stack cannot handle a longer record, and plan to move.
2048-bit
The current recommendation, what every major provider now issues, and the largest key Amazon SES accepts through BYODKIM. The record has to be split into two strings, which every competent DNS panel does for you.
Record length: about 392 characters
4096-bit
Stronger than anything asks for and slower to sign with. Some DNS panels reject a record this long outright, and a few older verifiers ignore keys above 2048 bits, which fails your signature rather than downgrading it. Choose it only deliberately.
Dated
The year and month you created it, like 202608. Rotation becomes free: publish next year at the new name, switch the signer, and retire the old record once nothing is signed with it.
Numbered
A short sequence, like s1 and s2. Compact and easy to say out loud, and it still rotates, but nothing in the name tells you how old the key is.
Named
The system that signs with it, like postfix or ses. Useful when several systems sign for one domain, because a report naming the selector then names the system.
A selector is only a label, so any DNS-legal string works and none of them is wrong. The name still decides how painful your next key change is: with a dated selector you publish the new key at a new name, move the signer, and retire the old record once nothing is signed with it, which is a rotation with no window where mail fails. With one generic selector you have to overwrite the live record instead.
Take it with you
Put this generator on your own site
Free to embed, on any site, with no permission needed and nothing to sign. It carries a visible credit back here, which is the whole arrangement. Keys are still generated inside the reader's own browser and selectors are still checked against live DNS, so an embedded copy does exactly what this one does.
Deliberate by default
What this generator puts in, and what it leaves out
A DKIM key record can be two tags long, because every tag except p has a default. The defaults are not all benign, which is why this is a rule per tag rather than a preference for short records. For what each tag means, the DKIM checker carries the full reference.
| Tag | When this generator emits it |
|---|---|
| v | Always, first. It is optional in the specification and universal in practice, and a record without it is one more thing for a reader to doubt. |
| k | Always, though rsa is already the default, because for an Ed25519 key the tag is required and two records that disagree about whether they name their key type cannot be compared at a glance. |
| h | Always, as h=sha256. This is the one tag here that is not a default restatement: left out, the key may be used with SHA-1, which RFC 8301 deprecated. |
| prequired | Always, last, because it is by far the longest and a record whose readable half comes first is one you can check before pasting. |
| t=y | Only when you switch it on, and with a warning attached. It makes every verification meaningless while it is set. |
| t=s | Only when you switch it on. The two t flags are combined into one tag, because two t tags is a malformed record. |
| n | Only when you write a note. No verifier reads it. |
| s | Never. It restricts the key to a service type, and the default already covers email. No receiver treats the two differently for mail. |
| g | Never. It was removed from the standard in RFC 6376, and some verifiers reject a record carrying it. |
The interesting row is h. Leaving it out is not neutral: the default permits every hash algorithm, including the SHA-1 that RFC 8301 deprecated for DKIM in 2018 while making rsa-sha256 mandatory for signers. Ten characters closes it, nothing legitimate is affected, and it is the one place on this page where the shortest record is not the correct one.
Once it is published
DKIM is one of the three, and never enough alone
A signature proves a message came from your domain unaltered. It says nothing about which servers may send as you, and nothing about what a receiver should do when a check fails. Verify the key you just published, then the two records beside it.
Proof the message is really yours
DKIM Checker
DKIM signs every message with a key only you hold. Check that the public key is published, parses, is not revoked, and is long enough to be trusted.
What it looks like
v=DKIM1; k=rsa; p=MIIBIjANBgkq…
Which servers may send as you
SPF Checker
SPF lists the servers allowed to send mail for your domain. Check that yours is published, resolves, and stays under the ten-lookup limit that silently breaks it.
What it looks like
v=spf1 include:_spf.google.com ~all
What happens when a check fails
DMARC Checker
DMARC tells receivers whether to quarantine or reject mail that fails SPF and DKIM, and where to send the reports. Check your policy, alignment and reporting address.
What it looks like
v=DMARC1; p=reject; pct=100
Or never touch a private key at all
Sending domains that arrive already signed
Generating a key is the easy part of running your own sending. Rotating it, keeping every selector straight across every domain, and staying out of spam is the rest. SmartReach hands you sending domains and mailboxes with all three records in place.
- Sending domains and mailboxes bought and authenticated in minutes, no IT ticket
- SPF, DKIM and DMARC configured for you, so there is no key to hand-install
- Warmup, inbox rotation and ESP matching across unlimited sending accounts
- Every address verified free before a campaign sends, so bounces never touch your domain
“This software is focused on the end receiver as much as the user.”Matt McQuin · Co-founder, ColdlyticsEvery rule on this page is checked against RFC 6376, the specification that defines DKIM, and RFC 8301, which sets the key and hash requirements. Last reviewed . Key pairs are generated in your own browser and never transmitted, and the selector check runs against live DNS every time you use it, not against anything stored here.
FREQUENTLY ASKED QUESTIONS
DKIM key questions, answered
Stop fixing deliverability one DNS record at a time.
SmartReach buys and authenticates your sending domains and mailboxes with SPF, DKIM and DMARC already in place, then warms them, rotates them, and verifies every address before you send.