mailtanimailtani
Free Tool

Free DKIM Record Generator

Generate a DKIM TXT record for your domain. Enter your domain and selector, choose a key length, and get the ready-to-publish DNS record in seconds.

Configure your DKIM record

How to Use This Tool

Step 01

Enter your domain and selector

The selector is a label you choose (e.g. "mail" or "s1"). It's part of the DNS record name and lets you run multiple DKIM keys for the same domain.

Step 02

Choose key length

2048-bit keys are the current standard and recommended for all new setups. 1024-bit is supported by older systems but no longer considered sufficient.

Step 03

Publish and configure your sender

Add the TXT record to your DNS at {selector}._domainkey.yourdomain.com, then configure your email provider to sign outgoing mail with the private key.

How DKIM Signing Works and Why It Matters

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing email messages, allowing receiving servers to verify that a message genuinely originated from the claimed domain and that its headers and body were not altered in transit. When your mail server sends a message, it computes a hash of specified headers and the message body, then signs that hash using a private key held securely on your server. The resulting signature is added as a `DKIM-Signature` header. Receiving servers fetch the corresponding public key from your DNS and use it to verify the signature. If the signature is valid, the message is confirmed as authentic and unmodified.

Unlike SPF, which checks the sending IP address at the network layer, DKIM operates at the message layer. This means DKIM signatures survive email forwarding — when a mailing list or mail forwarding service relays your message, the DKIM signature remains valid as long as the headers and body have not been modified. This makes DKIM the more robust DMARC pass mechanism in scenarios involving third-party forwarding, which is why email security practitioners prioritise getting DKIM right above optimising SPF alone.

DKIM was standardised in RFC 6376 and is now a baseline requirement alongside SPF for bulk senders to major inbox providers. Its value extends beyond compliance: inbox providers weight DKIM signing in their reputation models. A domain with a consistent DKIM signing history builds trust that improves inbox placement over time, while a domain that suddenly starts signing after a long gap may trigger additional scrutiny.

Key Pairs, Selectors, and DNS Record Structure

DKIM uses asymmetric cryptography: your mail infrastructure holds the private key and uses it to sign outgoing messages; you publish the public key in DNS and anyone can use it to verify signatures. The private key must be kept secret — if it is ever compromised, an attacker could sign fraudulent messages that pass DKIM verification. Most ESPs manage the private key on your behalf and only ask you to publish the corresponding public key in your DNS.

The selector is a label you choose that scopes the DNS lookup. It is arbitrary — you might use `google`, `s1`, `mail`, or a date-based label like `2024jan` — but it must be consistent between what your mail server includes in the `DKIM-Signature` header's `s=` tag and the DNS record you publish. The public key record lives at `{selector}._domainkey.yourdomain.com` as a TXT record. The record contains the key type (`k=rsa`), the public key itself (`p=...`), and optionally flags for testing mode (`t=y`) or restricted service types (`s=email`).

The key length debate is settled: use 2048-bit keys. 1024-bit keys were once standard but are now considered insufficient — several inbox providers, including Gmail, have flagged 1024-bit DKIM keys as a negative signal. Some very old DNS providers cannot handle 2048-bit keys in a single TXT record because the base64-encoded key exceeds 255 characters; the solution is to split the record across multiple quoted strings in the same TXT record, which compliant DNS resolvers automatically concatenate.

Rotating Keys, Testing Mode, and Verifying After Publication

DKIM key rotation is a security best practice that most teams neglect. The recommendation is to rotate your DKIM keys annually at minimum, and immediately if there is any possibility the private key was exposed. Rotation is non-disruptive if done correctly: generate a new key pair, publish the new public key under a new selector, configure your mail server to sign with the new selector, verify that new signatures are working, and only then remove the old selector from DNS. The overlap period ensures no gap in authenticated mail.

During initial setup, you can use the `t=y` flag in your DKIM DNS record to signal to receiving servers that you are in testing mode. This flag tells receivers to treat the key as if verification is being tested and not to use the result for filtering decisions. Remove the `t=y` flag once you have verified that signing is working correctly — leaving it in place long-term means receivers may ignore your DKIM results entirely.

After publishing your DKIM record, allow 5–30 minutes for DNS propagation before running verification. You can verify using a DKIM lookup tool by supplying your domain and selector, or by sending a test message to a service that displays full header analysis. Check that the `DKIM-Signature` header is present in outgoing messages, that the `d=` tag matches your From domain, and that the `s=` tag matches your published selector.

Configuring DKIM with Your ESP and Common Pitfalls

Most modern ESPs handle DKIM signing automatically once you complete their domain verification workflow. The typical process involves them providing you with a CNAME record pointing to their DNS-managed public key, or providing the actual TXT record value for you to publish directly. CNAME-based DKIM is increasingly common because it lets the ESP rotate keys transparently without requiring you to update DNS each time. If your ESP offers CNAME-based DKIM, use it — it shifts key management responsibility to the ESP and ensures you are always using their current key.

If you run your own mail infrastructure (Postfix, Exim, or similar), you will generate the key pair yourself, typically using OpenSSL, and publish the public key in DNS while configuring the signing daemon (OpenDKIM or rspamd are the most common) with the private key. The most common pitfall is a mismatch between the selector in your mail server configuration and the selector in your DNS record — a typo in either place causes all signatures to fail verification.

Another frequent issue is canonicalisation. DKIM supports two canonicalisation algorithms: `simple` and `relaxed`. Simple canonicalisation is strict about whitespace, meaning minor reformatting by intermediate servers can invalidate the signature. Relaxed canonicalisation is tolerant of common header and body modifications and is almost always the right choice. Verify that your signing configuration uses `c=relaxed/relaxed` to maximise resilience across different mail paths.

Key Features

Key Length Selection

Choose between 2048-bit and 1024-bit keys with clear guidance on which inbox providers require 2048.

Selector Naming Guide

Suggests selector naming conventions and explains how selectors enable seamless key rotation.

Long Key Split Output

Automatically splits 2048-bit public keys into multi-string format for DNS providers with length limits.

Testing Mode Flag Option

Optionally includes t=y testing flag in the generated record for safe pre-production verification.

Publication Path Display

Shows the exact DNS hostname where you must publish the record based on your selector and domain.

CNAME vs TXT Guidance

Explains when to use a CNAME versus TXT record depending on whether your ESP manages the key.

Frequently Asked Questions

Email Authentication Made Easy

mailtani walks you through DKIM, SPF, and DMARC setup step by step and monitors your authentication status — included in every plan.

  • DKIM key configuration guides
  • Authentication status monitoring
  • Inbox warmup & rotation
  • One-time price

14-day free trial · €89 lifetime access after