How to generate a DKIM key (and publish the right one)

Enabling DKIM starts with a deceptively simple question: how do you generate a DKIM key? The answer depends on who signs your mail — in the vast majority of cases, your sending platform generates the key for you, and your job comes down to publishing the right DNS record. But there are choices that matter (key size, CNAME vs TXT, alignment) and traps to avoid. This guide explains how to get a valid DKIM key, where each piece goes, and how to check everything is correct.

What a "DKIM key" really is

A DKIM key isn't a single object but a pair:

• a private key, used to sign your messages on the way out. It stays secret, stored by your sending platform. It never leaves that environment.
• a public key, derived from the private one, which you publish in DNS. Receivers fetch it to verify the signature.

Generating a DKIM key therefore means creating that pair. The visible part on your side — the DNS record — contains only the public key. If you see your private key in a DNS record, that's a serious mistake: it must never appear there.

The most common case: your platform generates it for you

For Microsoft 365, Google Workspace, a marketing router or most SaaS, you don't run any cryptographic command. The platform generates the pair, keeps the private key, and gives you the DNS record to publish. The steps:

1. Enable DKIM in the platform's console.
2. Get the record it gives you — often one or two CNAMEs, sometimes a TXT with the public key, at a specific selector (see the DKIM selector).
3. Publish it in your DNS, without altering the value (keys are long; copy them in full).
4. Turn on signing on the platform side once DNS propagation is done.

This is the recommended path: the platform handles the private key and, often, its rotation.

The CNAME rather than the TXT, when possible

Many providers offer to publish a CNAME pointing to a record they maintain, rather than a TXT containing the key hard-coded. Favor the CNAME: it lets the provider rotate the key without you touching your DNS each time. You publish once, and key rotation becomes transparent to you. The raw TXT is still valid, but forces you to step in at every renewal.

Generating a key yourself (advanced case)

If you operate your own sending infrastructure (a Postfix server, for example), you generate the pair yourself. Conceptually, you create an RSA key, extract its public part, and build the DNS record. The published record looks like:

selector._domainkey.your-domain.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ... (public key)"

The p= contains the encoded public key. The corresponding private key stays on your server, read by your signing tool. Two golden rules in this case: protect the private key like a critical secret, and choose a suitable size (see below).

Which key size to choose

The question always comes up: 1024 or 2048 bits? The short answer: 2048 bits is the recommended standard today, more robust. 1024 is still accepted but aging. There is, however, a technical subtlety (the DNS record's length) worth a dedicated guide — see 1024 or 2048 bits. If you're starting fresh, choose 2048.

The trap that voids everything: alignment

Here's the most expensive mistake. You can generate and publish a perfectly valid DKIM key, see the signature "pass," and yet bring nothing to DMARC. Why? Because DMARC requires the signing domain (d= in the signature) to align with your From:. The default DKIM signature of many platforms uses their domain (d=platform.com), not yours. Result: the signature is valid, but for the wrong domain.

The fix is to configure a branded signature: most providers offer a "custom signing domain" or "authenticated DKIM" option, which signs with d=your-domain.com. That's precisely what makes your DKIM key useful for DMARC. The full mechanism is in how the three protocols work together.

Verify your key works

Once the key is published and signing enabled, check three things:

1. The public key is there, complete and at the right selector (dig TXT selector._domainkey.your-domain.com).
2. The signature passes on a real message — see how to verify an email signature.
3. It aligns with your From:, visible in your aggregate reports.

You can confirm all of this at once by running your domain through our free analyzer, which checks the presence, validity and alignment of your keys.

Enabling DKIM on common platforms

The exact steps depend on your platform, but the pattern is the same everywhere: enable DKIM in the console, get the record, publish it, wait, sign. A few concrete pointers:

• Microsoft 365. In the security portal, under email authentication, you enable DKIM for your domain. Microsoft gives you two CNAMEs (selector1 and selector2) to publish; both serve to allow alternating key rotation. Once published and propagated, you turn on signing.
• Google Workspace. In the admin console, under email authentication, you generate a key (choose 2048 bits) for your domain. Google gives you a TXT to publish at the google selector. After propagation, you start authentication.
• Routers and SaaS (Brevo, SendGrid, Mailchimp…). Almost all offer a custom signing domain via one or more CNAMEs. That's also where you enable alignment (d=your-domain.com) — the step that makes the signature useful to DMARC.

In all cases, the rule is the same: copy the value in full, wait for propagation before turning on signing, and then verify that the d= is yours and not the provider's.

The most common generation mistakes

Three slips recur endlessly. First, turning on signing before DNS propagation: the first signatures point to a key that isn't visible yet and fail — wait until dig shows the key before signing. Second, truncating the key on copy-paste, especially with 2048 bits where it's long: a single missing character breaks the whole verification. Third, forgetting alignment: you enable DKIM, the signature passes, but with the provider's d= — you believe you're protected while DMARC relies on nothing. Check these three points after every activation, and you spare yourself the overwhelming majority of start-up DKIM failures.

Frequently asked questions

Do I have to generate the key myself? Rarely. If you send via a platform (Microsoft, Google, a SaaS), it generates the pair and keeps the private key. You only generate it yourself if you operate your own signing infrastructure.

Where does the private key go? It stays in the environment that signs (the platform or your server). It is never published in DNS and must never leave that environment. DNS contains only the public key.

Can I reuse the same key for several domains? Avoid it. Each domain should have its own key (and its own selector), to isolate risk and simplify rotation.

How long before it works? As long as DNS propagation takes (a few minutes to a few hours). Only turn on signing on the platform side once the public key is visible, otherwise the first signatures will fail.

1024 or 2048 bits? 2048 for a new deployment. 1024 still works but is less robust; replace it at the next rotation.

DKIM and deliverability: why it really matters

Beyond security, DKIM has a concrete effect on your email deliverability. Major mailbox providers (Gmail, Outlook, Yahoo) factor the presence and alignment of DKIM into their reputation scores: a domain that signs correctly over time, with an aligned key, builds a trust history that spam filters take into account. Conversely, a domain without DKIM (or with a non-aligned signature) is treated with more suspicion, especially if its reputation is still young. DKIM doesn't prevent spam — a spammer can perfectly well sign their messages — but it tells the receiver "this message really comes from who it claims to," which is an important legitimacy signal. Combined with SPF and DMARC, it forms the foundational trio every serious sender needs in place before trying to optimize anything else. The good news: well configured once, DKIM works invisibly for you, accumulating reputation with every legitimate email you send. The investment is front-loaded (getting the key published, the alignment right, the platforms configured), and after that it runs itself — except for periodic rotation, which keeps it current and limits the blast radius of any future compromise.

Let Thomas generate the right record

Between key size, CNAME vs TXT and above all alignment, a badly set DKIM key goes unnoticed until the day DMARC fails. Thomas, your virtual CISO, tells you for each platform the exact record to publish, checks the signature aligns with your domain, and guides you to a DKIM that actually counts for DMARC.

Analyze your domain for free → or create an account for a correct DKIM the first time.