Generate DKIM key pairs and DNS TXT records entirely in your browser. No data leaves your device — keys are created client-side using the Web Crypto API.
DKIM (DomainKeys Identified Mail) is an email authentication protocol that lets the receiving mail server verify that an email was actually sent by the domain it claims to come from and that the message wasn't tampered with in transit. It works by attaching a cryptographic signature to every outgoing email, which the recipient can validate against a public key published in your domain's DNS records.
Think of DKIM as a tamper-evident seal on every email you send. When your mail server sends a message, it uses a private key to create a unique digital signature based on the email's content — the headers, the body, or both. That signature is embedded directly into the email as a DKIM-Signature header. When the receiving server gets the email, it looks up your public key in DNS and uses it to verify the signature. If the signature checks out, the server knows two things: the email genuinely came from your domain, and nobody altered it after it was signed.
DKIM is one of the three pillars of modern email authentication, alongside SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). While SPF verifies which servers are allowed to send email for your domain, DKIM verifies the integrity of the message itself. DMARC ties the two together with a policy layer that tells receiving servers what to do when authentication fails.
Unlike SPF, DKIM survives email forwarding. Because the signature is embedded in the email headers rather than being tied to the sending server's IP address, a forwarded email can still pass DKIM verification as long as the message content hasn't been modified. This makes DKIM especially important for organizations whose emails are frequently forwarded, such as mailing lists, newsletters, and automated notifications.
DKIM uses asymmetric cryptography — a pair of mathematically linked keys where one key signs data and only the other key can verify that signature. Here's how the two keys are used in practice:
Lives on Your Mail Server
The private key stays on your mail server and is never shared with anyone. Your mail server uses it to create a unique cryptographic signature for every outgoing email. This signature is added to the email's DKIM-Signature header before the message leaves your server.
Published in DNS
The public key is published as a DNS TXT record at selector._domainkey.yourdomain.com. Receiving mail servers query this record to retrieve your public key, then use it to verify the DKIM signature on incoming emails from your domain.
The email is prepared with all its headers and body content, ready to be sent.
Using the algorithm specified in your DKIM configuration (typically SHA-256), the server generates a hash of the email headers and body.
The server encrypts the hash using your RSA private key, producing a unique digital signature that is only valid for this specific email.
The signature, along with metadata like the selector name, signing algorithm, and which headers were signed, is inserted as a DKIM-Signature header.
When the email arrives, the receiving server extracts the selector from the DKIM-Signature header and queries your DNS for the corresponding public key.
The receiving server uses your public key to decrypt the signature, then independently hashes the email content and compares the two values. If they match, DKIM passes.
The beauty of this system is that the private key never needs to leave your server. Even if someone intercepts the email and sees the signature, they cannot forge signatures for future emails without possessing the private key. And because the signature covers the email content, any modification to the message after signing will cause the verification to fail.
A DKIM selector is a short text string that identifies which DKIM key pair a particular email was signed with. It appears in two places: the DKIM-Signature header of every outgoing email, and the DNS hostname where the corresponding public key is published. The selector is what allows a domain to have multiple active DKIM keys at the same time.
When a receiving server processes an email with a DKIM signature, it reads the s= tag from the DKIM-Signature header to determine the selector. It then constructs the DNS query as selector._domainkey.domain.com and retrieves the public key. Without selectors, you could only have one DKIM key per domain — which would make key rotation and multi-provider setups impossible.
Selectors can be any alphanumeric string. There is no standard naming requirement, but using a descriptive, consistent naming scheme will save you headaches down the road. Here are common approaches:
google, sendgrid, mailgun, hubspotName the selector after the email service that uses it. Easy to audit.
dkim202604, q2-2026, 2026aprInclude the date or quarter when the key was generated. Simplifies key rotation tracking.
marketing, transactional, supportName the selector after the type of email it signs. Useful when different teams manage different streams.
default, dkim, mail, s1Simple generic names. Fine for single-provider setups.
Most organizations need more than one DKIM selector. If you send email through Google Workspace for internal communication, SendGrid for marketing campaigns, and a CRM for sales outreach, each service needs its own DKIM key pair with its own selector. This is perfectly normal and supported by the DKIM specification.
Multiple selectors also enable zero-downtime key rotation. You can publish a new key with a new selector, configure your mail server to start signing with it, and then remove the old selector once DNS propagation is complete. At no point do incoming emails fail DKIM verification.
The key length determines the cryptographic strength of your DKIM signature. Longer keys are harder to break but produce larger DNS records. Here's the practical comparison:
The only legitimate reason to use a 1024-bit key is if your DNS provider has a character limit on TXT records that prevents you from publishing a full 2048-bit public key. Some older DNS management interfaces cap TXT records at 255 characters per string, which can truncate a 2048-bit key. Most modern providers handle this by splitting the record into multiple strings automatically, but if yours doesn't, a 1024-bit key is a reasonable fallback.
All major email providers — Gmail, Outlook, Yahoo, Apple Mail — support both 1024-bit and 2048-bit DKIM keys. On the DNS side, Cloudflare, Namecheap, GoDaddy, Route 53, and Google Cloud DNS all support 2048-bit keys without issues. If you are using any mainstream provider from the last decade, 2048-bit will work fine. When in doubt, generate a 2048-bit key with our tool above, try adding it to your DNS, and fall back to 1024-bit only if the record doesn't publish correctly.
Once you've generated your DKIM key pair using the tool above, you need to publish the public key as a DNS TXT record so receiving mail servers can find it. Here are step-by-step instructions for the most common DNS providers:
selector._domainkey (replace “selector” with your actual selector).v=DKIM1; k=rsa; p=) into the Content field.selector._domainkey.selector._domainkey.selector._domainkey.After adding the record, DNS propagation typically takes between 15 minutes and 4 hours. Full global propagation can take up to 48 hours in rare cases. You can verify your record is live by using our DKIM Checker or our DNS Checker.
After publishing your public key in DNS, you need to install the private key on your mail server so it can sign outgoing emails. The process varies depending on your mail server or email service provider.
Postfix is the most common open-source mail server for Linux. DKIM signing is handled by OpenDKIM, which runs as a milter (mail filter).
sudo apt install opendkim opendkim-tools/etc/opendkim/keys/yourdomain.com/selector.private/etc/opendkim.conf with your domain, selector, and key path.main.cf configuration.Google Workspace generates its own DKIM keys through the Admin Console. You do not upload a custom private key.
Note: For Google Workspace, use the key Google provides rather than generating your own. Use our DKIM generator for custom mail servers or services that require you to supply your own key pair.
Microsoft 365 also manages DKIM signing internally but requires you to publish CNAME records that point to Microsoft's DKIM infrastructure.
selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com).Note: Like Google Workspace, Microsoft 365 handles its own key pair internally. Use our generator when configuring custom mail infrastructure.
After publishing your DKIM record in DNS and configuring your mail server with the private key, you should verify that everything is working correctly before relying on it for production email.
Use our DKIM Checker to query your selector._domainkey record and confirm it returns the correct public key. If it returns nothing, DNS hasn't propagated yet or the record was entered incorrectly.
Send an email from the mail server you configured with the private key. Send it to a Gmail, Outlook, or Yahoo address you control.
Open the received email and view the full headers (in Gmail: three dots > Show Original). Look for the Authentication-Results header. You should see dkim=pass.
The d= value in the DKIM-Signature header should match the domain in your From address. If it doesn't, DKIM will pass but won't satisfy DMARC alignment.
Copy the full email headers and paste them into our Email Header Analyzer for a detailed breakdown of all authentication results.
Verify your new DKIM record with our free DKIM Checker. It will confirm that your public key is published correctly and accessible to receiving mail servers.
A DKIM record is a DNS TXT record that contains the public key for your domain's DKIM authentication. It is published at selector._domainkey.yourdomain.com and allows receiving mail servers to verify the DKIM signatures on your outgoing emails. The record typically looks like v=DKIM1; k=rsa; p= followed by the Base64-encoded public key.
Use the DKIM generator at the top of this page. Enter your domain name, choose a selector name, select your preferred key length (1024 or 2048-bit), and click Generate. You will receive a private key for your mail server and a public key formatted as a DNS TXT record. Everything is generated in your browser -- no data is sent to any server.
A DKIM selector is a name that identifies a specific DKIM key pair for your domain. It allows you to have multiple DKIM keys active at the same time -- one for each email service you use. The selector is included in the DKIM-Signature header of every signed email and determines which DNS record the receiving server queries for the public key.
Use 2048-bit keys as your default choice. They provide stronger security and are recommended by the DKIM specification (RFC 6376). Only fall back to 1024-bit if your DNS provider has character length limitations that prevent you from publishing the full 2048-bit public key.
Add your DKIM record to your domain's DNS zone through your domain registrar or DNS hosting provider (Cloudflare, Namecheap, GoDaddy, Route 53, etc.). Create a new TXT record with the hostname selector._domainkey and paste the public key value from the generator as the record content.
Use our free DKIM Checker to confirm the TXT record is published and returning the correct public key. Then send a test email and check the email headers for dkim=pass in the Authentication-Results header. If both checks succeed, your DKIM is working correctly.
DKIM is not technically required to send email, but it is effectively required for reliable email delivery. Gmail, Outlook, Yahoo, and other major providers all check for DKIM authentication. Without it, your emails are far more likely to be flagged as spam or rejected outright. Google and Yahoo now require DKIM for bulk senders.
When DKIM verification fails, the outcome depends on your DMARC policy. If your DMARC policy is p=none, the email may still be delivered but is more likely to land in spam. If your policy is p=quarantine, the email goes to spam. If your policy is p=reject, the email is bounced entirely. Check your DMARC configuration with our free DMARC Checker.
Your DKIM key pair is generated. Now make sure the rest of your email authentication stack is locked down:
ScaledMail configures SPF, DKIM, and DMARC correctly for every inbox from day one. No DNS headaches, no key management, no authentication gaps.
See ScaledMail Pricing