Skip to content
DNS & Domain Setup

Rotating Your DKIM Key in AcelleMail — How to Publish a Fresh Key

AcelleMail has no in-app "rotate key" button — a sending domain's DKIM keypair is fixed at creation. To rotate, you delete the domain and re-add it (which generates a fresh key), publish the new DKIM record at your DNS host, then click Verify DNS records. Here's the safe way to do it.

8 min read Advanced

What this is for

You want to replace the DKIM key AcelleMail uses to sign your mail — maybe your DNS host had a security incident, maybe you're following a compliance policy, or maybe you're just doing routine cryptographic housekeeping. This guide shows the actual path AcelleMail gives you for that.

Set expectations first. AcelleMail does not have a "Rotate key" button, a dual-signing mode, or a per-key selector picker. When you add a sending domain, AcelleMail generates one DKIM keypair and binds it to that domain permanently — there is no Edit or Update on a sending domain for exactly this reason (renaming or re-keying in place would silently break verification and signing).

So "rotating" in AcelleMail means one concrete thing: delete the domain, re-add it (which generates a brand-new key), publish the new DKIM record at your DNS host, and re-verify. That's the whole playbook. The rest of this article is how to do that with the least delivery disruption.

Before you start

  • You'll need access to your DNS host (Cloudflare, Route 53, Namecheap, GoDaddy, etc.) — you'll edit one TXT record there.
  • Pick a low-traffic window. There's a short gap between deleting/re-adding the domain and your new record verifying, during which fresh sends from that domain won't carry a passing DKIM signature.
  • Know your domain's exact name as it appears under Sending → Sending domains (e.g. mail.brand.com).

How AcelleMail's DKIM actually works

Worth understanding before you touch anything, because it changes the steps.

  • When you add a sending domain, AcelleMail generates an RSA keypair locally and stores the private key. It builds the DNS records you need to publish — including the DKIM record.
  • The DKIM record AcelleMail asks you to publish is a TXT record at selector._domainkey.yourdomain.com. (CNAME-style DKIM is something only certain external sending vendors use — for a domain AcelleMail signs itself, it's a TXT record containing the public key.)
  • The selector is a single value set for your whole install (it defaults to acelle). It's the same for every domain you add. That matters for rotation: because the selector stays the same, your new DKIM TXT record sits at the same host name as the old one — so re-adding replaces the public key at one address rather than creating a second parallel record.

That last point is the key insight. There's no "old key + new key both live" period in AcelleMail. You swap the public key at one DNS host name and re-verify.

Step 1 — Open Sending domains

In AcelleMail's sidebar, go to Sending → Sending domains. The page is titled Sending Domains and lists every domain you've added with a Verified / Unverified status.

This is your starting point. Note the domain you're about to rotate — you'll re-create it with the exact same name in a moment.

Step 2 — Note your current DNS records (so you can compare later)

Click the domain name in the list to open its detail page (titled Domain authentication). You'll see:

  • A status badge — Verified (green) or Unverified (orange).
  • A DNS records card listing each record you need to publish, grouped by purpose. For a domain AcelleMail signs itself, that's Domain identity (the ownership TXT record) and DKIM signature (the TXT record carrying the public key). An SPF record row also appears if your administrator has configured a global SPF value for the install. Each row has a Type, Host, Value, and a per-record Verified / Pending status.

Take a screenshot or copy the current DKIM signature row's Value. After you re-add the domain, you'll compare the new DKIM TXT value against this one — they should differ (that's how you know you got a fresh key).

Step 3 — Delete the domain

Back on Sending → Sending domains, select the domain's checkbox. A bulk-action bar appears with a Delete button. Click it and confirm — AcelleMail warns "Delete selected sending domains? This cannot be undone."

Deleting removes AcelleMail's record of the domain and its old private key. Your DNS records still physically exist at your host until you change them — deleting in AcelleMail doesn't touch your DNS.

Heads up: from this moment until Step 6 completes, mail you send from this domain won't sign with a valid DKIM key. Keep the window short.

Step 4 — Re-add the domain (this generates the new key)

Click Add domain. A popup appears with a single field — the domain name. Type the exact same domain you just deleted (e.g. mail.brand.com) and submit.

AcelleMail generates a fresh DKIM keypair for the domain and lands you back on the Domain authentication detail page, now showing Unverified with a fresh set of DNS records to publish.

Step 5 — Publish the new DKIM record at your DNS host

On the detail page, the DNS records card shows the records to publish. The one that changed is the DKIM signature row — same Host as before (because the selector is unchanged), but a new Value (the new public key).

At your DNS host:

  1. Find the existing DKIM TXT record at that host name (selector._domainkey.yourdomain.com).
  2. Update its value to the new value AcelleMail shows. Copy the Value field verbatim — DKIM TXT values are long and a single dropped character breaks the signature.
  3. Save.

Because the host name is identical, you're editing one record, not adding a second. If your DNS host won't let you edit in place, delete the old TXT and create a new one at the same name with the new value.

The card also shows the Domain identity (ownership) row, and an SPF row if your install has one configured. If AcelleMail shows a new ownership token after re-adding, update that record too; if it's unchanged, leave it.

Step 6 — Re-verify

On the Domain authentication page, click Verify DNS records in the page header. AcelleMail queries your DNS and re-checks every record. While it works the button shows "Verifying...".

  • All records confirmed → "Domain verified successfully! All DNS records are confirmed." and the status badge flips to Verified.
  • Still propagating → "Verification in progress. Some DNS records are still pending — this can take up to 48 hours."

DNS changes take anywhere from 15 minutes to 48 hours to propagate worldwide (AcelleMail's own guide cards say this). If your DKIM row still shows Pending, wait and click Verify DNS records again — you can re-check as often as you like.

Step 7 — Confirm the new key is signing

Once the domain reads Verified, send yourself a test campaign from an address on that domain. In Gmail, open the message → ⋮ → Show original and look at the DKIM-Signature: line:

  • d= should be your domain.
  • s= should be your install's selector (the same one as before — the selector doesn't change; the key behind it did).
  • The header should show dkim=pass.

That's the whole rotation. There's exactly one DKIM-Signature header (AcelleMail signs with one key), and it now uses your fresh keypair.

Common issues

What you see What to do
DKIM row stays Pending after re-verify DNS hasn't propagated. Wait (up to 48h) and click Verify DNS records again. Confirm the TXT value at your host matches AcelleMail's Value exactly.
Test email shows dkim=fail after re-add The TXT value at your DNS host doesn't match — almost always a truncated or mis-pasted public key. Re-copy the Value from the DKIM signature row and replace it.
You added a second DKIM TXT record by mistake Since the selector is unchanged, you only want one record at that host name. Delete the stale one so only AcelleMail's current value is published.
Domain shows Unverified but you didn't touch DNS If you deleted and haven't re-added yet, that's expected. Finish Steps 4–6.
You can't find an Edit button on a domain There isn't one — that's by design. To change a domain's key, you delete and re-add (this guide).

When to rotate

There's no enforced schedule and no app reminder, so this is your call:

  • Rotate now if your DNS host had a security incident, or a compliance audit requires it.
  • Routine rotation (e.g. once a year) is reasonable cryptographic hygiene but optional.
  • Don't rotate during a critical send window (a big launch, a seasonal campaign). The short verify gap in Step 3–6 means fresh sends temporarily lose a passing DKIM signature — do it on a quiet day.

If you run several sending domains, rotate them one at a time and confirm each reads Verified before starting the next — far easier to debug than a batch.

What to do after

Related articles

Tagged

19 comments

11 comments

  1. Ahmed
    What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector or separate?
    1. Admin
      Separate keys, one per sending subdomain. Worth knowing: the selector name doesn't actually have to differ. DKIM lookups are scoped by the d= domain, so `s1._domainkey.mail.example.com` and `s1._domainkey.notifications.example.com` are two completely independent TXT records even though the selector string is the same. Reusing the name is legal. But I'd still give them different keypairs, because the whole point of rotation is being able to burn one without touching the other. If notifications.example.com starts having reputation trouble or a key leaks, you want to rotate that one alone and leave your transactional stream untouched. Shared key material means shared blast radius. In practice I'd add each subdomain as its own sending domain in the app and let it generate its own key, then rotate them on independent schedules. Naming them by purpose rather than `s1`/`s2` helps a lot six months later when you're staring at DNS trying to remember which is which.
  2. Thuỳ
    How do you handle DNS for clients in white-label setups? The customer would need to add records to their domain — is there a clean way to bulk-verify those?
    1. Admin
      There's no bulk-verify button today. Each sending domain gets its own DKIM record and its own verify check, so at the moment a white-label reseller has to walk the list one by one after the customer publishes. Two things that make it less painful in practice. First, hand the customer the exact TXT record (selector plus value) rather than instructions, most of the failed rotations we see are someone pasting the whole `v=DKIM1; k=rsa; p=...` string into the hostname field. Second, keep the old selector live for a few days after the new one resolves, DKIM is selector-scoped so both can validate at once and nothing in flight breaks. A batch re-check across all domains for an account is a fair ask and it's on the list, I just don't have a date. If you're running enough domains that manual checking hurts, tell me roughly how many and I'll use that to size it.
  3. Vera
    If you use Vercel or Netlify for the apex, watch out — they sometimes override TXT records via their auto-DNS feature. Bit us once with a stripped SPF record.
    1. Admin
      That one is nasty because it fails quietly. Netlify's auto-DNS in particular likes to reassert its own record set on the apex, and anything it doesn't know about gets dropped. DKIM usually survives since the selector lives on a subdomain like `s1._domainkey`, but SPF and DMARC sit on the apex and are fair game. Worth noting for rotation specifically: if you're mid-rotation with two selectors published and the provider wipes one, signing keeps working on the surviving key and you won't notice until you retire the wrong one. So dig the selector directly after any DNS panel change rather than trusting the UI: dig +short s2._domainkey.yourdomain.com TXT I'll add a callout about managed-DNS providers to the article. If you remember whether it was Vercel or Netlify that stripped yours, that'd help me name the right one instead of hand-waving at both.
  4. James
    the spf flattening explanation finally made it click for me. i'd been hitting the 10-lookup limit and didn't understand why nesting includes counted.
    1. Admin
      The nesting part catches almost everyone. Each `include:` costs a lookup, and every `include:` inside that one costs another, so a record that looks like three entries can be nine by the time the resolver finishes. `a`, `mx`, `ptr` and `exists` count too, `ip4`/`ip6` don't, which is why flattening works at all. One caveat before you flatten and forget about it: you're pinning your record to IPs your provider owns and can change without telling you. If you flatten a big sender like Google or Microsoft, re-check the expansion on a schedule or you'll get silent SPF failures months later when they add a range. Flattening the small fixed senders and leaving the big ones as includes usually gets you under 10 without that maintenance burden.
  5. Ravi
    our dkim rotation broke for 2 days because we updated the active selector first, then waited to delete the old. should be the other way — publish new, wait 48h for cache, switch sending, then remove old...
  6. Chen
    Quick question: do receivers actually enforce the SPF -all hard fail, or do most just downrate? I've heard mixed things and I'm hesitant to switch from ~all.
    1. Admin
      Mixed is about right, because it depends on the receiver. Gmail and Microsoft mostly treat SPF fail as one signal and let DMARC decide the outcome, so -all vs ~all makes little difference there if you have a DMARC policy. Smaller filters and some corporate gateways do reject on -all outright. In practice the thing that actually decides your fate is the DMARC p= value, not the SPF qualifier. If you're on p=none or p=quarantine and your sources are all accounted for, moving to -all is low risk. If you're not sure every sender is in the record yet, stay on ~all and read the aggregate reports for a couple of weeks first.
  7. David
    worth noting: our dns provider (cloudflare) caches negative responses for 1 hour. we added a txt record, dig showed it, but mail-tester said missing for another 40 minutes. almost lost our minds. ttl was set to 300 but the parent zone ns cache held.
  8. Marcus
    Hit the 10-lookup SPF limit when we tried to layer SES on top of an existing Google Workspace setup. Flattened with a tool (spfwizard.com) and its been fine since. That tool's worth a mention.
    1. Admin
      Flattening works, but it's worth knowing what you traded away. Once you inline SES's IPs into your own record, you stop tracking their changes. Amazon does rotate and add ranges, and when that happens your flattened record is silently wrong until something starts failing SPF. If you go that route, re-run the flatten on a schedule (monthly is enough) or use a tool that hosts the record and updates it for you. The cheaper fix first: Google Workspace's include costs you 3 or 4 lookups depending on what else you've got, and most setups over the limit are carrying two or three includes for services they stopped using a year ago. Worth auditing before you flatten. This article is only about DKIM rotation so I won't put SPF flattening in here, but the SPF lookup limit deserves its own page and I'll write one. I'd rather not name a specific third-party tool in it since I can't vouch for how they'll behave long term.
  9. Emma
    dns setup is one of those things where you don't know what you don't know. this article should be required reading for anyone running their own mail.
  10. Yuki
    Easy win: set up dmarcian.com (free tier) to receive your DMARC RUA reports. The first 2 weeks of reports tell you everything you didnt know about who's sending as you.
    1. Admin
      RUA reports are underrated, especially right after a rotation. During the overlap window you've got the old and new selector both live, and the aggregate reports are the only cheap way to see which one your actual traffic is signing with before you retire the old key. If a forgotten app is still signing with the old selector, it shows up there and nowhere else. Two caveats worth knowing. RUA is aggregate only, so you get selector and pass/fail counts, not message bodies, and reports land daily-ish rather than in real time. Don't plan a rotation cutover around them expecting same-hour feedback. I'll add a section on reading RUA during the overlap window to the article, the rotation steps currently stop at "publish the new key" and that's a gap.
  11. Tomas
    thanks for the explicit cautionary tales. the alignment-vs-pass distinction is exactly where i lost a week last year.
    1. Admin
      The dashboard only shows pass or fail, so read the raw Authentication-Results on a seed message and check d= against your From domain before retiring the old selector.

Related reading

More in DNS & Domain Setup

Run your email marketing on your own server, your own terms

Join thousands of companies that have taken control of their email marketing with full source code, no recurring fees, and unlimited sending. One-time $80 license, lifetime updates.

Get the AcelleMail newsletter

Monthly issue with new releases, deliverability tips, and self-hosting playbooks. No spam.