Designing a DKIM Key Management System for Multi-Tenant Infrastructure

• January 2022
• Engineering Memo · External Release

Managing DKIM keys for a single sending domain is a solved problem — generate a key pair, publish the public key in DNS, configure the MTA to sign with the private key, rotate annually. Managing DKIM keys for a multi-tenant infrastructure — where each client has their own sending domain, their own key pair, their own DNS configuration, and their own rotation schedule — requires an architecture that scales to dozens or hundreds of tenants without becoming operationally unmanageable.

This note documents the DKIM key management system required for managed email infrastructure providers, MailWizz multi-tenant (SaaS) deployments, and agencies managing email for multiple client domains. It covers key generation at scale, secure key storage, rotation scheduling, DNS publication automation, and the monitoring that detects when any tenant's key becomes invalid before it affects delivery.

Why Multi-Tenant DKIM Differs From Single-Domain Management

Single-domain DKIM management can be done manually — a one-time key generation, a DNS record update, and an annual reminder to rotate. At 20, 50, or 200 tenant domains, the same process becomes unmanageable without automation: rotation reminders multiply across tenants, DNS verification becomes a regular administrative task, and any operator error in key management for one tenant (publishing the wrong public key, rotating without updating the MTA configuration) creates a delivery problem for that tenant while the other tenants continue operating normally.

The operational risk profile also changes. In single-domain management, a key management error affects one organisation's email. In multi-tenant management, a key management error could affect hundreds of organisations' email if the error is systemic — for example, a software bug in the key rotation process that generates invalid key formats for all tenants who rotate in a given week. Systemic risk requires defensive design: key validation before deployment, rotation confirmations, and monitoring that verifies each tenant's key independently rather than assuming all keys are valid because the rotation process ran.

Key Generation and Storage Architecture

Each tenant requires a unique RSA-2048 private key — the same key cannot be shared across tenants because sharing a private key means that if one tenant's key is exposed, all tenants using that key are compromised. Key uniqueness is a security requirement, not just an organisational preference.

Private key storage must be encrypted at rest. The threat model for key storage in a multi-tenant environment: a database breach or storage access incident must not expose private keys in plaintext. Encrypt keys using a key encryption key (KEK) stored separately from the key database — if the key database is breached, the encrypted keys are useless without the KEK. The KEK itself should be stored in a hardware security module (HSM) or a cloud KMS service (AWS KMS, Azure Key Vault, Google Cloud KMS) that provides hardware-backed key protection and audit logging for all key operations.

The key metadata that must be stored alongside each private key: the tenant identifier, the domain the key signs for, the selector name (used in DNS records and MTA configuration), the key generation date, the scheduled rotation date, the current active status, and the hash of the corresponding public key (for verification). This metadata is the input to the rotation scheduler and the monitoring system, and it must be accurate to prevent rotation errors that break signing for specific tenants.

The Rotation Lifecycle for Multi-Tenant Environments

Annual key rotation is the standard practice for DKIM keys. In a multi-tenant environment with 100 clients, rotating all keys at the same time creates both operational risk (a systematic error affects all tenants simultaneously) and a significant DNS coordination burden (100 clients must all update their DNS within the same window). Staggering rotations throughout the year — rotating approximately 8–9 tenants per month — distributes the operational load and reduces systemic risk.

The rotation lifecycle for each tenant in a staggered schedule:

30 days before rotation: generate the new key pair for this tenant. Store the private key in the encrypted key store. Prepare the DNS TXT record with the new public key for the new selector name (e.g., rotating from mail2024 to mail2025). Notify the tenant that they must publish a new DNS record with the content provided, by a specific date 14 days before the rotation. This 14-day lead time allows for DNS propagation and verification before the new selector is activated.

14 days before rotation: verify that the tenant has published the new DNS record. This verification is automated: query the new selector from multiple external DNS resolvers and confirm the record exists and contains the expected public key. If the record is not yet published, send a second notification to the tenant and escalate if necessary. Do not proceed with rotation until the new DNS record is confirmed — rotating the MTA to use the new key before the DNS record is published causes immediate DKIM failures for this tenant.

Rotation day: update the PowerMTA DKIM signing configuration to use the new private key file and new selector name for this tenant. Reload the PowerMTA configuration to apply the change without process restart. Verify the new signing configuration by injecting a test message from this tenant's sending domain and confirming dkim=pass with the new selector in the Authentication-Results header. If verification fails, roll back to the old key configuration immediately.

14 days after rotation: remove the old selector's DNS record from the tenant's domain. The 14-day overlap ensures that any messages signed with the old key that are still in transit queues at receiving ISPs (including backlogged messages waiting for retry resolution) can still be verified. Remove the old private key from the key store after the overlap period.

Automated DNS Publication: When Tenants Control Their Own DNS

In many managed infrastructure scenarios, the tenant controls their own DNS — the infrastructure provider manages the sending infrastructure but the tenant manages their domain's DNS records. This means DKIM DNS record updates cannot be automated from the infrastructure side: the tenant must make the change in their DNS management interface after receiving the public key from the infrastructure provider.

The notification workflow for tenant-controlled DNS: the key management system generates the new public key for the tenant's upcoming rotation, formats it as a DNS TXT record value, and sends the tenant an email with specific, copy-pasteable instructions: "Please add the following DNS TXT record to your domain's DNS configuration before [date]." The notification includes the exact record type, the exact hostname (selector._domainkey.domain.com), and the exact record value — no ambiguity that requires interpretation by the tenant.

The verification step that confirms the tenant has completed the DNS update — automated queries from multiple external resolvers — must be non-negotiable before proceeding with MTA-side rotation. The common failure scenario in tenant-controlled DNS rotation: the tenant publishes the record at the wrong subdomain (e.g., selector._domainkey.com instead of selector._domainkey.domain.com) or with incorrect formatting that passes casual review but fails technical validation. Automated verification catches these errors before they affect delivery, rather than discovering them after rotation causes DKIM failures.

PowerMTA Configuration for Multi-Tenant DKIM

PowerMTA supports multiple dkim-signature configuration blocks, allowing each tenant to have a dedicated signing configuration with their own key file, selector, and domain. The virtual-mta configuration for each tenant references the corresponding dkim-signature block, ensuring that messages from tenant A are signed with tenant A's key and messages from tenant B are signed with tenant B's key.

# Tenant A DKIM configuration
<dkim-signature tenant-a>
  key-file          /etc/pmta/dkim/tenant-a/mail2025.pem
  domain            tenant-a.com
  selector          mail2025
  algorithm         rsa-sha256
  canonicalization  relaxed/relaxed
  header-list       *From:To:Subject:Date:Message-ID:MIME-Version
</dkim-signature>

# Tenant A virtual MTA (references tenant-a dkim-signature)
<virtual-mta vmta-tenant-a>
  smtp-source-host  203.0.113.10 mail.tenant-a.com
  dkim-signature    tenant-a
</virtual-mta>

# Tenant B has separate key, selector, and virtual MTA
<dkim-signature tenant-b>
  key-file          /etc/pmta/dkim/tenant-b/mail2025.pem
  domain            tenant-b.com
  selector          mail2025
  algorithm         rsa-sha256
  canonicalization  relaxed/relaxed
  header-list       *From:To:Subject:Date:Message-ID:MIME-Version
</dkim-signature>

Key file organisation on the server: store each tenant's private keys in a dedicated directory (/etc/pmta/dkim/[tenant-id]/). The directory permissions should allow read access only to the PowerMTA process user and the key management system process — not to general administrative users. During rotation, the new key file is placed in the tenant's directory with a temporary name, validated, then renamed to the production filename that the PowerMTA configuration references. After PowerMTA is reloaded to pick up the new key reference, the old key file is archived (not deleted immediately) until after the 14-day overlap period confirms no delivery issues.

Monitoring: Daily Key Validity Verification

The monitoring system for multi-tenant DKIM key management must verify three things for each tenant daily: the DNS record for the active selector resolves correctly and contains the expected public key; the PowerMTA signing configuration references the correct private key file for this tenant; and test messages injected from this tenant's virtual MTA produce dkim=pass with the correct selector in Authentication-Results.

The daily verification process: for each tenant, query their active selector's DNS TXT record and compare the public key value against the stored expected value in the key management database. Any mismatch — key value changed, record missing, selector incorrect — generates an immediate alert. Separately, inject a test message from each tenant's virtual MTA to a monitoring inbox (one per tenant) and verify the Authentication-Results header shows dkim=pass with the expected selector. Any dkim=fail triggers an immediate alert for that tenant.

This daily end-to-end verification catches the failure modes that configuration-only checks miss: a valid DNS record and a valid key file that are not matched to each other (the DNS record contains an old public key that does not correspond to the current private key file, perhaps from a manual configuration error during rotation). The test message injection is the only check that verifies the complete signing chain — private key in MTA, public key in DNS, message signed correctly — rather than just individual components in isolation.

Handling Tenant Offboarding: Key Deprecation Protocol

When a tenant's service ends, their DKIM configuration must be correctly deprecated rather than simply abandoned. Leaving an active private key in the MTA configuration after a tenant has offboarded creates a security exposure: the private key can still sign messages, potentially allowing the creation of signed messages purporting to be from the tenant's domain even after their relationship with the infrastructure has ended.

The offboarding protocol: (1) disable the tenant's virtual MTA to prevent new injection; (2) wait for the tenant's message queue to drain completely (monitor queue depth to zero); (3) remove the tenant's dkim-signature configuration block from PowerMTA and reload; (4) archive the private key file to offline secure storage (in case it is needed for dispute resolution or compliance purposes); (5) remove the private key from the online key store; (6) notify the tenant that they can remove the DNS record for the DKIM selector from their domain's DNS configuration. The DNS record removal is the tenant's responsibility — the infrastructure provider cannot remove it without access to the tenant's DNS.

Leaving the tenant's DNS selector record in place after offboarding is not a security risk — the DNS record contains only the public key, and without the corresponding private key (which is archived offline), the record cannot be used to create valid signatures. But informing the tenant to remove it is good practice for DNS hygiene: a selector record for a no-longer-active sending configuration is unnecessary DNS noise that could cause confusion if the domain is transferred to a new owner.

Multi-Tenant DKIM in MailWizz SaaS Deployments

MailWizz's multi-tenant (SaaS) mode allows multiple customer accounts to use the same MailWizz installation, each with their own campaigns, lists, and delivery configurations. DKIM configuration in this context requires that each customer account be associated with a specific DKIM signing key for their sending domain, and that the key management system described above integrate with MailWizz's delivery server and domain signing configuration.

MailWizz supports DKIM signing at the delivery server level — each delivery server can be configured with DKIM signing parameters. In a multi-tenant deployment, each customer account is associated with a dedicated delivery server (or a delivery server pool) that has the customer's DKIM key configured. This is functionally equivalent to the PowerMTA dkim-signature configuration approach, but implemented through MailWizz's delivery server interface rather than PowerMTA's configuration files directly.

The key management system must integrate with MailWizz's delivery server configuration through either direct database writes to MailWizz's delivery server tables or through the MailWizz API. The specific integration approach depends on the MailWizz version and deployment configuration — but the conceptual requirement is the same: when a new key is generated for a tenant, the corresponding delivery server in MailWizz must be updated to reference the new key, and MailWizz must be restarted or the delivery server cache refreshed to pick up the new key reference before the next campaign sends.

Compliance and Audit Trail Requirements

Multi-tenant DKIM key management has compliance dimensions that single-tenant management does not. Under GDPR and similar data protection frameworks, the key management system processes tenant-identifying information (the domain name) alongside cryptographic material (private keys). The data processing register should document this processing activity, its legal basis (legitimate interest or contractual necessity), retention periods, and access controls.

The audit trail requirement: every key management operation — key generation, key storage, DNS verification queries, rotation events, key archival, key deletion — should be logged with timestamp, operator identity, and outcome. This audit trail enables reconstruction of the complete key lifecycle for any tenant key, which is relevant both for security incident investigation (if a key is suspected to have been compromised) and for compliance audits that may require demonstration of key management controls.

The audit log must be tamper-evident — append-only storage with cryptographic chaining, or logging to an external audit log service that the key management system cannot modify. A tamper-evident audit trail provides assurance that the log accurately reflects what occurred, rather than what an operator with access chose to record. This is particularly important if the key management system is operated by a team different from the one being audited.

DKIM key management at scale — across dozens or hundreds of tenants — is operationally complex but technically straightforward. The complexity is in the coordination: maintaining the rotation schedules, verifying DNS publication, confirming signing validity after each rotation, and providing clear instructions to tenants who control their own DNS. Systems that automate this coordination — reducing the human touchpoints to only the DNS publication step for tenant-controlled DNS — achieve the operational scale required for a professionally managed multi-tenant email infrastructure provider. The key management investment, made once and maintained through the automated monitoring and staggered rotation process, delivers the authentication reliability that every tenant's deliverability depends on.

Security Considerations: Key Isolation Between Tenants

Beyond storage encryption, multi-tenant DKIM key management requires logical isolation between tenant key material. One tenant's private key must not be accessible to any process or operator associated with another tenant. In practice, this means: separate directory structures with per-tenant access controls on the file system; database row-level security that limits queries to the tenant's own key records; API authentication that associates each API request with a specific tenant and enforces tenant-scoped data access; and audit logging that distinguishes which tenant context each key operation occurred in.

The shared PowerMTA process creates a specific isolation consideration: the PowerMTA process runs as a single system user and has read access to all tenant key files it is configured to sign with. A compromise of the PowerMTA process (through a vulnerability in the software or a configuration exploit) would expose all tenant private keys accessible to that process. Mitigation: compartmentalise key access by running separate PowerMTA instances per tenant group, or use PowerMTA's signing module architecture to separate signing processes from the main delivery process with separate privilege levels. The appropriate compartmentalisation level depends on the tenant count, the sensitivity of the tenants' sending domains, and the organisation's security risk tolerance.

Ed25519 keys — a modern elliptic curve signing algorithm — provide equivalent cryptographic strength to RSA-2048 at significantly smaller key size (32 bytes vs 256 bytes), which simplifies key storage, reduces DNS record size, and speeds signing operations in high-volume environments. The limitation is receiving server compatibility: as of 2026, most major ISPs support Ed25519 DKIM verification, but some legacy corporate mail servers and smaller ISPs may not. The multi-tenant key management approach for providers who want to use Ed25519: publish both RSA-2048 and Ed25519 selectors for each tenant, configure PowerMTA to sign with Ed25519 as the primary algorithm, and use RSA-2048 as the fallback for servers that return Ed25519 verification failure. This dual-algorithm approach provides modern algorithm coverage without compatibility risk, though it doubles the key management burden (two key pairs, two DNS records, two rotation schedules per tenant).

The final operational principle for multi-tenant DKIM key management: treat key management as infrastructure, not as an administrative task. Key expiration, rotation, DNS synchronisation, and validation failures are infrastructure events that affect delivery — they should be monitored, alerted, and responded to with the same urgency and process discipline as MTA service alerts, DNSBL listings, or authentication failures. A key management system that operates without monitoring is a system that fails silently, and silent failures in DKIM key management produce the delivery and reputation consequences that follow from authentication failures at scale.

Multi-tenant DKIM key management at 50 or 100 tenants is significantly more demanding than at 5 or 10. The scaling inflection point — where manual key management becomes operationally unsustainable and a managed key system becomes necessary — is typically around 15–20 tenants. Providers who build the key management system before reaching this inflection point, rather than after, benefit from the system during the growth phase when operational load is increasing but before it becomes a crisis. The investment in building the system is constant regardless of when it is made; the cost of not building it compounds with each additional tenant that requires manual key management across the rotation lifecycle.