DKIM Record Generator

How DKIM works

Your mail server signs each outgoing message with the private key and adds the signature in a DKIM-Signature header. The receiver reads the selector name from that header, fetches the matching public key from your DNS, and verifies the signature. A match means the message came from your domain and was not altered in transit.

Which leads to a simple consequence: exactly one party needs the private key, whoever sends the mail. Everything else is public.

What to do with the output

1. Publish the public key as a TXT record at selector._domainkey.
2. Store the private key on your mail server and point the signing configuration at it.
3. Send a test message and read its headers: Authentication-Results should show dkim=pass.

The usual publishing problem

A 2048-bit key does not fit in a single TXT string, since DNS caps a string at 255 characters. Most panels split the value automatically, but some expect you to do it, and the record then becomes several quoted strings in a row with no separator. If a key check afterwards reports that the key cannot be parsed, the value has almost certainly been broken by a line wrap or truncated during copy-paste.

What the tags mean

• v=DKIM1 — the version. If present it must come first.
• k=rsa — the key type. It is the default, so it is often omitted. The alternative is k=ed25519: shorter and faster, but not every receiver supports it, so it goes out as a second selector alongside RSA rather than replacing it.
• p= — the public key itself, base64 encoded. An empty p= marks a revoked key: the record stays, signatures against it stop validating.
• t=y — testing mode. Receivers verify the signature but disregard the outcome. Useful for the first few days, harmful once forgotten: the domain looks signed while providing no protection.
• h=sha256 — the permitted hash algorithm. Optional; sha1 is not in use in 2026.

Key length

1024 bits is the historical minimum, still found at older sending services. It counts as weak, being computationally forgeable, and Gmail has flagged 1024-bit signatures as untrustworthy since 2023. The working choice is 2048.

4096 looks like the obvious next step but causes more trouble than it solves: the value stops fitting the limits of some DNS panels and older resolvers, while the added strength is immaterial for signing a message. Unless your provider insists otherwise, stay at 2048.

About selectors

A selector is an arbitrary label in front of ._domainkey, and it exists precisely so that you can hold several keys at once. Each sending service signs with its own: mail for one, s1 for another, google for Workspace. They do not collide, because the receiver reads the selector name out of the message header and fetches that specific key.

The practical consequence: adding a new sending service means migrating nothing. You add another selector and the old one keeps working. Meaningful names like crm2026 or esp-main save time a year later, when you are trying to remember whose key this is.

The private key

Generation happens entirely in your browser and the private key is never transmitted. From there it should live in exactly one place: wherever mail is signed, meaning your mail server configuration or your sending service's panel. It does not belong in a shared chat or a repository. Whoever holds it can sign mail as your domain, and DMARC will let it through.

Rotate keys roughly every six months, which can be done without downtime: publish a new selector, switch the service to it, then delete the old record a few days later, once mail signed with the previous key has finished arriving.

Confirming the signature actually works

Publishing the record is half the job: the key sits in DNS, but mail gets signed only once the private half is configured in the sending service. One message to your own mailbox settles it, and the source should contain a DKIM-Signature header, and Authentication-Results should read dkim=pass.

When it says dkim=fail while the key parses fine, the cause is nearly always one of three: the DNS value does not match what the service issued (characters lost in copy-paste), the message is modified in transit by an antivirus or a mailing list server, or the signature covers a header that gets rewritten afterwards, a Subject with an "[External]" tag prepended, for instance.