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

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. The CNAME is the one to favor: it lets the provider rotate the key without a DNS change on the sender's side each time. A single publication, and key rotation becomes transparent. The raw TXT is still valid, but forces a manual step at every renewal.

Generating a key in-house (advanced case)

An organization operating its own sending infrastructure (a Postfix server, for example) generates the pair itself. Conceptually, the sequence runs: creating an RSA key, extracting its public part, building the DNS record. The published record looks like:

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

The p= contains the encoded public key. The corresponding private key stays on the server, read by the signing tool. Two golden rules in this case: protecting the private key like a critical secret, and choosing 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. For a fresh start, 2048 is the choice.

The trap that voids everything: alignment

This is the most expensive mistake. A perfectly valid DKIM key can be generated and published, the signature can "pass," and it still brings nothing to DMARC. Why? Because DMARC requires the signing domain (d= in the signature) to align with the From:. The default DKIM signature of many platforms uses their domain (d=platform.com), not the sender's. 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=example.com. That's precisely what makes a DKIM key useful for DMARC. The full mechanism is in how the three protocols work together.

Verifying the key works

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

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

All of this can be confirmed at once by running the domain through our free analyzer, which checks the presence, validity and alignment of the keys.

Enabling DKIM on common platforms

The exact steps depend on the platform, but the pattern is the same everywhere: enabling DKIM in the console, collecting the record, publishing it, waiting, signing. A few concrete pointers:

• Microsoft 365. In the security portal, under email authentication, an administrator enables DKIM for the domain. Microsoft supplies two CNAMEs (selector1 and selector2) to publish; both serve to allow alternating key rotation. Once published and propagated, signing goes live.
• Google Workspace. In the admin console, under email authentication, an administrator generates a key (2048 bits) for the domain. Google supplies a TXT to publish at the google selector. After propagation, authentication starts.
• Routers and SaaS (Brevo, SendGrid, Mailchimp…). Almost all offer a custom signing domain via one or more CNAMEs. That's also where alignment gets enabled (d=example.com) — the step that makes the signature useful to DMARC.

In all cases, the rule is the same: the administrator copies the value in full, waits for propagation before turning on signing, then confirms the d= is the sender's 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 — signing waits until dig shows the key. 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: DKIM is enabled, the signature passes, but with the provider's d= — the domain looks protected while DMARC relies on nothing. Checking these three points after every activation spares the overwhelming majority of start-up DKIM failures.

A fourth slip is subtler: testing with a single message and concluding everything works. One successful signature proves the happy path, not the whole configuration — a platform can sign correctly from its main sending pool and skip signing on a secondary one (transactional versus marketing, for instance). The reports deserve a close watch for the first few days after activation: a fraction of the volume showing up unsigned or unaligned means a partial configuration caught early, while it's still a detail to adjust rather than a deliverability incident to explain.

Frequently asked questions

Does the key have to be generated in-house? Rarely. Where sending goes through a platform (Microsoft, Google, a SaaS), it generates the pair and keeps the private key. In-house generation only applies to an organization running its own signing infrastructure.

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

Can the same key serve several domains? Best avoided. 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). Signing goes live platform-side only 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; the next rotation replaces it.

DKIM and deliverability: why it really matters

Beyond security, DKIM has a concrete effect on 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, accumulating reputation with every legitimate email that goes out. 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.

Thomas generates 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, the virtual CISO, names for each platform the exact record to publish, checks the signature aligns with the domain, and steers the configuration toward a DKIM that actually counts for DMARC.

Free DMARC analysis or account signup for a correct DKIM the first time.