Email Redundancy Architecture with Multiple MX, Backup MX and Split Delivery

When teams start taking email reliability seriously, the conversation quickly moves from “Where is our mailbox?” to “What happens when that mailbox endpoint is down?” A solid email redundancy architecture answers this question before an outage does. By combining multiple MX records, backup MX servers and (when needed) split delivery, you can keep mail flowing even if one part of the chain fails, or while you are migrating between platforms.

In this article, we will walk through how MX records actually work, how to design redundant paths, when backup MX is a good idea (and when it creates more problems than it solves), and how split delivery lets you run hybrid email setups without breaking deliverability. We will keep the theory practical, using scenarios we see often at dchost.com when customers move from basic shared hosting email to more resilient stacks on VPS, dedicated servers or colocation.

By the end, you should have a clear blueprint for your own email redundancy plan: which MX patterns to choose, how to configure them in DNS, what to test, and common traps to avoid around spam filtering, SPF/DKIM/DMARC and migrations.

How MX Records Really Work (and Why Priority Matters)

Before designing redundancy, you need a clear mental model of how MX records behave. Many email problems we troubleshoot at dchost.com come from misunderstandings at this layer.

What an MX Record Is

An MX (Mail Exchanger) record tells the world which server is responsible for accepting email for a domain. When someone sends an email to [email protected], the sending mail server:

• Looks up the MX records for example.com
• Sorts them by priority (also called preference)
• Tries to connect to the lowest-number priority first (e.g. 10 before 20)
• If that fails, tries the next one, and so on

Each MX record points to a hostname, not directly to an IP. That hostname must resolve via A (IPv4) and/or AAAA (IPv6) records. If those are missing or broken, the MX record is effectively unusable.

If you want a refresher on A, AAAA, MX and other DNS record types, our guide DNS records explained like a friend covers them end to end with practical examples.

MX Priority Explained

Priority is a simple integer where lower numbers mean higher priority. For example:

example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  20  mx2.example.com.

In this setup:

• mx1.example.com is the primary
• mx2.example.com is a backup; it is only used if the primary is unreachable

It is also valid to have equal-priority MX records for load sharing:

example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  10  mx2.example.com.

Here, sending MTAs distribute traffic between both servers, usually in a round-robin or random way. This is how you build active/active MX redundancy.

TTL and Propagation

The TTL (time to live) controls how long resolvers cache your MX records. For a stable production email setup, TTLs of 1–4 hours are common. During migrations or testing new MX priorities, you may temporarily reduce TTL (e.g. 300 seconds) to make changes propagate faster. Our article on TTL strategies for zero-downtime migrations shows how the same approach works for email moves as well as website cutovers.

Design Patterns for Email Redundancy

Once you understand MX priorities, you can mix and match patterns to achieve different redundancy goals. In practice, we see three main patterns:

• Multiple active MX servers (active/active)
• Backup MX (active/passive)
• Split delivery (hybrid routing based on recipient)

Pattern 1: Multiple Active MX Servers

In this design, you publish two or more MX records with the same priority, all pointing to production-ready mail servers:

example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  10  mx2.example.com.

Each MX host:

• Accepts mail directly for your domain
• Applies the same spam filters, policies and TLS settings
• Stores mailboxes (or forwards to the same backend mail cluster)

This is ideal when you have:

• Two VPS servers in different data centers, both running your mail stack
• Two dedicated mail gateways in front of a shared IMAP cluster
• A main mail cluster plus an identically configured cluster in another region

With active/active MX, even if one server is down, the other continues to serve users with minimal disruption. For higher resilience, we often combine this with Anycast or multi-provider DNS, as described in our guide to Anycast DNS and automatic failover.

Pattern 2: Backup MX (Active/Passive)

Here you use one primary MX with a low priority number and one or more backup MX servers with higher numerical priorities:

example.com.  3600  IN  MX  10  mx-primary.example.com.
example.com.  3600  IN  MX  50  mx-backup1.example.net.

Backup MX servers typically:

• Accept mail only when the primary is unreachable
• Store messages temporarily in a queue
• Periodically retry delivery to the primary

From the sender’s perspective, messages are accepted reliably; they might just be delayed slightly during a primary outage. This is useful if your main mail server is on a single VPS or dedicated machine, and you want an offsite safety net without running a full second mailbox stack.

Pattern 3: Split Delivery (Hybrid Email)

Split delivery is not configured in DNS alone; it is a routing decision on your primary mail system. The idea:

• All MX records point to a single front-end mail gateway
• That gateway decides, per recipient, where the mailbox actually lives

For example:

• Local users (e.g. IT, dev team) have mailboxes on your own cPanel or custom Postfix/Dovecot server
• Most business users are on a hosted email platform under the same domain
• During migration, some users have already moved; some are still on the old system

Split delivery lets you migrate gradually, or keep specific teams on self-hosted infrastructure (for compliance or integration reasons) while the rest of the company uses a hosted email suite. Our tutorial on email hosting choices (self-hosted, shared hosting or external suites) fits naturally into planning this kind of hybrid architecture.

Configuring Multiple MX Records Step-by-Step

Let us go through a concrete example of configuring multiple MX records for redundancy. The details vary slightly depending on whether you use DNS at your registrar, on a control panel (cPanel, DirectAdmin, Plesk) or on a separate DNS provider, but the logic is the same.

Step 1: Plan Your Hostnames and IPs

Decide on clear hostnames for each MX server, for example:

• mx1.example.com – primary mail server, hosted on a VPS at dchost.com
• mx2.example.com – secondary mail server, on a second VPS or dedicated server

Each hostname must have:

• An A record for IPv4 (e.g. 203.0.113.10)
• Optionally an AAAA record for IPv6 (e.g. 2001:db8::10)

If you are already comfortable with dual-stack, enabling IPv6 on your mail servers improves future-proofing and sometimes deliverability; our guide Email deliverability over IPv6 walks through PTR, SPF and blocklist considerations.

Step 2: Create A/AAAA Records

In your DNS zone for example.com:

mx1.example.com.  3600  IN  A     203.0.113.10
mx2.example.com.  3600  IN  A     203.0.113.11
; Optional IPv6
mx1.example.com.  3600  IN  AAAA  2001:db8::10
mx2.example.com.  3600  IN  AAAA  2001:db8::11

Make sure reverse DNS (PTR) for these IPs points back to matching hostnames, especially for outbound mail. While PTR does not affect inbound acceptance of your MX, it is critical for avoiding spam flags when sending. Our article Inbox or spam? SPF, DKIM, DMARC and rDNS covers this in more depth.

Step 3: Add MX Records

Now add your MX records at the zone apex:

example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  10  mx2.example.com.

With equal priority (10/10), you have an active/active design. Sending servers will use both MX hosts, which gives you:

• Redundancy if one IP or data center fails
• Some horizontal scaling (more simultaneous connections across servers)

If you prefer active/passive with a backup MX, use different preferences:

example.com.  3600  IN  MX  10  mx1.example.com.  ; Primary
example.com.  3600  IN  MX  50  mx2.example.com.  ; Backup

Step 4: Configure the Mail Servers

DNS alone is not enough; you must configure each mail server properly:

• Accept the domain as a local or virtual domain
• Route mailboxes to the right storage (local Maildir, IMAP backend, etc.)
• Apply spam and virus filtering consistently on all active MX hosts
• Enable TLS (STARTTLS) with valid certificates
• Set HELO/EHLO name to match the server hostname (e.g. mx1.example.com)

If you are building a self-hosted mail stack on a VPS, our in-depth article I built my own mail server with Postfix, Dovecot and rspamd is a great complement to this MX-focused guide.

Step 5: Test Delivery and Failover

Once DNS and servers are configured:

• Send test emails from external providers to various recipients
• Check logs on both MX servers to see which incoming connections they handle
• Temporarily block access to one MX server (e.g. firewall) and ensure senders fail over to the other
• Use tools like dig MX example.com and nslookup -type=mx example.com to verify records

Also test TLS and modern SMTP security features such as MTA-STS and DANE/TLSA where possible. We have a practical playbook at Your mail’s secret bodyguard: SMTP security with MTA-STS, TLS‑RPT and DANE/TLSA.

Backup MX Servers: Benefits, Risks and Design Tips

Backup MX sounds like an obvious win: “If my primary is down, messages still get accepted.” In practice, a poorly designed backup MX can become a spam magnet or a hidden source of delivery problems. Let us break down what to do (and what to avoid).

What a Good Backup MX Should Do

A well-designed backup MX:

• Accepts mail only for your domains (no open relay under any circumstances)
• Applies similar spam checks as your primary, or at least rejects obviously bad traffic
• Queues mail for a limited time (e.g. 2–5 days) when the primary is unreachable
• Retries delivery to the primary with exponential backoff
• Provides clear logs and alerts so you notice if the queue is growing unusually

In many setups we build on dchost.com VPS or dedicated servers, the backup MX is a minimal Postfix instance configured as a “null client”: it does not host mailboxes, only relays queued mail to the primary when available.

The Spam Magnet Problem

Spammers often target backup MX hosts because:

• They are sometimes less strictly filtered than primaries
• They may accept mail that the primary would reject (non-existent recipients, fake senders, etc.)

If your backup MX simply accepts everything and later forwards it to the primary, you may waste bandwidth, CPU and mailbox storage on junk. Worse, if the backup holds huge queues during a long outage, once your primary comes back you can be flooded with delayed spam.

Mitigation strategies:

• Use the same or similar spam filtering rules (e.g. rspamd, SpamAssassin) as your primary
• Enable recipient validation (VRFY/RCPT checks) against a directory or synced aliases if possible
• Reject obvious garbage early (invalid HELO, bad SPF/DMARC, RBL hits)
• Monitor queue size; alert if it grows beyond expected thresholds

Should You Even Use Backup MX?

There are valid cases not to use a separate backup MX at all:

• Your primary email provider already runs a highly redundant cluster with multiple MX endpoints
• You have an active/active design with two or more properly maintained primary MX servers
• Your risk tolerance accepts the rare case where all primary MX hosts are down (often less likely than other business-impacting events)

In those cases, adding a third-party or misconfigured backup MX can introduce more risk than it removes. However, if you run a single self-hosted mail server (e.g. one VPS) and want extra protection against short outages or maintenance windows, a carefully configured backup MX on another dchost.com VPS or colocation server is usually worthwhile.

Split Delivery: Hybrid Email Without Breaking Deliverability

Split delivery becomes relevant when you have more than one mailbox backend for the same domain. Typical scenarios we see:

• Migrating some users from cPanel email to an external suite, but not everyone at once
• Keeping technical or system accounts on self-hosted servers, while business users use a hosted suite
• Segmenting mail for compliance (e.g. finance mailboxes stored on a specific in-house system)

How Split Delivery Works Conceptually

At a high level, split delivery follows this flow:

1. All MX records for example.com point to a front-end mail gateway (or cluster)
2. The gateway receives incoming mail and looks up the recipient address
3. If the mailbox exists locally, the message is delivered there
4. If not, the message is forwarded (relayed) to a different mail system (another domain or a routing host)

This routing can be defined using:

• Local user databases or virtual mailbox maps
• LDAP/Active Directory lookups
• Explicit routing tables (e.g. Postfix transport maps)

Split Delivery vs Forwarding

It is important to distinguish split delivery from simple forwarding:

• Forwarding accepts mail for a user and then sends a new message onward, often rewriting envelope addresses. This can break SPF and DMARC unless you use SRS/ARC.
• Split delivery is a routing decision on the first hop: the MX gateway never pretends the mailbox lives there; it simply routes to the correct final destination based on recipient.

In practice, you may need a mix: some addresses are truly routed (split delivery), others are forwarded copies. If you rely heavily on forwarding, especially across domains and providers, learn how to fix SPF/DMARC issues with SRS and ARC using our guide Forwarding broke your SPF/DMARC? Here is how SRS and ARC save the day.

Configuration Example (Conceptual)

Let us say:

• IT and dev mailboxes stay on mail.example.com (self-hosted Postfix/Dovecot on a dchost.com VPS)
• Everyone else is on a hosted suite at example.mailhost.net

Your MX records might all point to the self-hosted gateway:

example.com.  3600  IN  MX  10  mail.example.com.

On mail.example.com you then configure:

• Local virtual mailboxes for it@, dev@, alerts@, etc.
• A transport map saying “for all other recipients under @example.com, route to example.mailhost.net using SMTP”

This way:

• [email protected] – delivered locally
• [email protected] – routed to external suite

Because the MX gateway is only performing a single-hop route (not re-sending as a separate message), DMARC alignment is usually easier to handle correctly than with naive forwarding.

Common Split Delivery Pitfalls

Watch out for these issues:

• Looping: Misconfigured routing where mail bounces back and forth between systems. Always ensure each system knows which recipients it is authoritative for.
• Catch-all addresses: Catch-alls on multiple systems can hide configuration errors and cause unexpected routing.
• Auto-replies and filters: Vacation responders or filters on both sides (local and external) can cause confusing behaviour or even loops.
• Inconsistent spam policies: Users on different backends experiencing very different spam filtering quality can lead to support headaches.

We usually recommend writing down your split-delivery logic as a short runbook with clear “who lives where” tables. This also helps when you eventually complete a migration and want to simplify routing back to a single system.

End-to-End Example Architectures

To make these patterns concrete, here are three real-world-style architectures we frequently discuss with customers at dchost.com.

1) Small Business: Shared Hosting + VPS Backup MX

Scenario:

• Website and email on a shared hosting plan
• Concern about losing mail if shared server has an outage
• Limited budget, but okay with mild complexity

Architecture:

• Primary MX: shared hosting mail server
• Backup MX: a small VPS at dchost.com running Postfix as a store-and-forward relay

DNS:

example.com.  3600  IN  MX  10  mail.shared-hosting.example.
example.com.  3600  IN  MX  50  mx-backup.dchost-vps.example.

Mail flow:

• Normal: mail goes to shared hosting
• Outage: mail goes to VPS; messages are queued and retried until shared hosting is back

When the business grows or moves the website to a VPS, they can retire the backup MX or repurpose it as an active second MX in a more advanced setup. If you are evaluating the trade-offs of shared hosting vs VPS, our article Choosing the best hosting for WordPress: shared vs managed vs VPS gives a clear picture.

2) Self-Hosted Mail on Two VPS Servers (Active/Active)

Scenario:

• You want full control over mail, with strong redundancy
• You run your own Postfix/Dovecot/rspamd stack
• You are comfortable managing two VPS servers or dedicated machines

Architecture:

• mx1.example.com – VPS #1 in Datacenter A
• mx2.example.com – VPS #2 in Datacenter B
• Shared mailbox storage via IMAP replication or external object storage for backups

DNS:

example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  10  mx2.example.com.

Mail flow:

• Senders distribute traffic between both MX servers
• If one server or data center is down, the other keeps accepting mail

This design pairs well with a solid backup strategy (for example, backing up maildirs or IMAP data to S3-compatible storage) and monitoring. If you are new to planning VPS resources for such workloads, see our guide How much CPU, RAM and bandwidth a new website (and by extension, mail stack) needs to avoid under- or over-provisioning.

3) Migration: From cPanel Email to Hosted Suite with Split Delivery

Scenario:

• Your existing mailboxes are on a cPanel server
• You are moving most users to a hosted suite under the same domain
• You want zero downtime and a gradual migration

Architecture:

• During migration, MX points to a smart gateway (could be the hosted suite or a dedicated gateway you control)
• Gateway uses split delivery: some addresses route to cPanel, others to the new suite

This approach lets you move departments one by one, testing calendars, mobile sync and spam handling as you go, instead of flipping everyone at once. For a full migration playbook (including DNS cutover, IMAP sync and user communication), check our article Moving email between Google Workspace, Microsoft 365 and cPanel without downtime.

Operational Practices: Monitoring, Security and Documentation

Redundant MX records are just one part of a resilient email story. To make the architecture actually reliable in production, you also need good operational hygiene.

Monitor What Matters

At minimum, monitor:

• SMTP availability on all MX hosts (ports 25 and 587/465 if you provide submission)
• Queue size on each mail server (spikes can indicate a problem)
• Disk usage where queues and mailboxes live
• TLS certificate expiry on all SMTP endpoints

We often recommend pairing MX redundancy with a simple uptime monitor such as Uptime Kuma plus server-level metrics via Prometheus/Grafana, as described in our guide VPS monitoring and alerts without tears.

Keep SPF, DKIM and DMARC in Sync

Every outbound server that sends mail for your domain must be:

• Included in your SPF record
• Signing with DKIM keys published in DNS
• Aligned with your DMARC policy

If you add a new MX host that also sends mail (e.g. user submission, auto-replies), update these records accordingly. If it only receives mail and relays internally without sending outside, SPF/DKIM/DMARC may not need changes, but double-check any bounce or notification flows.

Document Your Routing Rules

Write a short internal document that answers:

• Which MX records exist and why
• Which servers are primary vs backup
• Which users live on which backend in a split-delivery setup
• What to do when a queue grows unusually large

This seems boring until the day a colleague is debugging mail flow at 09:00 on a Monday. Clear documentation turns a potential incident into a simple checklist.

Conclusion: Designing Email Redundancy You Can Trust

Email redundancy architecture is less about clever tricks and more about getting the fundamentals consistently right. Multiple MX records give you resilience against single-server or single-datacenter failures. Backup MX servers can smooth over outages when you only have one main mail host, as long as they are configured with proper spam controls and queue limits. Split delivery lets you run hybrid environments and migrations calmly, instead of with risky big-bang cutovers.

At dchost.com, we see the best results when teams treat email like any other critical service: plan the topology, document the flows, monitor the right metrics and rehearse what happens during failures. Whether your MX hosts run on robust shared hosting, a carefully sized VPS cluster, dedicated hardware or colocation, the principles stay the same: clear DNS, consistent security (SPF/DKIM/DMARC, TLS, MTA-STS), and simple, well-tested routing rules.

If you are planning a new mail setup or reworking an existing one, we are happy to help you choose the right combination of shared hosting, VPS, dedicated servers or colocation at dchost.com, and design MX redundancy that actually fits your risk profile. Start with a small, realistic blueprint, test failover deliberately, and grow the architecture as your needs evolve—without losing a single important message along the way.