Email infrastructure failures — MTA server crashes, data centre outages, ESP platform incidents, IP blacklisting events, or DNS failures — can cause complete sending interruption at the worst possible times. For programmes where email is a primary revenue channel (e-commerce transactional email, newsletter advertising revenue, SaaS product activation and retention email), even 2-4 hours of sending interruption translates to direct commercial impact. Email infrastructure disaster recovery (DR) planning defines what happens when the primary sending infrastructure fails — who switches what, how quickly, and what protective measures are in place to prevent an outage from becoming a reputation event as well as a delivery interruption.
Email Infrastructure Failure Scenarios
Email infrastructure disaster recovery planning must address the specific failure scenarios relevant to the programme's infrastructure stack. The most common commercial email infrastructure failure modes:
MTA server failure: Hardware failure, OS crash, or disk failure on the primary MTA server. Messages in the outbound queue at time of failure may be lost if the queue is on the failed storage. All in-flight SMTP connections are terminated. No email delivery until the server is recovered or traffic is redirected to backup infrastructure.
Data centre / cloud provider outage: The entire cloud region or data centre hosting the MTA becomes unavailable. The MTA may be running but unreachable from the internet, or may be terminated by the provider's own DR procedures. Data centre outages typically last 1-12 hours for major providers and up to 72+ hours for regional or smaller facilities.
ESP platform incident: The managed ESP (Postmark, Mailgun, SendGrid) experiences a platform-wide outage affecting all customers. ESP outages are typically partial (affecting specific regions or sending pools) rather than total, but complete API unavailability does occur. Major ESP incidents have lasted 30 minutes to 8 hours historically.
IP blacklisting event: All or most sending IPs are listed on a major blacklist (Spamhaus SBL, Barracuda BRBL). Messages from the blacklisted IPs are rejected at destination servers. Delivery effectively stops for all recipients whose ISP uses the affected blacklist. Spamhaus SBL listings for commercial email programmes are typically resolved within 24-72 hours but can take longer for complex cases.
DNS failure: PTR records, SPF records, DKIM keys, or MX records become unavailable due to DNS provider failure, domain registrar issue, or misconfiguration. Authentication failures resulting from DNS unavailability cause delivery failures or spam folder placement at ISPs. DNS failures can be brief (minutes) or extended (hours to days if caused by a domain registrar problem).
RTO and RPO for Email Infrastructure
Disaster recovery planning begins with defining Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for the email infrastructure:
RTO (Recovery Time Objective): The maximum acceptable time from disaster onset to resumed sending capability. For transactional email (password resets, order confirmations, account alerts), an RTO of 15-30 minutes is typical — longer outages create customer support spikes and user frustration. For marketing email (campaigns, newsletters), an RTO of 2-4 hours is often acceptable — the commercial impact is significant but not the immediate customer-facing urgency of transactional email.
RPO (Recovery Point Objective): The maximum acceptable amount of message data loss, expressed in time. An RPO of zero means no messages can be lost — all queued messages must be deliverable after recovery. An RPO of 30 minutes means messages queued in the 30 minutes before disaster onset may be lost — the application must re-trigger those messages from the source system. RPO drives whether the DR architecture requires queue synchronisation (zero-loss) or only failover delivery capability (with potential message regeneration from source).
The RTO and RPO requirements determine the complexity and cost of the DR architecture. A zero-RPO, 15-minute RTO architecture requires warm standby infrastructure (a second fully operational MTA with synchronised queues and IP warmup complete) that can accept traffic instantly. A 2-hour RTO with 30-minute RPO requires a pre-warmed backup infrastructure that can be activated within 2 hours and a message regeneration process to re-queue messages that were in-flight at the time of the disaster.
Backup MTA Architecture
A backup MTA for disaster recovery must be pre-warmed before any disaster occurs — activating cold (unwarmed) backup IPs during a disaster creates the additional problem of sending high volumes from IPs with no reputation history at the worst possible time. The backup MTA architecture must maintain the backup IPs in an active but low-volume state that keeps them warmed and ready for full-volume activation.
The backup MTA configuration for a PowerMTA-based primary stack:
# Primary stack: 4 dedicated IPs, 100K+ messages/day # Backup stack: 2 dedicated IPs on separate server/region # Backup IPs maintained at ~5% of primary volume (warmup maintenance sends) # Primary MTA configuration (main.cf): # primary-ip1: 203.0.113.10 # primary-ip2: 203.0.113.11 # primary-ip3: 203.0.113.12 # primary-ip4: 203.0.113.13 # Backup MTA (separate server, separate data centre): # backup-ip1: 198.51.100.20 # backup-ip2: 198.51.100.21 # Warmup maintenance: 5,000 messages/day per backup IP (ongoing) # Full capacity: 50,000+ messages/day per backup IP (after failover) # Failover trigger: # Monitoring alerts primary MTA unavailable # Application switches SMTP endpoint from primary to backup # Backup MTA ramps to full volume over 60-120 minutes
The backup MTA should be in a different data centre region from the primary — a disaster that takes down one data centre should not affect the backup simultaneously. AWS us-east-1 primary + AWS us-west-2 backup provides geographic separation within the same cloud provider. Primary in one cloud provider (AWS) + backup in a different cloud provider (Hetzner, OVH) provides both geographic and provider separation for higher resilience.
Backup IP warming maintenance: maintain backup IPs by routing 3-5% of normal sending volume through the backup stack continuously — not just during disaster drills. This keeps the backup IPs at High Gmail reputation and Green SNDS status so they are ready to accept full volume immediately upon failover activation. A backup IP that last received sending volume 3 months ago has degraded reputation that will produce poor inbox placement when activated during a disaster.
ESP Failover Configuration
For programmes using managed ESPs (Postmark, Mailgun, SendGrid) rather than self-hosted MTAs, the disaster recovery architecture focuses on ESP-level failover: maintaining accounts with at least two ESPs and configuring the application to switch to the secondary ESP when the primary is unavailable.
The dual-ESP failover architecture: (1) Primary ESP (e.g., Postmark) handles all production sending under normal operation. (2) Secondary ESP (e.g., Mailgun) maintains an active account with all templates configured, authentication set up, and sending domain warmed. (3) The application's email sending library is configured to attempt delivery through the primary ESP, and automatically switch to the secondary if the primary API returns an error or times out after a configurable threshold. (4) The switch from primary to secondary is transparent to the application layer — the same sending call handles both ESPs.
The critical requirement for ESP failover: both ESPs must be configured with custom domain DKIM signing from the same sending domain. If the primary ESP signs with d=brand.com and the secondary signs with d=backupesp.com, the failover produces authentication inconsistency that affects domain reputation. Both ESPs use different DKIM selectors (primary uses selector "mail", backup uses selector "mail-backup") but both sign with d=brand.com — providing authentication continuity regardless of which ESP is handling delivery.
IP Reputation Protection During Disasters
Email infrastructure disasters carry a secondary risk beyond the delivery interruption: reputation damage from the disaster handling. The most common reputation risks during disaster scenarios:
Queue dumps: After restoring a failed MTA, if the queue was preserved, the operator may be tempted to "dump" all queued messages immediately at full sending rate to clear the backlog. This creates a sudden volume spike that ISPs have not seen from this IP before — which may trigger throttling or temporary blocks as the ISP evaluates whether the unusual volume pattern represents a spam event. Resume sending post-disaster at 50% of normal rate, increasing to 100% over 4-6 hours rather than injecting the full queued volume immediately.
Cold IP activation: If the disaster requires activating IPs that have not been maintained in the warm state, activating them at full disaster-response volume causes the warmup problems described in the warmup guides. Cold IPs generate SNDS Yellow status within days and complaint rates disproportionate to their reputation at full volume. Throttle cold IPs to 10-20% of their target volume and increase over 2-3 weeks even during disaster recovery.
Authentication gaps: DNS failures during disasters may cause DKIM or SPF failures during the recovery period. Implement DNS health checks in the monitoring stack that alert on authentication DNS failures within 5 minutes — and verify authentication for the first send after any recovery operation before ramping to full volume.
Queue Preservation and Message Recovery
The MTA queue — messages accepted for delivery but not yet delivered — represents the most vulnerable data during infrastructure failures. Queue preservation strategies depend on the acceptable RPO:
Zero-RPO queue preservation: Queue synchronisation to a secondary storage location in real time. For PowerMTA, the queue files in /var/spool/pmta can be synchronised using DRBD (Distributed Replicated Block Device) to a secondary server with sub-second replication latency. If the primary fails, the secondary can mount the replicated queue and resume delivery from the point of failure with zero message loss.
Acceptable-RPO queue recovery: For programmes with RPO of 30-60 minutes, the application source system maintains the triggering events (email addresses, template parameters, trigger times) for all messages sent in the past 60 minutes. After an infrastructure failure, the application re-triggers all messages from the 60-minute window — regenerating them from the source data rather than recovering them from the queue. This approach is simpler than real-time queue synchronisation but requires source-system re-trigger capability.
DNS Failover for Email Infrastructure
DNS failures are a specific disaster category for email infrastructure because many email deliverability components depend on DNS availability: SPF lookup during SMTP evaluation, DKIM key retrieval for signature verification, PTR lookup for connection validation, and MX lookup for inbound email routing. DNS failover for email infrastructure:
Use multiple DNS providers: The DNS zone for the sending domain should be hosted on at least two DNS providers (primary and secondary). Most domain registrars support secondary nameserver configuration. If the primary DNS provider has an outage, the secondary continues serving DNS records. Configure both providers with identical zone data — including all email authentication records.
Low TTL for critical email records: Set TTL (Time To Live) values on email authentication records (SPF, DKIM, DMARC, PTR) to 300-3600 seconds rather than the default 86400 (24 hours). Lower TTL means DNS changes propagate faster when emergency updates are needed — useful if a record needs to be changed quickly during a disaster scenario.
Disaster Recovery Testing Protocol
A DR plan that has never been tested is not a DR plan — it is a hypothesis. Email infrastructure DR testing should be performed annually at minimum, with the goal of validating that the RTO and RPO commitments are achievable with the current architecture and team capabilities.
▶ Annual DR Test Protocol
Email infrastructure disaster recovery is not glamorous operational work — but the commercial consequence of being unprepared when a disaster occurs is significant. The programme that has tested its failover, maintains backup IPs in a warm state, and has a documented runbook that any team member can execute responds to infrastructure failures within its RTO target. The programme that has not invested in DR discovers its actual recovery capability during the most stressful possible moment — an active outage during a critical sending period. Invest in the DR architecture; test it annually; and infrastructure failures become contained operational incidents rather than reputation-damaging commercial crises.