Most DKIM posts are written for the moment a signature has already broken: a migration that left the old key behind, a selector pointing nowhere, a client's mail suddenly failing DMARC. This one is about the DKIM key that isn't broken at all, the one that's quietly signed a client domain's mail for two or three years and has never been touched since the day it was created. Rotating it on a schedule, before anything forces the issue, is routine security hygiene for any domain, whether its mailboxes sit on Atriomail, a self-hosted server, or somewhere else.

A long-lived private key is a long-lived target, and the DNS record carrying its public half never expires on its own. Done carelessly, though, rotation creates the exact outage it's meant to prevent: remove the old key too early and mail still in flight, signed under a key that's now gone, fails DKIM for no reason visible in the message itself. This guide walks through doing it safely, with a new selector published alongside the old one before anything changes, and ends with what this looks like on a domain whose mailboxes live on Atriomail, including the one part Atriomail doesn't give you a control for.

Table of Contents

Key Takeaways

Point Why it matters
Never reuse the old selector name with a new key RFC 6376 warns this makes it impossible to tell a message that failed because the key rotated from one that's actually forged. Every new key gets a selector name that's never been used before.
Run two selectors in parallel during the cutover Publishing the new selector days before you switch signing over means the DNS record has already propagated everywhere by the time any mail actually depends on it.
The old selector has to outlive the cutover, not end with it Mail queued or retried by a slow downstream server can still carry the old key's signature for days after you've switched. Remove that record too soon and those messages fail DKIM for no visible reason.
Major platforms handle this very differently Microsoft 365 ships a one-click rotation control with a built-in four-day delayed cutover; Google Workspace requires generating and activating a new record by hand, with no automatic schedule.
What Atriomail does for this Generates one DKIM key per domain automatically, ready to copy or auto-published on Cloudflare and Namecheap, but has no documented control to generate a second selector or rotate that key yourself.

One key per domain, generated for you. Atriomail writes a domain's DKIM key the moment the domain clears its security check, ready to copy from the DNS Setup dialog or published automatically on a connected Cloudflare or Namecheap account. Rotating that key on your own schedule, the task this guide walks through, is handled directly at the domain's DNS host either way.

Create your account   See pricing

Before You Start

  • Admin access to the domain's DNS zone, specifically the ability to add and later remove TXT records under _domainkey. This is the only place DKIM selectors actually live.
  • Access to whatever signs the domain's outgoing mail today: the mail platform's admin console, a cPanel or Plesk DKIM feature, or a self-hosted mail transfer agent's key configuration. Rotation changes what signs, not just what's published.
  • The domain's current selector name and signing domain, read directly from a recent outgoing message's own DKIM-Signature header, covered in the next section. Guessing this from memory is how a rotation accidentally collides with the record already in production.
  • A selector-naming convention that's never been used on this domain, such as a date stamp (s2026b) or a simple counter (dkim2). Whatever it is, decide it before generating anything.
  • A multi-week window, not an afternoon. A safe rotation has a propagation period, a cutover, an observation period, and only then a retirement step. Rushing straight to deleting the old record is where this goes wrong.

Read the Current DKIM-Signature Header First

Before generating anything new, confirm exactly what's live today. Send a test message from the domain to an account you control, then open its full headers: in Gmail, the three-dot menu on an open message has a "Show original" option; most other clients call it "view message source" or "view headers." Find the DKIM-Signature header and read two of its tags. Per RFC 6376's own definition of the namespace, "given a DKIM-Signature field with a 'd=' tag of 'example.com' and an 's=' tag of 'foo.bar', the DNS query will be for 'foo.bar._domainkey.example.com'" (RFC 6376, Section 3.6.2.1, rfc-editor.org, checked October 2026). The d= value confirms exactly which domain is signing, useful if a domain's DNS setup involves a white-label hostname or a subdomain, and the s= value is the selector name currently in production. That selector name is the one the new key must never reuse.

The selector name is the whole safety mechanism. A new key under a brand-new selector can be published, tested and even abandoned without ever touching the record that's currently signing live mail. That's the entire reason this takes a few steps instead of one.

Create your account   Check a domain's DNS free

Generate the New Key and a Selector Name You've Never Used

A key that's never failed is still a key worth replacing on a schedule, the same reasoning behind why a password reset alone doesn't fix a compromised account: age and exposure matter on their own, independently of whether anything visible has gone wrong yet. RFC 6376 is direct about why the selector matters here: "reusing a selector with a new key makes it impossible to tell the difference between a message that didn't verify because the key is no longer valid and a message that is actually forged," recommending instead that "a better strategy is to assign new keys to new selectors" (RFC 6376, Section 3.1, checked October 2026). Generate a new RSA key pair at 2048 bits; Google Workspace's own current setup guidance recommends 2048-bit over 1024-bit because "longer keys are more secure than shorter keys" (Google Workspace Admin Help, knowledge.workspace.google.com, checked October 2026), and platforms still defaulting to 1024-bit do so for historical compatibility, not because it's the safer choice today. Whatever generates the key, usually the mail platform's own DKIM feature or a command-line tool like OpenSSL, will produce the public half formatted for a DNS TXT record with a v=, k= and p= tag (RFC 6376, Section 3.6.1). Pair it with the fresh selector name chosen before you started.

Publish the New Selector Alongside the Old One

Add the new key as a TXT record at newselector._domainkey.clientdomain.com, using whichever selector name you chose. Leave the existing record, at the old selector's name, completely untouched. At this point the domain has two valid DKIM keys published at once, which is exactly the intended state: nothing is signing with the new one yet, so there's zero risk, but the record is live and has time to propagate through every resolver and cache that might eventually need it, the same propagation patience that matters for any DNS-based mail record, including the one covered in fixing an SPF record with too many DNS lookups. Give this at least a few days before moving to the next step.

Switch Signing to the New Selector

Once the new record has had time to propagate, point the mail platform's signing configuration at the new key and selector. How this step looks depends on what's doing the signing. Microsoft 365 automates most of it: the platform already maintains two CNAME-based selectors, selector1._domainkey and selector2._domainkey, with "only one selector... active and used" at a time, and a built-in "Rotate DKIM keys" control that activates the inactive one (Microsoft Learn, "How to use DKIM for email in your custom domain," learn.microsoft.com, checked October 2026). That same documentation notes "the change isn't immediate. It takes four days (96 hours) for the new private key to start signing messages," a delay built into the platform itself. Google Workspace has no such automation: an admin generates a new record by hand through the Gmail authentication settings in the Admin console and clicks "Start authentication" to activate it, with no documented automatic schedule (Google Workspace Admin Help, checked October 2026). A self-hosted server or a hosting-panel DKIM feature works the same way as Google's manual path, flipping the active selector on your own timeline, which is exactly why skipping the propagation wait above is the easiest way to turn this into an outage.

Retire the Old Selector on a Safe Schedule

Resist removing the old selector's DNS record the day signing switches over. RFC 6376 frames the caution from the signer's side: "a Signer should not sign with a private key when the selector containing the corresponding public key is expected to be revoked or removed before the Verifier has an opportunity to validate the signature" (RFC 6376, Section 5.2, checked October 2026), exactly the situation a too-fast removal creates in reverse. Mail that was queued or retried by a slow downstream server can still carry the old selector's signature well after the main switch is done; if that record is already gone, a legitimate message fails DKIM with no indication of why. Keep the old record published for at least a week or two past cutover, longer for a domain with its own retry queue, before removing it.

How to Verify It Worked

  • Query the new selector's DNS record directly with dig TXT newselector._domainkey.clientdomain.com +short and confirm the v=, k= and p= values match exactly what was generated.
  • Send a real test message after the cutover and open its full headers the same way described earlier (Gmail's "Show original," or "view message source" elsewhere). Confirm the DKIM-Signature header's s= tag now reads the new selector, and that the authentication result for DKIM shows a pass.
  • Run the domain through Atriomail's free DNS checker at /dns-checker/, entering the new selector by name, to confirm the record resolves and is well-formed. Since DKIM has no single discoverable location the way MX or SPF do, the checker only looks at the exact selector you type in, so check the old selector the same way during the overlap window, and check it again after retirement to confirm it's genuinely gone rather than quietly still live.
  • Watch for anything still signing with the old key a week or two after cutover. A quiet secondary sender, a marketing tool, a helpdesk platform, or a second outbound server that nobody remembered to update, is the most common reason an otherwise-clean rotation still has a loose end.

Common Mistakes and How to Avoid Them

  • Reusing the old selector name for the new key. Symptom: once anything goes wrong later, there's no way to tell whether a given DKIM failure is a forged message or simply an artifact of the key having changed, the exact ambiguity RFC 6376 warns the selector mechanism exists to prevent.
  • Switching signing over before the new record has propagated. Symptom: DKIM fails broadly, right after cutover, at receivers whose resolvers hadn't picked up the new selector's record yet.
  • Removing the old selector the same day signing switches. Symptom: a handful of DKIM failures trickle in over the following days, all for messages that were queued, deferred or retried before the cutover and are only now completing delivery under a key that no longer exists in DNS.
  • Missing a secondary signing source. Symptom: the "main" mail flow verifies cleanly with the new key, but one specific sending path, often a third-party tool configured once years ago, keeps failing because nobody updated it.
  • Defaulting back to a 1024-bit key out of habit. Symptom: nothing breaks today, but the domain has just spent a rotation cycle re-adopting a key length multiple mail providers' own documentation already treats as the weaker legacy option.
  • Confirming the DNS record exists but never confirming a real message signs with it. Symptom: a rotation that looks complete in every lookup tool still hasn't been proven against an actual sent email's headers.

Rolling a rotation like this out across an entire client book multiplies every one of these, the same discipline covered in managing multi-client email at scale, and it's worth a heads-up through whatever client support process already covers planned DNS changes, consistent with the reseller's email security playbook.

Doing This on Atriomail

For a domain hosted on Atriomail, the panel generates a single DKIM key automatically once the domain clears its security check, ready to copy from that domain's DNS Setup dialog, or published directly into the zone on a connected Cloudflare or Namecheap account alongside the domain's MX, SPF, DMARC, autodiscover and autoconfig records, covered in more detail in connecting Cloudflare and Namecheap for automatic mail DNS. That covers getting a key published in the first place. What it doesn't cover is the task this guide is actually about: there's no documented control in the panel, or through the API, to generate a second selector or rotate that key on a schedule of your own choosing. The key Atriomail generates for a domain is the key that domain signs with, and that's the honest limit, not a gap unique to Atriomail among smaller platforms, just one worth planning around rather than assuming away.

For a reseller running the white-label add-on, this works the same regardless of whether the domain's mail server hostname shown to clients is Atriomail's own or the reseller's branded one: one key, generated automatically, per domain. If a rotation schedule is part of a client's own security requirements or a compliance checklist you've committed to, that's a conversation to have before onboarding a domain with that requirement, not after, the same groundwork covered in setting up and branding a client's email domain. None of this changes what a mailbox costs: a domain gets the same automatically-generated DKIM key and DNS Setup dialog at $1.39 per mailbox with 15 GB included, whether or not key rotation is part of the plan. Create your account to see a domain's own DNS Setup dialog before deciding whether the one-key limit changes anything about onboarding it.

Know the limit before you promise a client a rotation schedule. Atriomail generates and, on Cloudflare or Namecheap, publishes one DKIM key per domain automatically. A self-managed rotation schedule, the kind this guide walks through, isn't a documented panel control today, so factor that into any client commitment around key-rotation cadence.

Create your account   Talk to the team

Frequently Asked Questions

Why rotate a DKIM key that isn't broken or compromised?

Same reason you rotate a password that hasn't leaked yet: a key that's been signing mail for years is a key that's been sitting in front of anyone who could eventually factor it or has already quietly leaked from a backup, a log file or an old server. Routine rotation on a schedule costs an hour or two; finding out a key was compromised after the fact costs a lot more.

How long should the old and new selectors run in parallel before I remove the old one?

Give the new selector's DNS record at least a few days to propagate everywhere before cutting signing over, then keep the old selector's record published for a further week or two after cutover. Mail already queued or being retried by a slow downstream server can still carry the old selector's signature days after you've switched, and if that record is already gone, those messages fail DKIM for no visible reason.

Does Atriomail let me generate a second DKIM selector or rotate the key myself?

No. Atriomail generates one DKIM key per domain automatically, ready to copy from that domain's DNS Setup dialog, or published automatically on a connected Cloudflare or Namecheap account. There's no documented panel control to generate a second selector or rotate that key on your own schedule.

What happens to already-queued mail if I remove the old selector too soon?

It fails DKIM, even though nothing about the message itself is wrong. A receiving server that defers a message and retries it later, or a sending queue that was simply backed up, can still sign with the old selector days after you've switched your main signing over to the new one. If that selector's DNS record is already removed, the signature can't be verified.

Can I just reuse the same selector name with a new key instead of creating a new one?

RFC 6376 specifically warns against this: reusing a selector with a new key makes it impossible to tell a message that failed because the key rotated from one that's actually forged. The specification's own guidance is to assign every new key to a selector name that hasn't been used before.

Does Atriomail's free DNS checker show which DKIM selector is currently active?

It checks whichever selector you type in, since DKIM has no fixed, discoverable location the way MX or SPF do. During a rotation, that's useful for confirming both the old and new selector resolve and are well-formed at the same time, but you need to already know the selector names; the checker doesn't enumerate them for you.

Latest from the blog