English Nederlands Español Italiano 日本語 Français
Log in

DKIM|Strategy

Getting DKIM signing in place is only half the job. The other half is deciding how you manage the key pairs behind it: whether every domain gets its own, whether a third party can share one across all its customers, and how often you rotate. Get this wrong and a single leaked key can affect far more than one domain. (New to DKIM? Start with DKIM | Guidelines for the fundamentals.)

Think of a key pair like a house key

A shared DKIM key pair is like handing the same house key to every tenant in a building: convenient to manage, but if one tenant loses it, every lock needs to be changed. A unique key pair per domain is a separate lock per door: more keys to keep track of, but losing one only affects that door.

Why it matters

DKIM uses a public/private key pair, and how that pair is shared (or not) has direct security consequences. A shared key pair used across many domains or customers is operationally convenient, but if it’s ever compromised (or simply reverse-engineered, since key strength degrades as computing power increases), every domain using it is exposed at once. A unique key pair per domain contains that risk to a single domain, at the cost of more pairs to track and rotate.

Unique vs. shared key pairs

Unique key pairs

The main advantage of a unique key pair per domain is containment: if one domain is compromised, only that key pair needs to be replaced. This is the stronger choice from a security standpoint, but it means more operational overhead: more key pairs to generate, publish, and rotate on schedule.

Shared key pairs

A shared key pair (one pair used across multiple domains, or a whole domain portfolio) is far easier to manage operationally. The trade-off is security: a single compromised or recalculated private key exposes every domain that shares it. This isn’t a recommended practice from a security perspective, even though it’s common with some third-party senders.

Shared keys carry shared risk

Some third parties reuse the same DKIM key pair across all of their customers. If that key is ever compromised, every domain relying on it is affected simultaneously, not just yours.

I need more information

The plain-language version above covers the core trade-off. The rest of this article covers best practices for managing key pairs day to day, and what to consider when a third party handles DKIM signing on your behalf.

Best practices

  • Avoid shared key pairs where practical: a compromised shared key exposes every domain using it at once.
  • names must be unique per signing domain: reusing a name across different senders for the same domain causes DKIM failures.
  • Rotate key pairs on a regular schedule; see DKIM | Guidelines for the recommended cadence and overlap window.
  • Keep an inventory of every sender and the DKIM it uses, so the same is never accidentally reused.
  • Where you can, let the sending third party own DKIM key management entirely; see DKIM | External Vendors for how to delegate this via while keeping control of the reference.

Working with third parties

Not every provider treats DKIM key management the same way. Some, like Amazon SES, let you choose: manage your own key pair yourself, or hand responsibility to the provider (Amazon calls its managed option “Easy DKIM”). Others give you no choice at all. Before signing up with a sender, it’s worth checking which model they use, and whether they issue you a unique key pair or share one across their customer base.

Identifying whether a given third party is already signing on behalf of multiple domains, yours included, is worth checking directly against your own sending infrastructure, since it directly affects how much risk a single compromised key represents.

References & further reading