Contents
- Why DR planning matters for email
- What must be backed up
- The backup strategy
- Configuration recovery versus full server recovery
- Recovery time and recovery point objectives
- Building the recovery runbook
- Testing the recovery
- The standby server approach
- The reputation dimension of recovery
- During an actual recovery
Why DR planning matters for email
A PowerMTA server, like any server, can be lost: a hardware failure, a destroyed cloud instance, a corrupted operating system, a catastrophic configuration mistake. When it happens, an operation without a disaster recovery plan is improvising under pressure while mail does not flow, and the improvisation is slow and error-prone. An operation with a DR plan executes a known procedure and is back to sending in a predictable time.
This guide exists because PowerMTA disaster recovery has specifics that a generic server-backup approach misses. Backing up the config file is not enough; a real PowerMTA recovery needs the license, the DKIM keys, the suppression data, and the surrounding DNS context, and missing any of them produces a recovery that does not actually work. There is also the reputation dimension, recovering onto new IPs is a deliverability problem, not just a technical one. The structure of this guide: why DR planning matters, what must be backed up beyond the config, the backup strategy, the distinction between configuration recovery and full server recovery, the recovery time and recovery point objectives, building and testing a recovery runbook, the standby server approach and its licensing cost, the reputation dimension of recovery, and the diagnostic workflow during an actual recovery.
What must be backed up
A PowerMTA DR backup must capture more than the config file. The essentials:
| Item | Why it is essential |
|---|---|
| The configuration files | Define how PowerMTA delivers |
| The License Activation Key | PowerMTA will not run without a valid license |
| The DKIM private keys | Without them the recovery cannot produce verifying signatures |
| The suppression and bounce data | Losing it resumes mailing suppressed addresses |
| The DNS and IP context | Needed to reconstruct the environment accurately |
The configuration files. The main config at /etc/pmta/config and any included files. This is the obvious part, but it is only the start.
The License Activation Key. PowerMTA will not run without a valid license. If a recovery has to obtain a replacement LAK from the vendor, that adds recovery time. Backing up the LAK means the recovery can place it immediately.
The DKIM private keys. This is the most commonly overlooked essential. PowerMTA signs with private keys whose public counterparts are published in DNS. If a recovery loses the private keys, the recovered PowerMTA cannot produce DKIM signatures that verify against the published public keys. The recovery would have to generate new keys and republish the public keys in DNS, which adds time and DNS propagation delay. Backing up the DKIM private keys lets the recovery sign correctly from the start.
The suppression and bounce-handling data. The lists of addresses that should not be mailed. A recovery that loses the suppression data resumes sending to addresses that had been suppressed, mailing people who bounced or unsubscribed, which harms reputation.
The DNS and IP context. A record of the IP addresses, the reverse DNS, and the DNS records for SPF, DKIM, and DMARC, so the recovered environment can be reconstructed accurately.
The backup strategy
Having identified what to back up, the strategy covers how and where.
Where the backup lives. The backup must be stored somewhere separate from the PowerMTA server itself. A backup on the same server is worthless for a full server loss, the disaster takes the backup with it. The backup belongs in separate storage: another server, an object store, a backup service, somewhere the loss of the PowerMTA server does not also lose the backup.
How often. The backup frequency should match how often the backed-up items change. The configuration changes when the operator edits it, so a backup after every configuration change captures the config promptly. The suppression data changes continuously as mail bounces and recipients unsubscribe, so it needs regular, frequent backup. The license and the DKIM keys change rarely, so they need backing up when they change, after a key rotation, after a license renewal, and otherwise a periodic capture confirms they are still held.
Automation. The backup should be automated, not a manual task someone remembers to do. An automated backup runs reliably; a manual one is forgotten exactly when it matters. A scheduled job that captures the configuration, the suppression data, and the supporting material to the separate storage is the dependable approach.
Verification. A backup that has never been verified is a hope, not a plan. The backup process should be checked, that it is running, that the backups it produces are complete and not corrupt, and the testing described below confirms the backups can actually be restored.
Configuration recovery versus full server recovery
PowerMTA disaster recovery has two distinct scenarios, with different scopes and procedures.
| Scenario | What was lost | Recovery scope |
|---|---|---|
| Configuration recovery | The config, server intact | Restore config, reload |
| Full server recovery | The whole server | Rebuild server, reinstall, restore everything |
Configuration recovery is when the server is intact but the configuration has been lost or corrupted, a bad edit, an accidental deletion, a failed change. The recovery is to restore the configuration file and reload or restart PowerMTA. This is relatively fast: the server, the OS, the PowerMTA installation, and the IPs are all still in place, only the configuration needs restoring.
Full server recovery is when the server is lost entirely, hardware failure, destroyed instance, corrupted OS. The recovery requires rebuilding the whole server: provisioning a new server, installing the OS, installing PowerMTA, placing the license, restoring the configuration, restoring the DKIM keys and suppression data, and dealing with the IP addresses. This is a larger undertaking and takes longer.
The two scenarios need different runbooks and have different recovery-time expectations. A complete DR plan addresses both, the fast configuration-only recovery and the slower full-server rebuild, because both can happen and the operator wants a prepared procedure for each.
Recovery time and recovery point objectives
Two concepts frame DR planning: the recovery time objective and the recovery point objective.
The recovery time objective (RTO) is how long the operation can tolerate PowerMTA being down, the target time within which the recovery must restore service. A business-critical email operation might have an RTO of an hour or two; an operation where some delay is tolerable might accept a longer RTO.
The recovery point objective (RPO) is how much data the operation can tolerate losing, expressed as a time window, the maximum age of the backup the recovery restores from. If the suppression data is backed up every hour, the RPO for suppression data is an hour, the recovery could lose up to an hour of suppression changes.
The RTO drives the recovery approach: a tight RTO that a full rebuild cannot meet pushes toward a standby server. The RPO drives the backup frequency: a tight RPO for the suppression data requires frequent suppression backups.
Setting the RTO and RPO explicitly is the part of DR planning that turns vague intentions into concrete requirements. Once the operator has decided email can be down for at most two hours (RTO) and the suppression data can lose at most one hour of changes (RPO), the DR plan has measurable targets: the recovery procedure must complete within two hours, and the suppression backup must run at least hourly.
Building the recovery runbook
The recovery runbook is the documented, step-by-step procedure for executing a recovery. It exists so that a recovery is the execution of a prepared plan rather than an improvisation.
A runbook should be written for each scenario. The full server recovery runbook, the more involved one, covers:
- Provision the new server. A server on a supported OS, RHEL, AlmaLinux, or Rocky Linux in a current line, with OpenSSL 3.x for PowerMTA 6.0, 64-bit x86, adequate disk.
- Remove any conflicting MTA. Stop and disable Postfix or Sendmail so it does not hold port 25.
- Install PowerMTA. Install the PowerMTA package for the correct version.
- Place the license. Restore the License Activation Key from backup into the configuration directory.
- Restore the configuration. Restore the config files from backup.
- Restore the DKIM keys. Restore the DKIM private keys to the path the configuration expects.
- Restore the suppression data. Restore the suppression and bounce-handling data.
- Address the IP addresses. Assign the sending IPs, set up reverse DNS, and if the IPs are new, plan for the reputation implications.
- Request the cloud port 25 unblock if on a cloud provider.
- Validate the configuration with the PowerMTA config check.
- Start PowerMTA and verify with pmta show status, a test delivery, and accounting confirmation.
- Update DNS if needed so SPF, DKIM, and the sending hostnames point at the recovered environment.
The configuration recovery runbook is shorter: restore the config, validate it, reload or restart, verify. Each runbook should be detailed enough that someone other than its author can execute it, because the person available during a disaster may not be the person who wrote the plan.
Testing the recovery
A DR plan that has never been tested is a document, not a capability. The recovery must be tested.
Testing the recovery means actually executing the runbook, in a test context, and confirming it produces a working PowerMTA. The test reveals the gaps: a backup that turns out to be incomplete, a runbook step that is unclear or wrong, a piece of data that was not being backed up, a recovery that takes longer than the RTO allows.
The failure mode that DR testing exists to catch is the backup that looks fine but does not actually enable a recovery: the DKIM keys that were not in the backup set, the suppression data that was being captured incompletely, the license file that was missing, the runbook step that references something that no longer exists. None of these is visible by looking at the backup; they only surface when someone tries to recover from it. Testing the recovery, actually executing the runbook against the backups, is the only way to know the DR plan works. A backup nobody has ever restored from is an assumption, and a disaster is the worst time to discover the assumption was wrong.
The recovery test should be run periodically, not just once, because the environment changes: new DKIM keys from a rotation, configuration changes, new streams. A recovery test from a year ago does not confirm the current backup recovers the current environment. A periodic test, and a test after any significant change to the PowerMTA setup, keeps the DR capability real.
The test also produces a measured recovery time, which validates the RTO. If the tested recovery takes four hours and the RTO is two, the plan does not meet its objective and the approach needs to change, a faster procedure, more preparation, or a standby server.
The standby server approach
For operations where a full rebuild cannot meet the RTO, the standby server approach keeps a second PowerMTA installation ready to take over.
A standby server is a second PowerMTA installation, maintained in a ready state, that the operator can fail over to if the primary is lost. Instead of provisioning and building a new server during an outage, the failover switches to the already-running standby, turning an hours-long rebuild into a much shorter failover.
The standby's benefit is recovery speed, valuable for an operation where email downtime directly costs money or breaks customer-facing functionality. The standby's cost has two parts:
- Infrastructure cost. Running a second server.
- Licensing cost. PowerMTA licensing charges per installation, so the standby needs its own license. The standby is an additional PowerMTA license cost, not just a server cost.
The per-installation licensing is a real factor specific to PowerMTA. For software without per-installation licensing, a standby is just an infrastructure cost; for PowerMTA, the standby also carries a license cost, which makes the standby approach more expensive and feeds into the broader cost considerations operators weigh when comparing PowerMTA to alternatives.
The decision is a weighing: the recovery-time benefit of the standby against the combined infrastructure and licensing cost, in light of how critical email uptime is. An operation that can tolerate a few hours of recovery may reasonably choose backup-and-rebuild; an operation where email must stay up may find the standby justified. The DR plan should state which approach is chosen and what recovery time it implies, so the choice is explicit and the expectations are set.
The reputation dimension of recovery
A PowerMTA recovery is not purely a technical exercise, because of the IP reputation dimension.
Sending IP reputation is built over time and is tied to specific IP addresses. A full server recovery raises the question of what IPs the recovered installation sends from.
If the recovery uses the same IPs as the lost server, the IP reputation is preserved, and the recovery is, on the reputation side, clean. This is the better outcome, and it is a reason to architect for IP portability where possible, so a recovery can reclaim the original IPs.
If the recovery must use new IPs, the recovered installation faces the reputation problem of sending from IPs with no established reputation. New IPs are unwarmed, and sending full production volume from unwarmed IPs triggers throttling and filtering, exactly the IP warming problem, but arriving unexpectedly during a recovery. A recovery onto new IPs is therefore a technical recovery plus a warming exercise: the recovered installation should ramp volume on the new IPs rather than resuming full volume immediately.
This reputation dimension should be part of the DR plan. The plan should consider whether the original IPs can be reclaimed in a recovery, and if not, the recovery runbook should include the warming approach for the new IPs. A DR plan that restores PowerMTA technically but ignores the IP reputation produces a recovered installation that runs but delivers poorly because it is sending established volume from unwarmed IPs.
During an actual recovery
When an actual recovery is underway, the workflow follows the runbook, with attention to the points where recoveries commonly stumble:
Step 1: identify the scenario. Configuration recovery (server intact) or full server recovery (server lost)? This selects the runbook.
Step 2: execute the runbook steps in order. Follow the prepared runbook. The discipline of following the documented steps, rather than improvising, is what keeps the recovery on track.
Step 3: confirm the license is in place and validates. A common recovery stumble is the license: confirm the restored LAK is the right generation and PowerMTA accepts it, and that the recovered server has the network connectivity license validation needs.
Step 4: confirm the DKIM keys are restored correctly. Confirm the DKIM private keys are in the path the configuration expects. A recovery that runs but signs with missing or wrong keys produces DKIM failures, so verify a test message's DKIM signature verifies.
Step 5: confirm the suppression data is restored. Verify the suppression data is in place before resuming sending, so the recovered installation does not mail suppressed addresses.
Step 6: verify with a test delivery. Before resuming production sending, send a test message and confirm it delivers, with valid authentication. This exercises the whole recovered path.
Step 7: address the IPs and reputation. Confirm the IP situation. If new IPs, begin the warming approach rather than resuming full volume.
Step 8: resume sending and monitor closely. Resume production sending, and monitor the recovered installation closely, the delivery rates, the authentication results, the queues, against the known baseline, because a recovery can have subtle issues that only surface under production load.
An operator we worked with experienced a full server loss when their PowerMTA host suffered an unrecoverable failure. They had a DR plan and backups, so they executed the recovery: provisioned a new server, installed PowerMTA, restored the license, restored the configuration, and brought PowerMTA up. The recovery seemed successful, PowerMTA started, the configuration loaded, test messages delivered. They resumed production sending and considered the recovery complete. Over the following day, their DMARC reports and their deliverability began to degrade, and mail was increasingly landing in spam. The investigation found the problem: the recovered PowerMTA was producing DKIM signatures that failed verification. Their backup process had captured the configuration file diligently, but it had been set up to back up /etc/pmta/config and not the directory holding the DKIM private keys. So the recovery had restored the configuration, which referenced the DKIM key files, but the key files themselves had not been in the backup and were lost with the old server. The recovered PowerMTA, when it tried to DKIM-sign, was either failing to sign or signing with keys that did not correspond to the public keys still published in DNS. Every signed message failed DKIM verification at the receivers, which dragged down DMARC and deliverability. The recovery had restored everything except the one thing that, missing, quietly broke authentication. The fix required generating new DKIM key pairs, updating the PowerMTA configuration to use them, and publishing the new public keys in DNS, then waiting for DNS propagation, all of which could have been avoided if the keys had been in the backup. The operator's deeper fix was to correct the backup set to include the DKIM private keys, and to institute periodic recovery testing, because a recovery test would have caught the missing keys long before a real disaster did. The lesson is the central point about what must be backed up: the config file alone is not a sufficient PowerMTA backup. The DKIM private keys are essential, and a backup that omits them produces a recovery that runs but cannot authenticate. And the meta-lesson is that testing the recovery, actually restoring from the backup, is the only reliable way to discover that the backup is incomplete before a disaster forces the discovery.
PowerMTA disaster recovery is the discipline of being able to restore a mail infrastructure predictably after a loss. It rests on a backup that captures everything a real recovery needs, not just the config file but the License Activation Key, the DKIM private keys, the suppression data, and the DNS and IP context, stored separately from the PowerMTA server. The plan distinguishes the fast configuration recovery from the slower full server rebuild, sets explicit RTO and RPO targets, and documents a runbook for each scenario that someone other than its author can follow. The standby server approach trades cost, including PowerMTA's per-installation license cost, for faster recovery, a weighing each operation makes against its email-uptime needs. The reputation dimension means a recovery onto new IPs is also a warming exercise. And testing the recovery, actually executing the runbook against the backups, is the non-negotiable step that turns a DR plan from a hopeful document into a real capability. Operators who back up the full set, document and test their runbooks, and plan for the IP reputation, recover predictably; operators who back up only the config file discover during a disaster that their recovery restores a PowerMTA that runs but cannot do its job.