wiredepth
Run a check

Free tool · Email auth

DKIM TXT record generator

Paste the public key your mail provider gave you and get the DKIM TXT record properly formatted with v=DKIM1, k=, h=, p= tags in the right order. Includes the host name (selector._domainkey.domain) and a multi-string split for DNS consoles that don't auto-handle long values.

Short label your mail platform uses to find this key. Each rotation gets a new selector (e.g. 2026q1).

The apex (or subdomain) you sign mail with.

Generated inside your mail platform (Google Workspace, M365, SendGrid, Mailgun, etc.). Do NOT paste a private key here - this tool stays in your browser but private keys never leave the mail platform that generated them.

What this tool checks

What this tool does NOT do: generate the keypair. The DKIM private key has to live with the mail platform that signs your outbound mail; generating it in a browser and copy-pasting it across systems is fragile and unsafe. Generate the keypair inside Google Workspace Admin / M365 Exchange Admin / SendGrid / Mailgun / etc. - those tools emit the public key for you to publish.

What this tool DOES do: take the public key those tools handed you (usually as a chunk of base64 sometimes wrapped in -----BEGIN PUBLIC KEY----- markers) and format it as a syntactically-correct DKIM TXT record. Right v= prefix, right tag order, right handling of the 255-character DNS TXT string cap.

Selector strategy: use one selector per sending platform AND rotate at least yearly. A typical year of records looks like google2026q1._domainkey, sendgrid2026._domainkey, mailgun2026q1._domainkey. New selector for a new key means you can stage the rotation, dual-sign with old + new for a week, then retire the old.

Frequently asked questions

What's a DKIM selector?

A short label your mail platform stamps into each outbound message as `d=domain; s=selector` in the DKIM-Signature header. Receivers use it to look up `selector._domainkey.domain` and find the public key that should verify the signature. Each independent sender wants its own selector so rotating one doesn't affect the others.

RSA 1024 or 2048?

2048 if your mail platform supports it. 1024 is the historical default and still works at every major receiver. 1024 emits a shorter TXT record (under 255 chars typically); 2048 needs the multi-string split below. There is no security reason to prefer 1024 over 2048; the smaller record size is the only argument and it isn't a strong one.

Should I use Ed25519?

It is RFC 8463 standard, supported by Gmail / Microsoft / Apple Mail / etc., and produces a tiny TXT record. The catch: some sending platforms (older SendGrid, some self-hosted Postfix configs) still only emit RSA. Use what your sender supports. The receiver-side verification is the same end result.

How long should a DKIM record live?

Rotate yearly minimum, quarterly if you can. Old selector stays published (with old public key) for ~30 days after rotation so in-flight retries from receivers can still verify, then retire. This is standard secret-rotation hygiene; the same key signing your mail for 5 years is a problem if it ever leaks.

Can you tell DKIM is working without sending mail?

The TXT record itself only tells you the public key is published correctly. To confirm signing actually works you have to send mail through the sender and check the Authentication-Results header on the receiving end.

Related free tools