DKIM: From Theory to Production — An Operator's Guide

• March 2021
• Engineering Memo · External Release

DKIM — DomainKeys Identified Mail — is the most consequential email authentication standard for deliverability. More consequential than SPF (which is checked but can be passed by anyone who controls the sending IP) and more consequential than DMARC alone (which requires either DKIM or SPF alignment to pass). DKIM is the authentication mechanism that actually proves a message originated from who claims to have sent it — a property that neither SPF nor DMARC alone provides. Deliverability practitioners have strongly recommended DKIM for all senders for years; major ISPs including Gmail treat correctly configured DKIM alignment as a core trust signal in their reputation assessment.

This note documents DKIM implementation from the perspective of a production email operator — not as a cryptography tutorial, but as a guide to the specific configuration decisions, failure modes, and operational maintenance practices that determine whether DKIM works correctly at scale. It covers key generation and publication, signing configuration in PowerMTA, the rotation schedule that prevents key age from becoming a vulnerability, and the diagnostic steps for the DKIM failures most commonly encountered in production.

The Mechanics: What DKIM Signs and What That Proves

DKIM adds a cryptographic signature to outgoing messages. The signature is created by the sending mail server using a private key, and published in a DNS record as the corresponding public key. Receiving servers retrieve the public key from DNS and use it to verify the signature. If verification succeeds, the receiving server knows two things: the message was not modified in transit (the signature covers the message headers and body), and the message was signed by an entity that controls the private key associated with the published DNS record.

The practical implication of the "signed by an entity that controls the private key" statement: DKIM doesn't prove the From: address in the message is legitimate — it proves the message was signed by a specific key. The connection between the signing key and the From: address is established through DMARC alignment. DMARC requires that the domain in the DKIM signature (the d= tag in the DKIM-Signature header) aligns with the From: domain (either exactly or as a subdomain). When both DKIM and DMARC are correctly configured, together they do prove that the organization controlling the From: domain sent the message.

The DKIM-Signature header added to each signed message contains: the signing domain (d=), the selector (s=, which identifies which DNS record to query), the signing algorithm (a=, typically rsa-sha256), the list of signed headers (h=), the body hash (bh=), and the signature (b=). The selector is critical for operations because it allows multiple DKIM keys to exist for the same domain simultaneously — enabling key rotation without disrupting in-flight messages.

Key Generation: The Decisions That Matter

DKIM key generation requires two decisions: key algorithm and key size. The current production standard is RSA-2048 — 2048-bit RSA keys. ISPs use DKIM key quality as a trust signal in their reputation assessment, and 2048-bit keys provide the cryptographic strength that reflects well-managed sending infrastructure. 1024-bit keys, while technically valid, are considered cryptographically weak and receive lower trust scores in ISP authentication quality assessments. Ed25519 keys — a more modern elliptic curve algorithm — offer equivalent security at smaller key size but are not yet universally supported by all receiving infrastructure; using Ed25519 as the sole signing algorithm creates compatibility gaps.

The production approach: generate RSA-2048 keys as the primary DKIM configuration. If the infrastructure and receiving servers support it, add an Ed25519 selector as an alternative — but ensure the RSA-2048 selector remains as the fallback for receiving servers that do not support Ed25519 verification. This dual-selector configuration provides modern algorithm coverage without compatibility risk.

Key generation command on Linux:

# Generate 2048-bit RSA private key
openssl genrsa -out dkim_private.pem 2048

# Extract public key for DNS record publication
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Format for DNS TXT record (remove header/footer, join to single line)
openssl rsa -in dkim_private.pem -pubout -outform der 2>/dev/null | base64

# The resulting base64 string goes into the DNS TXT record:
# selector._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

PowerMTA DKIM Configuration

PowerMTA supports DKIM signing through its dkim-signature configuration directive. The signing configuration specifies which private key to use, which selector corresponds to the published DNS record, which domain the signature is for, and which message headers are included in the signature.

# In PowerMTA config (pmta.conf or include file)
<dkim-signature>
  key-file         /etc/pmta/dkim/yourdomain.com.pem
  domain           yourdomain.com
  selector         mail2025
  header-list      From:To:Subject:Date:Message-ID:MIME-Version:Content-Type
  algorithm        rsa-sha256
  canonicalization relaxed/relaxed
</dkim-signature>

# Apply to a virtual MTA
<virtual-mta vmta-main>
  smtp-source-host 203.0.113.10 mail.yourdomain.com
  dkim-signature   yourdomain.com
</virtual-mta>

The header-list configuration determines which headers are included in the DKIM signature and therefore cannot be modified without breaking the signature. At minimum, the From header must be signed. Including To, Subject, Date, and Message-ID provides additional protection against header manipulation but also means that any modification to these headers in transit — by mailing list software, forwarding services, or content filtering systems — breaks the DKIM signature. The trade-off: signing fewer headers is more durable through transit modifications; signing more headers provides stronger authentication assurance. The standard production configuration signs From, Subject, Date, and Message-ID as a balance between durability and assurance.

Key Rotation: The Schedule and the Process

DKIM private keys should be rotated periodically for security hygiene. The commonly recommended interval is annually, though organizations with stricter security requirements rotate quarterly. The rotation process requires careful sequencing to avoid DKIM failures during the transition.

The two-week wait between steps 4 and 5 is critical. Messages that have already been signed with the old selector may be in transit or temporarily queued — in bounce processing queues, at ISPs waiting to be delivered after a deferral, or in spam folder review queues. These messages reference the old selector for DKIM verification. Removing the old DNS record before these messages have been processed breaks their DKIM signatures, causing verification failures for previously-sent legitimate mail. Two weeks of overlap is conservative but safe; one week is typically sufficient for most production environments.

DKIM Failure Modes and Diagnosis

DKIM failures in production fall into four categories, each with a distinct diagnostic path. Understanding which category applies before attempting remediation prevents the wasted effort of applying the wrong fix.

Signature fails verification (key mismatch). The receiving server retrieves the public key from DNS and the signature does not verify against it. Most common cause: the private key file on the sending server and the public key in DNS do not correspond. This happens when a key rotation is done out of sequence — the DNS record is updated before the MTA configuration is updated, or vice versa. Diagnosis: compare the key fingerprint from the MTA configuration against the fingerprint derivable from the DNS TXT record. If they differ, the MTA and DNS are out of sync. Fix: ensure both are updated consistently and that DNS propagation is complete before MTA configuration changes.

Signature not present. The DKIM-Signature header is missing from outgoing messages. The message either was not signed at all, or was signed by a service that does not have DKIM configured. Diagnosis: check the accounting log for messages with no DKIM-Signature header using a header analysis tool or log parser. Check whether the MTA's DKIM signing configuration applies to all virtual MTAs or only to specific ones. Check whether any upstream relay or sending service is stripping DKIM signatures before delivery.

Signature present but body modified in transit. The signature verifies the key correctly but the body hash comparison fails, indicating the message body was modified after signing. Common cause: mailing list software that adds footers, content security systems that rewrite URLs, or forwarding services that modify message content. This failure is typically not fixable at the sending infrastructure level — it requires either excluding the modified content from the signature (body length limits in DKIM) or working with the transit system that is making modifications.

DMARC alignment failure despite DKIM pass. The DKIM signature is valid but the d= domain in the DKIM-Signature does not align with the From: domain. This occurs when a sending service signs with its own domain rather than the sender's domain, or when a subdomain mismatch prevents relaxed alignment from passing. Diagnosis: compare the d= value in the DKIM-Signature header against the From: domain. Relaxed alignment allows subdomain matching (newsletter.yourdomain.com aligns with yourdomain.com). Strict alignment requires exact match. Fix: ensure the DKIM signing is configured to use the organizational domain that matches the DMARC policy's domain, not the signing service's own domain.

DKIM for Multi-Tenant Infrastructure

Organizations operating email infrastructure for multiple sending domains — email service providers, agencies managing multiple client sending programmes, MailWizz deployments serving multiple customer accounts — face DKIM configuration complexity that single-domain operators do not. Each sending domain requires its own DKIM key pair and its own DNS record, and the MTA configuration must correctly associate each domain's key with the correct sending streams.

In PowerMTA, multi-domain DKIM is handled through multiple dkim-signature configuration blocks, one per domain, each referencing the appropriate private key file and selector. The virtual-mta configuration then references the correct dkim-signature block for each sending stream. A correctly structured multi-domain PowerMTA configuration maintains clear association between each domain's traffic, its signing key, and its selector without any ambiguity.

The key management challenge in multi-tenant infrastructure is maintaining separate key rotation schedules for each domain, with each domain's DNS records and MTA configuration synchronized independently. A key rotation error that affects one domain should not affect others. The practical approach: maintain a key management log — a simple spreadsheet or configuration management system entry — recording for each domain its current selector, the key generation date, the scheduled rotation date, the key file location, and the DNS record containing the public key. This log is the source of truth for all DKIM configuration changes and the audit trail for security compliance purposes.

In MailWizz's multi-tenant (SaaS) mode, each customer account can have its own sending domain with its own DKIM configuration. MailWizz generates DKIM key pairs through its delivery server configuration interface, but the DNS record publication requires access to the DNS zone for each customer's domain — which the customer must either manage themselves or delegate to the infrastructure provider. The onboarding process for new MailWizz customers in a managed environment includes: generating the DKIM key pair in MailWizz, providing the customer with the DNS TXT record to publish, verifying publication after the customer confirms the DNS update, and testing DKIM signing with a test message before activating the account for live sending. This sequence ensures every new customer account has validated DKIM from first send.

Monitoring DKIM Pass Rates in Production

DKIM pass rate should be monitored continuously in production — not just validated at deployment. DKIM configurations that are correct at deployment can become incorrect through configuration drift: a server migration that moves the private key file without updating the path in the MTA configuration, a DNS change that removes the DKIM selector record without updating the MTA to use a different selector, or a MailWizz delivery server reconfiguration that changes the signing parameters without corresponding MTA updates.

The monitoring sources for DKIM pass rates: DMARC aggregate reports provide per-source DKIM alignment pass rates across all mail receivers that process your traffic. A source that was passing DKIM alignment in last week's report but is not in this week's report indicates a configuration change that broke signing for that source. Gmail Postmaster Tools also provides DKIM authentication data at the domain level — the authentication failure rate visible in Postmaster Tools will increase if DKIM failures are occurring at scale, often before the DMARC aggregate report data surfaces the specific source.

For immediate verification in production: send a test message and inspect the Authentication-Results header in the received message. Gmail's Authentication-Results header reports dkim=pass (or dkim=fail) along with the selector that was used and the domain the signature covers. This header is the most direct diagnostic tool for verifying whether DKIM is functioning correctly for a specific sending configuration before a campaign sends at volume.

Automated DKIM health checks can be implemented as part of a broader email infrastructure monitoring system: a scheduled process that sends a test message through each configured virtual MTA, parses the Authentication-Results header from the delivered message, and alerts if any virtual MTA produces a dkim=fail result. This monitoring catches configuration drift before it affects production campaigns — particularly valuable in multi-tenant environments where multiple domains and multiple signing configurations exist simultaneously and changes to one should not affect others.

DKIM Key Strength Standards in 2021

By 2021, deliverability practitioners have converged on 2048-bit RSA as the standard DKIM key size. The 1024-bit keys common in earlier deployments are now considered cryptographically marginal — while still technically valid under the DKIM specification, 2048-bit keys are the correct choice for new deployments and the target for migrations from older key sizes. ISPs including Gmail use DKIM key strength as one signal in their authentication trust scoring; 2048-bit keys contribute stronger positive signals than 1024-bit keys in the multi-dimensional reputation model.

DKIM alignment — ensuring the d= domain in the DKIM signature matches the From: domain for DMARC alignment — has become more important as more programmes adopt DMARC at p=quarantine or p=reject. A DKIM signature that verifies correctly but fails DMARC alignment because it is signed with an ESP's domain rather than the sender's domain is functionally equivalent to no DKIM signing for DMARC purposes. The industry has broadly standardised on domain-aligned DKIM as the expected configuration for any sender deploying DMARC at enforcement levels.

Oversigning, described earlier in this note, is an additional security practice that has gained adoption as phishing campaigns have become more sophisticated. Including oversigning for the From: header is increasingly regarded as standard configuration rather than an advanced option, particularly for senders whose brand is a frequent phishing target. The configuration overhead is minimal; the protection against header injection attacks is meaningful for high-value brand domains.

Authentication configuration requires periodic review to ensure it remains current as infrastructure evolves. New sending sources added after the initial DKIM configuration may not be covered by the existing signing setup. DMARC aggregate reports, reviewed weekly, identify these gaps by showing which source IPs are sending from the domain and whether each source is passing DKIM alignment. This monitoring discipline — catching new authentication gaps as they appear rather than discovering them from deliverability problems months later — is the operational standard for DKIM configuration maintenance.

DKIM Key Rotation: The Safe Protocol

Key rotation is the most operationally sensitive DKIM maintenance task. The safe protocol: generate the new 2048-bit RSA key pair; publish the new public key at a new selector name with TTL=3600; configure the MTA to sign new messages with the new key and new selector while keeping the old selector DNS record published; wait 5–7 days for all in-transit messages signed with the old key to complete delivery; then remove the old selector DNS record.

The 5–7 day overlap is the safety margin. Messages signed with the old key that are sitting in ISP retry queues may be retried days after injection. If the old selector DNS record has been removed, DKIM verification fails for these in-transit messages. Keeping the old selector active for 5–7 days after the new signing configuration is in place ensures all deferred in-transit messages verify successfully before the old key is retired. The overlap period is not conservatism — it is the correct accommodation of realistic ISP retry behaviour.

The selector naming convention should be documented and consistent. A date-based convention (mail-2021, mail-2022) makes the rotation history visible in the DNS zone file and in DMARC aggregate reports, where the selector appears as part of the dkim= result. An opaque random name provides no operational context about when the key was created or how old it is, which complicates audit and rotation tracking over time.

Monitoring DKIM Pass Rate in Production

DKIM monitoring requires three data sources used together: DMARC aggregate reports (showing DKIM pass rate per source IP, weekly), Gmail Postmaster Tools authentication section (showing DKIM pass rate for Gmail-destined traffic), and periodic functional verification (test message with Authentication-Results header inspection). A decline in DKIM pass rate in DMARC aggregate reports is the earliest warning of configuration drift — typically appearing within the first week of a new unauthenticated source sending from the domain, before any reputation impact is detectable.

The most common production DKIM drift: a new sending source (CRM integration, added email service) sends from the domain without corresponding DKIM signing. Its sends fail DKIM, appearing in DMARC aggregate reports as a new source IP with low alignment pass rate. Weekly DMARC review catches this within the first send cycle. Without weekly review, the accumulation of DKIM failures over weeks or months affects domain reputation before the gap is discovered — at which point the remediation requires both correcting the configuration and recovering the reputation impact.

DKIM in production requires the same operational discipline as any other infrastructure component: initial correct configuration, quarterly verification, annual key rotation, and continuous monitoring. The authentication advantage DKIM provides — enabling ISPs to attribute reputation signals reliably to the signing domain — compounds over years of correct operation into a domain reputation asset that is not achievable without it. The investment in operating DKIM correctly is the prerequisite for all other reputation-based deliverability improvement; without it, the positive signals that clean sending generates are not fully attributed to the domain whose reputation they should be building.