DKIM DNS Record Generator

Enter a selector name and public key (PEM format) to generate the DNS TXT record for DKIM signing (v=DKIM1; k=rsa; p=...). Public keys longer than 255 characters are automatically split into BIND zone file format.

Last updated: 2026-09-20

Assembling the DNS record for DKIM

Enter a selector name and a public key in PEM form and this tool assembles the DNS TXT record used to verify DKIM signatures, of the shape `v=DKIM1; k=rsa; p=...`. Its place is at `selector._domainkey.yourdomain`.

**What everyone runs into here is the limit of 255 characters per string in a DNS TXT record.** An RSA 2048-bit public key comes to roughly 390 characters in Base64, so **it will not fit into a single string as it stands.** In a zone file it is written in parentheses as several strings, and **the receiving side joins them back into one value.** This tool performs that splitting for you. **The other thing that must never be got wrong is that what goes into DNS is the public key.** The private key belongs on the signing server alone and must never leave it.

How to use it

Enter the domain and a selector name The selector is a name of your choosing; use a new one whenever you replace the key.
Paste the public key in PEM form **It is the key beginning `-----BEGIN PUBLIC KEY-----`, not the private one.**
Review the generated record **Where it runs past 255 characters, the output comes split within parentheses.**
Register it in DNS Place it as a TXT record at `selector._domainkey.yourdomain`.

Tips for getting more out of it

You can paste the contents of a PEM file generated with opendkim-genkey or OpenSSL's openssl genrsa → openssl rsa -pubout directly. Line breaks and header lines are stripped automatically.
Enabling test mode (t=y) can make some receiving servers go easier on DKIM failures instead of rejecting outright. It's a safer setting during the validation period before going to production.
After publishing the generated record to DNS, we recommend confirming it took effect with this site's mail deliverability checker (SPF/DKIM/DMARC diagnosis).
Key lengths of 1024 or 2048 bits are common, and 2048-bit keys typically produce a public key string longer than 255 characters that gets split into multiple strings. The split itself is not an error.
You can choose any selector name, but if a domain uses multiple mail providers, including the provider name (e.g. "google", "mailgun") makes management easier.

Where it comes in useful

Adopting DKIM for the first time

**Once the keys are made, it shows you how to write them into DNS.**

Rotating a key

**Add a record under a new selector and remove the old one after the changeover.**

Confirming how the splitting is written

How to divide a long key is exactly the sort of thing got wrong by hand.

Verifying what a delivery service told you

**You can confirm that a record handed to you by an outside service takes the right form.**

DKIM terms

Selector: The name identifying a key. **It forms the head of `selector._domainkey.example.com`, and each key gets its own.**
Public key: **The one that goes into DNS.** The receiving side verifies signatures with it.
Private key: The key used to create the signatures. **It belongs on the sending server alone and must never be published.**
The 255-character limit: **The ceiling on a single string within a TXT record.** Anything longer is written as several strings.
V=DKIM1: The tag stating the version of the record. It comes first.
K=rsa: The kind of key. Besides RSA there is Ed25519, whose keys are considerably shorter.

Frequently Asked Questions

It's an identifier that lets a domain use multiple DKIM keys at once. The record is published in DNS under the name "selector._domainkey.domain", and the signature is verified using the public key of the selector matching the s= tag in the outgoing mail's DKIM-Signature header.

Since a single DNS TXT character-string is limited to 255 bytes, anything longer is split into multiple quoted strings that are concatenated with no gap into a single TXT record. The BIND-format output this tool generates already handles that split.

No. This tool only assembles the record you publish to DNS — it does not generate a private key. Generate and store your private key securely in your own environment using a trusted tool such as opendkim-genkey or OpenSSL.

Use it right after deploying DKIM, during the period when you're confirming that signing and verification work correctly in your actual sending environment. Some receivers treat DKIM failures from domains with t=y more leniently, making it a safety net before going fully live.

RSA (k=rsa) is the de facto standard today because it's supported by the widest range of sending and receiving servers. Ed25519 (k=ed25519, RFC 8463) has shorter keys and faster signing, but some mail servers still don't support it, so only adopt it if you can confirm it works on both ends.

Side Note — How public-key cryptography stops email impersonation

DKIM (DomainKeys Identified Mail) was standardized in 2004 by merging two technologies that Yahoo! and Cisco had developed independently — DomainKeys and Identified Internet Mail. At its core is public-key cryptography: the sender encrypts a hash computed from the message headers and part of the body with a private key and attaches it as the DKIM-Signature header. The receiver verifies that signature using the public key published in DNS, and if the key pair matches, it can mathematically confirm the content was not altered after it was sent.

While SPF verifies legitimacy at the network level — the sending IP address — DKIM is fundamentally different in that it applies a digital signature to the content of the email itself. As a result, even if a message is relayed through legitimate servers multiple times (something SPF is known to handle poorly), the DKIM signature remains valid as long as the body isn't modified. This is why DKIM is considered more reliable than SPF for delivery paths that involve forwarding, such as mailing lists.

The selector mechanism also matters in practice. When a single domain uses multiple mail providers (an in-house server, Gmail, SendGrid, and so on), assigning a separate key pair and selector name to each lets you revoke or rotate keys independently per provider. This operational flexibility — a leaked key affecting only its own selector — is one reason DKIM has remained in wide use across large-scale mail infrastructure despite being nothing more than a single DNS record.

Browse all trivia