DKIM keys should rotate. Most operators don't do it because the dance is fiddly: generate key, publish DNS, wait for propagation, cut over MTA, verify, retire old key, document for compliance. Each step has a way to break delivery if you move too fast or skip verification. Most teams plan to rotate "next quarter" for years.
We run the rotation. Quarterly cadence per domain (or your chosen frequency). Dual-publication overlap so old and new keys both validate during cutover. MTA configuration updated and verified before the old key retires. Documentation shipped for your compliance evidence. €29/month flat per domain rotated, cancel anytime.
The first reason is security. A DKIM private key signs authenticity of your sending. If the key leaks (compromised server, accidental git commit, social engineering attack on your operations team), an attacker can sign mail as your domain until you rotate. Static keys mean unbounded compromise windows. Rotated quarterly, the maximum compromise window is ~90 days. Rotated monthly, ~30 days. Smaller blast radius matters during incident response.
The second reason is compliance. SOC 2 Type II, ISO 27001, PCI-DSS, NIST 800-53, and similar frameworks have key management requirements that include periodic rotation. The specific cadence requirements vary, but "we rotate quarterly with documented evidence" satisfies almost all of them. "We've been using the same key since 2019" satisfies none. Auditors specifically check this for environments handling customer data over email.
The third reason is reputation. Receivers' reputation systems observe DKIM key behaviour. Senders who rotate keys quarterly look like senders with mature operations; senders with static keys for years look like senders who have stopped maintaining their infrastructure. Gmail's Postmaster Tools doesn't expose this signal directly but their reputation models incorporate it. Senders who rotate appropriately benefit at the margin. The benefit is small but cumulative over time.
The honest counter-argument: rotation also creates risk. A rotation done wrong (DNS not propagated, MTA cutover before verification, old key retired too early) breaks DKIM signing and damages reputation faster than not rotating at all. That's why most teams don't rotate; the downside risk feels larger than the upside benefit. We run rotations regularly enough that the operational discipline is established; for teams rotating once per quarter manually, the per-rotation risk is higher because the muscle memory isn't there.
Different cadences fit different operations. Click each to see what it gains and what it costs. Most senders default to quarterly; some specific cases benefit from faster or slower.
Once per year is the minimum cadence that satisfies most compliance frameworks. Acceptable for low-risk transactional sending where DKIM compromise impact is limited and attack surface is small.
Annual rotation creates a ~365-day compromise window if a key leaks. For most commercial sending, that's a long blast radius but tolerable. For sending that carries authentication weight (signed receipts, account notices, financial transactions), the window is too long.
Click any step to see what's happening at that point. The dual-publication overlap (steps 2-5) is where most DIY rotations break; the discipline of waiting for verification before retiring is what differentiates clean rotations from broken ones.
We generate a fresh 2048-bit RSA private key on a hardened key-generation host. The new public key gets formatted as a TXT record value ready for DNS publication. The private key transfers via encrypted channel to your sending infrastructure (or stays on ours if we host).
Selector convention: year-quarter. Example for Q2 2026:
2026q2._domainkey.yourdomain.com. This
convention makes selectors self-describing without
exposing rotation history; auditors can see the
rotation cadence by looking at active selectors.
Set how many domains you operate and how often you'd rotate if you did it yourself. The calculator shows time saved versus our managed rotation. Single-domain DIY usually wins economically; multi-domain quickly tips the math.
Each domain needs its own DKIM keypair and rotation. Multi-brand operators typically rotate across 5-20 domains.
Faster cadence = more rotations per year = more compounding time savings on the managed path.
DIY rotation: planning (15min), key generation (15min), DNS (15min), MTA reconfig (30min), verification (30min), documentation (15min). 2h is optimistic for typical ops.
What an hour of your team's time is worth, accounting for opportunity cost. Engineering time often values higher than this estimate.
Plus the risk of broken rotations damaging deliverability when DNS, MTA, or verification steps fail.
Bulk pricing applies past 5 domains: €99/mo for 5, €179/mo for 10. Single-domain pricing is €29/mo.
For your domain count and cadence, managed rotation is net positive. Plus the risk reduction from disciplined rotation execution.
Math: DIY annual hours × hourly rate vs managed monthly fee × 12. The calculator excludes the cost of broken rotations (DKIM signing failures, deliverability damage during cutover) which favours managed further. For single-domain operators willing to invest the time, DIY is rational; for multi-domain operators, the math rarely supports DIY past 5 domains.
Default cadence: every 90 days. New key generation, DNS publication, MTA cutover, verification, old key retirement. Each rotation runs end-to-end without your involvement beyond initial setup access.
Custom cadences supported: monthly (€39/mo per domain due to 4x rotation count), annual (still €29/mo because the ongoing infrastructure costs are similar). Most customers stick with quarterly.
Industry-standard 2048-bit keys. We don't generate 1024-bit keys (deprecated by Gmail, Yahoo since 2024) or weaker algorithms. RSA over Ed25519 because RSA enjoys broader receiver support; some receivers still don't validate Ed25519 DKIM signatures cleanly.
Selectors named with year-quarter pattern:
2026q1, 2026q2, etc. Self-
describing, sortable, doesn't expose rotation history beyond
the active selector. Custom naming supported if you have
existing conventions; default is recommended.
New key published 7 days before MTA cutover. DNS propagation varies (most resolvers within 1 hour; long-cached resolvers up to 48 hours). The 7-day buffer ensures all caches see the new key before it's needed for verification.
Old key remains published for 30 days after MTA cutover. In-flight messages signed with old key (on receivers' queues or in temporary storage) still verify cleanly during this buffer. Without the buffer, those messages might fail DKIM and damage reputation.
We update MTA configuration to use new selector. Supported: PowerMTA (config.cf domain-key block), Postfix (OpenDKIM milter config), MailWizz (admin panel update), sendmail-style configs, custom MTAs (we work with whatever you run).
For self-hosted infrastructure where we don't have direct access, we provide the exact configuration changes for your team to apply. Verification step coordinates with your cutover.
Sample test sends through major receivers (Gmail, Outlook, Yahoo, Apple, AOL) confirm DKIM=pass on the new key. Verification runs after MTA cutover; if it fails, we roll back the cutover before retiring the old key. Failed rotations are caught and reverted before damage occurs.
Each rotation produces a signed log: timestamps for each step, old/new selectors, key fingerprints, verification results, sample headers showing successful DKIM=pass on both old and new keys during overlap. Audit-ready format.
Logs delivered via Telegram and stored in your customer portal. Auditors can directly access the documentation if you grant access; otherwise you forward to them as needed.
Single domain: €29/mo. 5 domains: €99/mo (€19.80 each). 10 domains: €179/mo (€17.90 each). 20+ domains: custom quote. Pricing reflects the operational economics of running multiple rotations simultaneously rather than arbitrary discount tiers.
Domain additions and removals adjust pricing on next billing cycle. No contract requirements; cancel anytime.
Three reasons. Security: rotation limits the window of damage if a private key is compromised. Static keys mean unbounded compromise windows. Compliance: SOC 2, ISO 27001, PCI-DSS, and similar frameworks require key rotation policies. Reputation: rotating keys signals mature operations to receivers; static keys for years signals neglect. Reputation impact is small but cumulative.
Quarterly is the established practice. Some compliance frameworks recommend monthly for high-security environments; annual is acceptable for low-risk transactional sending. We default to quarterly because it balances security gain against operational overhead.
Custom cadences supported: monthly (€39/mo per domain), annual (€29/mo same as quarterly because ongoing costs are similar).
Done correctly, no. The dual-publication overlap (7 days before cutover, 30 days after) ensures DNS propagation is complete and in-flight messages still verify. Done incorrectly (which is why most teams fear DIY rotation), yes.
Common DIY failure modes we don't have: rotating before DNS propagates, retiring old key while in-flight messages still need it, MTA cutover without verification, generating a new key but forgetting to update DKIM-Signature header domain in MTA, multiple DKIM keys signed by different services not coordinated. We handle all of these disciplines as standard operational practice.
We coordinate. Each sender that signs DKIM for your domain uses its own selector; rotation applies per-sender. We handle the rotation for senders we manage (PowerMTA, MailWizz, our infrastructure) and document what your other ESPs do.
Major ESPs (Mailgun, SendGrid, AWS SES) handle their own DKIM rotation on their own cadence; we don't override that. We rotate the selectors we control and ensure they coordinate cleanly with the ESP-managed selectors.
Yes. The 7-step process is documented in our wiki at no charge. The work isn't secret; the discipline is what we charge for. If you have engineering time and willingness to follow the procedure quarterly, DIY is rational. The calculator on this page helps think through whether managed rotation makes economic sense for your case.
We detect failure during verification (step 5). Failed rotations roll back: MTA reverted to old key, new key DNS removed, old key kept active. No DKIM downtime occurs because the old key is still published and the MTA still uses it. We investigate the cause and retry once root cause is identified.
Across 800+ rotations executed, we've had 4 failures during verification. Causes were: DNS provider rate- limiting (1), DKIM signing-domain mismatch in MTA config (2), receiver-side DNSSEC validation failure (1). All rolled back cleanly without delivery impact.
Yes. Each rotation produces a log including: timestamps for each step, old/new selectors, key fingerprints (not the keys themselves), verification results from sample sends, sample headers showing DKIM=pass during overlap. Format satisfies SOC 2, ISO 27001, and PCI-DSS evidence requirements. Auditors typically accept these logs without further questions.
We support Ed25519 if you specifically request it. Coverage is improving (Gmail validates, Microsoft validates, Yahoo validates) but not universal. Some smaller receivers and corporate filters still don't validate Ed25519 cleanly; messages signed with Ed25519 only may show DKIM=neutral at those receivers, which is suboptimal.
Best practice: dual-sign with both RSA and Ed25519. We generate both keypairs, publish both, and configure MTA to sign both. €39/mo per domain for dual signing (vs €29 for RSA only). Most customers stick with RSA-only at 2048 bits because the receiver coverage benefit doesn't justify the operational complexity for most sending.
Cancel anytime via Telegram. No notice period, no contract. Last-rotation logs delivered as final handover. After cancellation, your existing DKIM keys remain in DNS and functional; we just stop performing rotations. You'll keep the most recent key indefinitely until you (or someone) rotate again.
Monthly billing in advance. Payable in any of our 11 supported cryptocurrencies via self-hosted BTCPay. Pre- paid 6-month subscription: 5% discount. Pre-paid 12-month: 10% discount. Bulk pricing applies before discounts. Domain count adjustments apply on next billing cycle.
We offer two DKIM rotation tiers. The standard tier (this service) handles the mechanical operation of rotating keys on a scheduled cadence for single-domain operations. The premium tier (documented separately) adds operational sophistication for multi-domain, multi-tenant, or HSM-integrated requirements.
Standard tier appropriate when: operator has single sending domain or small fixed set of domains, rotation cadence aligns with standard quarterly schedule, no HSM integration requirements, no compliance frameworks requiring audit-grade key management documentation. Most operators with straightforward sending operations fit this tier indefinitely.
Premium tier appropriate when: operator manages many domains with independent rotation schedules, ESP-style operations with per-customer key management, compliance frameworks require cryptographic audit evidence, HSM integration is operationally required or strongly preferred. The premium tier addresses specific operational requirements that the standard tier does not optimize for.
The pricing differential reflects the operational sophistication: standard tier at EUR 19 monthly per domain, premium tier at EUR 99 monthly with broader scope. The choice between tiers should match the operators specific operational requirements rather than aspirational positioning.
DKIM rotation cadence should match the senders volume profile and receiver-side expectations. The standard cadence options that production senders settle on:
Quarterly rotation (90-day cycle): the standard cadence for high-volume sending operations. The frequency matches receiver-side expectations that have tightened through 2024-2026, prevents the static-configuration negative signal that older keys produce, distributes rotation events across the calendar so that any single rotation does not look anomalous.
Semi-annual rotation (180-day cycle): appropriate for moderate-volume operations where the operational overhead of quarterly rotation outweighs the marginal receiver-side benefit. The longer cycle still satisfies receiver expectations for active key management.
Annual rotation (365-day cycle): the practical minimum for any production sending. Operations rotating less frequently than annual accumulate the static-configuration negative signal that receivers increasingly weight against senders. Annual rotation appropriate for low-volume operations where quarterly or semi-annual overhead is disproportionate.
Custom cadence based on specific operational requirements: operations with compliance frameworks mandating specific rotation intervals, operations with key compromise concerns requiring more frequent rotation, operations integrating with broader cryptographic key management programs. Custom cadences are supported through the premium tier; standard tier offers the three standard cadences listed above.
DKIM rotation as a managed service handles most operational work but requires specific customer responsibilities that cannot be delegated entirely.
Customer-side DNS publishing: while we generate new keypairs and configure MTAs, the DKIM DNS records must be published in customer-controlled DNS zones. We provide the record content; customer or customer DNS provider publishes it. The publishing happens during the rotation event with our coordination; customer involvement during each rotation typically runs 15-30 minutes.
Validation of correct signing after rotation: customers should verify that signed mail validates correctly through external tools. We test from our side; customers should test from their side to confirm cross-system validation. The verification matters because subtle configuration issues can produce signing that passes our validation but fails at specific receivers.
Communication with downstream systems: customers whose MailWizz, Acelle, or similar control plane references specific DKIM selectors in customer-visible configuration need to coordinate selector references during rotation. We handle the underlying MTA configuration; customer-side coordination of any selector references in ESP control plane configurations remains with the customer.
Incident escalation: if rotation produces deliverability issues that customer monitoring detects but our monitoring did not, the customer should escalate quickly so we can investigate and remediate. The escalation pathway runs through standard support channels with priority handling for active rotation issues.
Each rotation event produces documentation that customers retain for operational and compliance purposes. The documentation captures what happened, when, and what the customer can verify externally.
Standard rotation report contents: timestamp of new keypair generation, selector name chosen for the new key, key size and algorithm used (2048-bit RSA-SHA256 by default), DNS record content for customer publication, MTA configuration change summary, transition period schedule (when old selector remains active versus when it is removed), verification test results from our side post-rotation.
The reports are delivered through customer-preferred channels (email, Slack, ticket system depending on customer configuration). Customers can request additional formats (PDF for compliance documentation, signed reports for higher-assurance frameworks) as part of premium tier configuration.
Annual rotation history summary: at the end of each calendar year, customers receive a summary covering all rotation events during the year. The summary supports annual compliance reporting and operational reviews. The format is consistent across years to facilitate trend analysis and audit comparisons.
Telegram subscription takes 10 minutes. First rotation completes within 14 days of onboarding. Quarterly cadence runs on autopilot after that. Cancel anytime, no contract. Most customers don't think about DKIM rotation again until the compliance audit, when the documentation is ready.
# Median Telegram response: 12 minutes during operating hours