DKIM Record Generator

Generate a DKIM key pair and the DNS TXT record to publish it. Runs entirely in your browser, so your private key never leaves your device.

  • 100% client-side generation
  • Private key never leaves your device
  • Free, no signup

A selector lets you run more than one DKIM key on the same domain at once. Leave it as “default” unless your mail provider tells you to use something else.

Key length

2048-bit generation can take a few seconds on slower devices. The key never leaves this browser tab.

A DKIM record generator creates an RSA key pair and formats the public key as a DNS TXT record (v=DKIM1; k=rsa; p=...) published at selector._domainkey.yourdomain.com. The private key is used to sign outgoing mail and should never be generated or stored on a third-party server. This tool generates the key pair in your browser using the Web Crypto API, so the private key is never transmitted anywhere.

01 Basics

What is DKIM and why do you need it?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email your domain sends. The receiving mail server checks that signature against a public key published in your DNS, confirming two things: the message really came from a server authorized to sign for your domain, and nobody altered it in transit.

Without DKIM, your outgoing mail is easier to spoof, easier to flag as suspicious, and more likely to land in spam. Gmail, Outlook, and Yahoo all weight DKIM (alongside SPF and DMARC) heavily in their spam filtering decisions, and Google and Yahoo now require it outright for anyone sending more than 5,000 messages a day to their users. If you run transactional email, marketing campaigns, or anything sent on your domain's behalf by a third-party platform, DKIM is table stakes, not an optional hardening step.

Setting it up means two things: a key pair (public and private) and a DNS TXT record publishing the public half. This tool generates both, safely, and gives you the exact record to publish.

02 Installation

How to install your DKIM record

Four steps, then the specifics for five common DNS providers. The generator above walks you through the same providers with your actual record already filled in.

  • 01
    Copy your record
    Copy the record name and value the generator produced. If your key is 2048-bit, copy the quoted-string version too. Some DNS providers need it.
  • 02
    Add a TXT record with your DNS provider
    Log in to whoever hosts your domain's DNS (not necessarily your mail provider) and add a new TXT record using the name and value you copied.
  • 03
    Wait for propagation
    DNS changes usually take 5 minutes to a few hours to spread, occasionally up to 48 hours. Don't panic if verification fails immediately after saving.
  • 04
    Install the private key on your mail server
    Your outgoing mail server or provider (Postfix, Postmark, SendGrid, Google Workspace, and so on) needs the private key to sign messages. Where this goes depends entirely on what sends your mail.
  • 01
    Cloudflare
    Open the Cloudflare dashboard and select your domain.
  • 02
    GoDaddy
    Go to My Products > DNS next to your domain.
  • 03
    Namecheap
    Go to Domain List > Manage next to your domain, then the Advanced DNS tab.
  • 04
    Amazon Route 53
    Open the Route 53 console and select your hosted zone.
  • 05
    Google Domains / Google Workspace
    In Google Workspace Admin, go to Apps > Google Workspace > Gmail > Authenticate email, or in Google Domains go to DNS > Custom records.

03 Verification

How to verify DKIM is working

The fastest check is a real email. Send yourself a test message from the domain you just configured, open it in Gmail, and view the original message (three-dot menu → Show original). Look for DKIM: ‘PASS’ in the authentication results near the top.

You can also check the DNS record directly with dig, before any mail is even sent:

dig txt selector._domainkey.yourdomain.com

Replace selector and yourdomain.com with your own values. A working record returns your full v=DKIM1; k=rsa; p=...value. No answer usually means the record hasn’t propagated yet or the selector doesn’t match what you published.

04 The full picture

How DKIM, SPF, and DMARC fit together

DKIM is one of three DNS-based checks that make up email authentication. Each catches something the others miss.

  • 01
    SPF: who's allowed to send
    SPF lists the mail servers and IP addresses authorized to send mail for your domain. It's an allowlist published as a DNS TXT record. Simple, but it doesn't survive forwarding well and doesn't verify the content itself.
  • 02
    DKIM: the message wasn't altered
    DKIM signs each outgoing message with a private key. The receiving server checks that signature against the public key in your DNS record. Unlike SPF, DKIM survives forwarding, because the signature travels with the mail, not the sending IP.
  • 03
    DMARC: what to do when checks fail
    DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks: quarantine it, reject it, or let it through and just report on it. It's also how you get visibility into who's sending mail claiming to be your domain, including spoofers.

We build email and messaging infrastructure.

Postmark and SendGrid integrations, transactional systems, and deliverability monitoring. Talk to us if that's on your roadmap.

How it works

Generates an RSA key pair (1024 or 2048-bit) client-side via the browser's native Web Crypto API. The public key is exported and formatted into a DKIM DNS TXT record; the private key is exported as PEM for installation on your mail server. No key material is ever sent to RaftLabs or any third party.

DKIM questions, answered

A selector is a label that lets you publish more than one DKIM key for the same domain at once, for example one per sending platform (default._domainkey vs. mailgun._domainkey). It becomes part of the DNS record name: selector._domainkey.yourdomain.com. Most single-platform setups can leave it as "default," but if your email provider tells you to use a specific selector, use theirs so it matches what they sign with.
Use 2048-bit unless a specific system forces 1024-bit. 2048-bit is the current industry standard and meaningfully harder to break. The only reason to pick 1024-bit is a legacy DNS provider or mail platform that can't handle the longer, split TXT record, or a quick test setup you'll rotate later.
Rotate every 6 to 12 months as routine hygiene, and immediately if you suspect the private key was exposed. Rotation means generating a new key pair under a new or same selector, publishing the new public key, waiting for DNS propagation and a few days of mail flow on the new key, then removing the old record. Never remove the old record before mail has fully cut over, or messages already in flight will fail verification.
Four things cause most failures. The TXT record hasn't propagated yet, wait up to 24-48 hours. The selector in your DNS doesn't match what your mail server signs with. A long 2048-bit key got truncated because it wasn't split into quoted strings correctly. Or there's a typo in the name, which has to be exactly selector._domainkey.yourdomain.com, no extra dots, no wrong subdomain. Check `dig txt selector._domainkey.yourdomain.com` to see exactly what's published.
Yes, as long as each one uses a different selector. That's exactly what selectors are for: running multiple DKIM keys side by side. Do it during a key rotation, or because you send mail through more than one platform, say your own transactional sender plus a marketing ESP, and each one signs with its own key.