{"id":2806,"date":"2025-12-03T19:34:24","date_gmt":"2025-12-03T16:34:24","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/email-redundancy-architecture-with-multiple-mx-backup-mx-and-split-delivery\/"},"modified":"2025-12-03T19:34:24","modified_gmt":"2025-12-03T16:34:24","slug":"email-redundancy-architecture-with-multiple-mx-backup-mx-and-split-delivery","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/email-redundancy-architecture-with-multiple-mx-backup-mx-and-split-delivery\/","title":{"rendered":"Email Redundancy Architecture with Multiple MX, Backup MX and Split Delivery"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When teams start taking email reliability seriously, the conversation quickly moves from \u201cWhere is our mailbox?\u201d to \u201cWhat happens when that mailbox endpoint is down?\u201d 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.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation.<\/p>\n<p>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.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_MX_Records_Really_Work_and_Why_Priority_Matters\"><span class=\"toc_number toc_depth_1\">1<\/span> How MX Records Really Work (and Why Priority Matters)<\/a><ul><li><a href=\"#What_an_MX_Record_Is\"><span class=\"toc_number toc_depth_2\">1.1<\/span> What an MX Record Is<\/a><\/li><li><a href=\"#MX_Priority_Explained\"><span class=\"toc_number toc_depth_2\">1.2<\/span> MX Priority Explained<\/a><\/li><li><a href=\"#TTL_and_Propagation\"><span class=\"toc_number toc_depth_2\">1.3<\/span> TTL and Propagation<\/a><\/li><\/ul><\/li><li><a href=\"#Design_Patterns_for_Email_Redundancy\"><span class=\"toc_number toc_depth_1\">2<\/span> Design Patterns for Email Redundancy<\/a><ul><li><a href=\"#Pattern_1_Multiple_Active_MX_Servers\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Pattern 1: Multiple Active MX Servers<\/a><\/li><li><a href=\"#Pattern_2_Backup_MX_ActivePassive\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Pattern 2: Backup MX (Active\/Passive)<\/a><\/li><li><a href=\"#Pattern_3_Split_Delivery_Hybrid_Email\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Pattern 3: Split Delivery (Hybrid Email)<\/a><\/li><\/ul><\/li><li><a href=\"#Configuring_Multiple_MX_Records_Step-by-Step\"><span class=\"toc_number toc_depth_1\">3<\/span> Configuring Multiple MX Records Step-by-Step<\/a><ul><li><a href=\"#Step_1_Plan_Your_Hostnames_and_IPs\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Step 1: Plan Your Hostnames and IPs<\/a><\/li><li><a href=\"#Step_2_Create_AAAAA_Records\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Step 2: Create A\/AAAA Records<\/a><\/li><li><a href=\"#Step_3_Add_MX_Records\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Step 3: Add MX Records<\/a><\/li><li><a href=\"#Step_4_Configure_the_Mail_Servers\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Step 4: Configure the Mail Servers<\/a><\/li><li><a href=\"#Step_5_Test_Delivery_and_Failover\"><span class=\"toc_number toc_depth_2\">3.5<\/span> Step 5: Test Delivery and Failover<\/a><\/li><\/ul><\/li><li><a href=\"#Backup_MX_Servers_Benefits_Risks_and_Design_Tips\"><span class=\"toc_number toc_depth_1\">4<\/span> Backup MX Servers: Benefits, Risks and Design Tips<\/a><ul><li><a href=\"#What_a_Good_Backup_MX_Should_Do\"><span class=\"toc_number toc_depth_2\">4.1<\/span> What a Good Backup MX Should Do<\/a><\/li><li><a href=\"#The_Spam_Magnet_Problem\"><span class=\"toc_number toc_depth_2\">4.2<\/span> The Spam Magnet Problem<\/a><\/li><li><a href=\"#Should_You_Even_Use_Backup_MX\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Should You Even Use Backup MX?<\/a><\/li><\/ul><\/li><li><a href=\"#Split_Delivery_Hybrid_Email_Without_Breaking_Deliverability\"><span class=\"toc_number toc_depth_1\">5<\/span> Split Delivery: Hybrid Email Without Breaking Deliverability<\/a><ul><li><a href=\"#How_Split_Delivery_Works_Conceptually\"><span class=\"toc_number toc_depth_2\">5.1<\/span> How Split Delivery Works Conceptually<\/a><\/li><li><a href=\"#Split_Delivery_vs_Forwarding\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Split Delivery vs Forwarding<\/a><\/li><li><a href=\"#Configuration_Example_Conceptual\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Configuration Example (Conceptual)<\/a><\/li><li><a href=\"#Common_Split_Delivery_Pitfalls\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Common Split Delivery Pitfalls<\/a><\/li><\/ul><\/li><li><a href=\"#End-to-End_Example_Architectures\"><span class=\"toc_number toc_depth_1\">6<\/span> End-to-End Example Architectures<\/a><ul><li><a href=\"#1_Small_Business_Shared_Hosting_VPS_Backup_MX\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1) Small Business: Shared Hosting + VPS Backup MX<\/a><\/li><li><a href=\"#2_Self-Hosted_Mail_on_Two_VPS_Servers_ActiveActive\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2) Self-Hosted Mail on Two VPS Servers (Active\/Active)<\/a><\/li><li><a href=\"#3_Migration_From_cPanel_Email_to_Hosted_Suite_with_Split_Delivery\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3) Migration: From cPanel Email to Hosted Suite with Split Delivery<\/a><\/li><\/ul><\/li><li><a href=\"#Operational_Practices_Monitoring_Security_and_Documentation\"><span class=\"toc_number toc_depth_1\">7<\/span> Operational Practices: Monitoring, Security and Documentation<\/a><ul><li><a href=\"#Monitor_What_Matters\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Monitor What Matters<\/a><\/li><li><a href=\"#Keep_SPF_DKIM_and_DMARC_in_Sync\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Keep SPF, DKIM and DMARC in Sync<\/a><\/li><li><a href=\"#Document_Your_Routing_Rules\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Document Your Routing Rules<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_Designing_Email_Redundancy_You_Can_Trust\"><span class=\"toc_number toc_depth_1\">8<\/span> Conclusion: Designing Email Redundancy You Can Trust<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_MX_Records_Really_Work_and_Why_Priority_Matters\">How MX Records Really Work (and Why Priority Matters)<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"What_an_MX_Record_Is\">What an MX Record Is<\/span><\/h3>\n<p>An MX (Mail Exchanger) record tells the world which server is responsible for accepting email for a domain. When someone sends an email to <code>user@example.com<\/code>, the sending mail server:<\/p>\n<ul>\n<li>Looks up the MX records for <code>example.com<\/code><\/li>\n<li>Sorts them by priority (also called preference)<\/li>\n<li>Tries to connect to the lowest-number priority first (e.g. 10 before 20)<\/li>\n<li>If that fails, tries the next one, and so on<\/li>\n<\/ul>\n<p>Each MX record points to a <strong>hostname<\/strong>, 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.<\/p>\n<p>If you want a refresher on A, AAAA, MX and other DNS record types, our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">DNS records explained like a friend<\/a> covers them end to end with practical examples.<\/p>\n<h3><span id=\"MX_Priority_Explained\">MX Priority Explained<\/span><\/h3>\n<p>Priority is a simple integer where <strong>lower numbers mean higher priority<\/strong>. For example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.\nexample.com.  3600  IN  MX  20  mx2.example.com.\n<\/code><\/pre>\n<p>In this setup:<\/p>\n<ul>\n<li><code>mx1.example.com<\/code> is the primary<\/li>\n<li><code>mx2.example.com<\/code> is a backup; it is only used if the primary is unreachable<\/li>\n<\/ul>\n<p>It is also valid to have <strong>equal-priority MX records<\/strong> for load sharing:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.\nexample.com.  3600  IN  MX  10  mx2.example.com.\n<\/code><\/pre>\n<p>Here, sending MTAs distribute traffic between both servers, usually in a round-robin or random way. This is how you build <strong>active\/active<\/strong> MX redundancy.<\/p>\n<h3><span id=\"TTL_and_Propagation\">TTL and Propagation<\/span><\/h3>\n<p>The TTL (time to live) controls how long resolvers cache your MX records. For a stable production email setup, TTLs of 1\u20134 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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero-downtime migrations<\/a> shows how the same approach works for email moves as well as website cutovers.<\/p>\n<h2><span id=\"Design_Patterns_for_Email_Redundancy\">Design Patterns for Email Redundancy<\/span><\/h2>\n<p>Once you understand MX priorities, you can mix and match patterns to achieve different redundancy goals. In practice, we see three main patterns:<\/p>\n<ul>\n<li>Multiple active MX servers (active\/active)<\/li>\n<li>Backup MX (active\/passive)<\/li>\n<li>Split delivery (hybrid routing based on recipient)<\/li>\n<\/ul>\n<h3><span id=\"Pattern_1_Multiple_Active_MX_Servers\">Pattern 1: Multiple Active MX Servers<\/span><\/h3>\n<p>In this design, you publish two or more MX records with the <strong>same priority<\/strong>, all pointing to production-ready mail servers:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.\nexample.com.  3600  IN  MX  10  mx2.example.com.\n<\/code><\/pre>\n<p>Each MX host:<\/p>\n<ul>\n<li>Accepts mail directly for your domain<\/li>\n<li>Applies the same spam filters, policies and TLS settings<\/li>\n<li>Stores mailboxes (or forwards to the same backend mail cluster)<\/li>\n<\/ul>\n<p>This is ideal when you have:<\/p>\n<ul>\n<li>Two VPS servers in different data centers, both running your mail stack<\/li>\n<li>Two dedicated mail gateways in front of a shared IMAP cluster<\/li>\n<li>A main mail cluster plus an identically configured cluster in another region<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/hic-kesilmeden-yayinda-kalmak-mumkun-mu-anycast-dns-ve-otomatik-failover-ile-nasil-saglanir\/\">Anycast DNS and automatic failover<\/a>.<\/p>\n<h3><span id=\"Pattern_2_Backup_MX_ActivePassive\">Pattern 2: Backup MX (Active\/Passive)<\/span><\/h3>\n<p>Here you use one primary MX with a low priority number and one or more backup MX servers with higher numerical priorities:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx-primary.example.com.\nexample.com.  3600  IN  MX  50  mx-backup1.example.net.\n<\/code><\/pre>\n<p>Backup MX servers typically:<\/p>\n<ul>\n<li>Accept mail only when the primary is unreachable<\/li>\n<li>Store messages temporarily in a queue<\/li>\n<li>Periodically retry delivery to the primary<\/li>\n<\/ul>\n<p>From the sender\u2019s 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.<\/p>\n<h3><span id=\"Pattern_3_Split_Delivery_Hybrid_Email\">Pattern 3: Split Delivery (Hybrid Email)<\/span><\/h3>\n<p>Split delivery is <strong>not<\/strong> configured in DNS alone; it is a routing decision on your primary mail system. The idea:<\/p>\n<ul>\n<li>All MX records point to a single front-end mail gateway<\/li>\n<li>That gateway decides, per recipient, where the mailbox actually lives<\/li>\n<\/ul>\n<p>For example:<\/p>\n<ul>\n<li>Local users (e.g. IT, dev team) have mailboxes on your own cPanel or custom Postfix\/Dovecot server<\/li>\n<li>Most business users are on a hosted email platform under the same domain<\/li>\n<li>During migration, some users have already moved; some are still on the old system<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/e-posta-hosting-secimi-kendi-sunucunuz-mu-paylasimli-hosting-mi-google-workspace-ve-microsoft-365-mi\/\">email hosting choices (self-hosted, shared hosting or external suites)<\/a> fits naturally into planning this kind of hybrid architecture.<\/p>\n<h2><span id=\"Configuring_Multiple_MX_Records_Step-by-Step\">Configuring Multiple MX Records Step-by-Step<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Step_1_Plan_Your_Hostnames_and_IPs\">Step 1: Plan Your Hostnames and IPs<\/span><\/h3>\n<p>Decide on clear hostnames for each MX server, for example:<\/p>\n<ul>\n<li><code>mx1.example.com<\/code> \u2013 primary mail server, hosted on a VPS at dchost.com<\/li>\n<li><code>mx2.example.com<\/code> \u2013 secondary mail server, on a second VPS or dedicated server<\/li>\n<\/ul>\n<p>Each hostname must have:<\/p>\n<ul>\n<li>An A record for IPv4 (e.g. <code>203.0.113.10<\/code>)<\/li>\n<li>Optionally an AAAA record for IPv6 (e.g. <code>2001:db8::10<\/code>)<\/li>\n<\/ul>\n<p>If you are already comfortable with dual-stack, enabling IPv6 on your mail servers improves future-proofing and sometimes deliverability; our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/ipv6-ile-e%e2%80%91posta-teslimi-nasil-rayina-oturur-ptr-helo-spf-ve-rbllerle-saha-rehberi\/\">Email deliverability over IPv6<\/a> walks through PTR, SPF and blocklist considerations.<\/p>\n<h3><span id=\"Step_2_Create_AAAAA_Records\">Step 2: Create A\/AAAA Records<\/span><\/h3>\n<p>In your DNS zone for <code>example.com<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">mx1.example.com.  3600  IN  A     203.0.113.10\nmx2.example.com.  3600  IN  A     203.0.113.11\n; Optional IPv6\nmx1.example.com.  3600  IN  AAAA  2001:db8::10\nmx2.example.com.  3600  IN  AAAA  2001:db8::11\n<\/code><\/pre>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">Inbox or spam? SPF, DKIM, DMARC and rDNS<\/a> covers this in more depth.<\/p>\n<h3><span id=\"Step_3_Add_MX_Records\">Step 3: Add MX Records<\/span><\/h3>\n<p>Now add your MX records at the zone apex:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.\nexample.com.  3600  IN  MX  10  mx2.example.com.\n<\/code><\/pre>\n<p>With equal priority (10\/10), you have an active\/active design. Sending servers will use both MX hosts, which gives you:<\/p>\n<ul>\n<li>Redundancy if one IP or data center fails<\/li>\n<li>Some horizontal scaling (more simultaneous connections across servers)<\/li>\n<\/ul>\n<p>If you prefer active\/passive with a backup MX, use different preferences:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.  ; Primary\nexample.com.  3600  IN  MX  50  mx2.example.com.  ; Backup\n<\/code><\/pre>\n<h3><span id=\"Step_4_Configure_the_Mail_Servers\">Step 4: Configure the Mail Servers<\/span><\/h3>\n<p>DNS alone is not enough; you must configure each mail server properly:<\/p>\n<ul>\n<li><strong>Accept the domain<\/strong> as a local or virtual domain<\/li>\n<li><strong>Route mailboxes<\/strong> to the right storage (local Maildir, IMAP backend, etc.)<\/li>\n<li><strong>Apply spam and virus filtering<\/strong> consistently on all active MX hosts<\/li>\n<li><strong>Enable TLS<\/strong> (STARTTLS) with valid certificates<\/li>\n<li><strong>Set HELO\/EHLO name<\/strong> to match the server hostname (e.g. <code>mx1.example.com<\/code>)<\/li>\n<\/ul>\n<p>If you are building a self-hosted mail stack on a VPS, our in-depth article <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-e%e2%80%91posta-sunucusu-kurulumu-postfix-dovecot-rspamd-ile-teslim-edilebilirlik-ve-ip-isitma-adim-adim\/\">I built my own mail server with Postfix, Dovecot and rspamd<\/a> is a great complement to this MX-focused guide.<\/p>\n<h3><span id=\"Step_5_Test_Delivery_and_Failover\">Step 5: Test Delivery and Failover<\/span><\/h3>\n<p>Once DNS and servers are configured:<\/p>\n<ul>\n<li>Send test emails from external providers to various recipients<\/li>\n<li>Check logs on both MX servers to see which incoming connections they handle<\/li>\n<li>Temporarily block access to one MX server (e.g. firewall) and ensure senders fail over to the other<\/li>\n<li>Use tools like <code>dig MX example.com<\/code> and <code>nslookup -type=mx example.com<\/code> to verify records<\/li>\n<\/ul>\n<p>Also test TLS and modern SMTP security features such as MTA-STS and DANE\/TLSA where possible. We have a practical playbook at <a href=\"https:\/\/www.dchost.com\/blog\/en\/mta-sts-tls-rpt-ve-dane-tlsa-ile-smtp-guvenligi-teslim-edilebilirligi-ve-sifrelemeyi-nasil-guclendirirsin\/\">Your mail\u2019s secret bodyguard: SMTP security with MTA-STS, TLS\u2011RPT and DANE\/TLSA<\/a>.<\/p>\n<h2><span id=\"Backup_MX_Servers_Benefits_Risks_and_Design_Tips\">Backup MX Servers: Benefits, Risks and Design Tips<\/span><\/h2>\n<p>Backup MX sounds like an obvious win: \u201cIf my primary is down, messages still get accepted.\u201d 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).<\/p>\n<h3><span id=\"What_a_Good_Backup_MX_Should_Do\">What a Good Backup MX Should Do<\/span><\/h3>\n<p>A well-designed backup MX:<\/p>\n<ul>\n<li><strong>Accepts mail only for your domains<\/strong> (no open relay under any circumstances)<\/li>\n<li><strong>Applies similar spam checks<\/strong> as your primary, or at least rejects obviously bad traffic<\/li>\n<li><strong>Queues mail<\/strong> for a limited time (e.g. 2\u20135 days) when the primary is unreachable<\/li>\n<li><strong>Retries delivery<\/strong> to the primary with exponential backoff<\/li>\n<li><strong>Provides clear logs and alerts<\/strong> so you notice if the queue is growing unusually<\/li>\n<\/ul>\n<p>In many setups we build on dchost.com VPS or dedicated servers, the backup MX is a minimal Postfix instance configured as a \u201cnull client\u201d: it does not host mailboxes, only relays queued mail to the primary when available.<\/p>\n<h3><span id=\"The_Spam_Magnet_Problem\">The Spam Magnet Problem<\/span><\/h3>\n<p>Spammers often target backup MX hosts because:<\/p>\n<ul>\n<li>They are sometimes less strictly filtered than primaries<\/li>\n<li>They may accept mail that the primary would reject (non-existent recipients, fake senders, etc.)<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>Mitigation strategies:<\/p>\n<ul>\n<li>Use the same or similar spam filtering rules (e.g. rspamd, SpamAssassin) as your primary<\/li>\n<li>Enable recipient validation (VRFY\/RCPT checks) against a directory or synced aliases if possible<\/li>\n<li>Reject obvious garbage early (invalid HELO, bad SPF\/DMARC, RBL hits)<\/li>\n<li>Monitor queue size; alert if it grows beyond expected thresholds<\/li>\n<\/ul>\n<h3><span id=\"Should_You_Even_Use_Backup_MX\">Should You Even Use Backup MX?<\/span><\/h3>\n<p>There are valid cases <strong>not<\/strong> to use a separate backup MX at all:<\/p>\n<ul>\n<li>Your primary email provider already runs a highly redundant cluster with multiple MX endpoints<\/li>\n<li>You have an active\/active design with two or more properly maintained primary MX servers<\/li>\n<li>Your risk tolerance accepts the rare case where all primary MX hosts are down (often less likely than other business-impacting events)<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Split_Delivery_Hybrid_Email_Without_Breaking_Deliverability\">Split Delivery: Hybrid Email Without Breaking Deliverability<\/span><\/h2>\n<p>Split delivery becomes relevant when you have more than one mailbox backend for the same domain. Typical scenarios we see:<\/p>\n<ul>\n<li>Migrating some users from cPanel email to an external suite, but not everyone at once<\/li>\n<li>Keeping technical or system accounts on self-hosted servers, while business users use a hosted suite<\/li>\n<li>Segmenting mail for compliance (e.g. finance mailboxes stored on a specific in-house system)<\/li>\n<\/ul>\n<h3><span id=\"How_Split_Delivery_Works_Conceptually\">How Split Delivery Works Conceptually<\/span><\/h3>\n<p>At a high level, split delivery follows this flow:<\/p>\n<ol>\n<li>All MX records for <code>example.com<\/code> point to a front-end mail gateway (or cluster)<\/li>\n<li>The gateway receives incoming mail and looks up the recipient address<\/li>\n<li>If the mailbox exists locally, the message is delivered there<\/li>\n<li>If not, the message is forwarded (relayed) to a different mail system (another domain or a routing host)<\/li>\n<\/ol>\n<p>This routing can be defined using:<\/p>\n<ul>\n<li>Local user databases or virtual mailbox maps<\/li>\n<li>LDAP\/Active Directory lookups<\/li>\n<li>Explicit routing tables (e.g. Postfix <code>transport<\/code> maps)<\/li>\n<\/ul>\n<h3><span id=\"Split_Delivery_vs_Forwarding\">Split Delivery vs Forwarding<\/span><\/h3>\n<p>It is important to distinguish split delivery from simple forwarding:<\/p>\n<ul>\n<li><strong>Forwarding<\/strong> 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.<\/li>\n<li><strong>Split delivery<\/strong> is a <strong>routing decision<\/strong> on the first hop: the MX gateway never pretends the mailbox lives there; it simply routes to the correct final destination based on recipient.<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91posta-yonlendirmede-spf-dmarc-neden-kiriliyor-srs-ve-arc-ile-nasil-tatli-tatli-onarirsin\/\">Forwarding broke your SPF\/DMARC? Here is how SRS and ARC save the day<\/a>.<\/p>\n<h3><span id=\"Configuration_Example_Conceptual\">Configuration Example (Conceptual)<\/span><\/h3>\n<p>Let us say:<\/p>\n<ul>\n<li>IT and dev mailboxes stay on <code>mail.example.com<\/code> (self-hosted Postfix\/Dovecot on a dchost.com VPS)<\/li>\n<li>Everyone else is on a hosted suite at <code>example.mailhost.net<\/code><\/li>\n<\/ul>\n<p>Your MX records might all point to the self-hosted gateway:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mail.example.com.\n<\/code><\/pre>\n<p>On <code>mail.example.com<\/code> you then configure:<\/p>\n<ul>\n<li>Local virtual mailboxes for <code>it@<\/code>, <code>dev@<\/code>, <code>alerts@<\/code>, etc.<\/li>\n<li>A transport map saying \u201cfor all other recipients under <code>@example.com<\/code>, route to <code>example.mailhost.net<\/code> using SMTP\u201d<\/li>\n<\/ul>\n<p>This way:<\/p>\n<ul>\n<li><code>user@it.example.com<\/code> \u2013 delivered locally<\/li>\n<li><code>alice@example.com<\/code> \u2013 routed to external suite<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Common_Split_Delivery_Pitfalls\">Common Split Delivery Pitfalls<\/span><\/h3>\n<p>Watch out for these issues:<\/p>\n<ul>\n<li><strong>Looping<\/strong>: Misconfigured routing where mail bounces back and forth between systems. Always ensure each system knows which recipients it is authoritative for.<\/li>\n<li><strong>Catch-all addresses<\/strong>: Catch-alls on multiple systems can hide configuration errors and cause unexpected routing.<\/li>\n<li><strong>Auto-replies and filters<\/strong>: Vacation responders or filters on both sides (local and external) can cause confusing behaviour or even loops.<\/li>\n<li><strong>Inconsistent spam policies<\/strong>: Users on different backends experiencing very different spam filtering quality can lead to support headaches.<\/li>\n<\/ul>\n<p>We usually recommend writing down your split-delivery logic as a short <strong>runbook<\/strong> with clear \u201cwho lives where\u201d tables. This also helps when you eventually complete a migration and want to simplify routing back to a single system.<\/p>\n<h2><span id=\"End-to-End_Example_Architectures\">End-to-End Example Architectures<\/span><\/h2>\n<p>To make these patterns concrete, here are three real-world-style architectures we frequently discuss with customers at dchost.com.<\/p>\n<h3><span id=\"1_Small_Business_Shared_Hosting_VPS_Backup_MX\">1) Small Business: Shared Hosting + VPS Backup MX<\/span><\/h3>\n<p>Scenario:<\/p>\n<ul>\n<li>Website and email on a shared hosting plan<\/li>\n<li>Concern about losing mail if shared server has an outage<\/li>\n<li>Limited budget, but okay with mild complexity<\/li>\n<\/ul>\n<p>Architecture:<\/p>\n<ul>\n<li>Primary MX: shared hosting mail server<\/li>\n<li>Backup MX: a small VPS at dchost.com running Postfix as a store-and-forward relay<\/li>\n<\/ul>\n<p>DNS:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mail.shared-hosting.example.\nexample.com.  3600  IN  MX  50  mx-backup.dchost-vps.example.\n<\/code><\/pre>\n<p>Mail flow:<\/p>\n<ul>\n<li>Normal: mail goes to shared hosting<\/li>\n<li>Outage: mail goes to VPS; messages are queued and retried until shared hosting is back<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-en-iyi-hosting-secimi-paylasimli-yonetilen-ve-vps-karsilastirmasi\/\">Choosing the best hosting for WordPress: shared vs managed vs VPS<\/a> gives a clear picture.<\/p>\n<h3><span id=\"2_Self-Hosted_Mail_on_Two_VPS_Servers_ActiveActive\">2) Self-Hosted Mail on Two VPS Servers (Active\/Active)<\/span><\/h3>\n<p>Scenario:<\/p>\n<ul>\n<li>You want full control over mail, with strong redundancy<\/li>\n<li>You run your own Postfix\/Dovecot\/rspamd stack<\/li>\n<li>You are comfortable managing two VPS servers or dedicated machines<\/li>\n<\/ul>\n<p>Architecture:<\/p>\n<ul>\n<li><strong>mx1.example.com<\/strong> \u2013 VPS #1 in Datacenter A<\/li>\n<li><strong>mx2.example.com<\/strong> \u2013 VPS #2 in Datacenter B<\/li>\n<li>Shared mailbox storage via IMAP replication or external object storage for backups<\/li>\n<\/ul>\n<p>DNS:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  3600  IN  MX  10  mx1.example.com.\nexample.com.  3600  IN  MX  10  mx2.example.com.\n<\/code><\/pre>\n<p>Mail flow:<\/p>\n<ul>\n<li>Senders distribute traffic between both MX servers<\/li>\n<li>If one server or data center is down, the other keeps accepting mail<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-web-sitesi-icin-cpu-ram-ve-trafik-nasil-hesaplanir\/\">How much CPU, RAM and bandwidth a new website (and by extension, mail stack) needs<\/a> to avoid under- or over-provisioning.<\/p>\n<h3><span id=\"3_Migration_From_cPanel_Email_to_Hosted_Suite_with_Split_Delivery\">3) Migration: From cPanel Email to Hosted Suite with Split Delivery<\/span><\/h3>\n<p>Scenario:<\/p>\n<ul>\n<li>Your existing mailboxes are on a cPanel server<\/li>\n<li>You are moving most users to a hosted suite under the same domain<\/li>\n<li>You want zero downtime and a gradual migration<\/li>\n<\/ul>\n<p>Architecture:<\/p>\n<ul>\n<li>During migration, MX points to a smart gateway (could be the hosted suite or a dedicated gateway you control)<\/li>\n<li>Gateway uses split delivery: some addresses route to cPanel, others to the new suite<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/e-posta-altyapisini-tasirken-kesinti-yasamamak\/\">Moving email between Google Workspace, Microsoft 365 and cPanel without downtime<\/a>.<\/p>\n<h2><span id=\"Operational_Practices_Monitoring_Security_and_Documentation\">Operational Practices: Monitoring, Security and Documentation<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Monitor_What_Matters\">Monitor What Matters<\/span><\/h3>\n<p>At minimum, monitor:<\/p>\n<ul>\n<li><strong>SMTP availability<\/strong> on all MX hosts (ports 25 and 587\/465 if you provide submission)<\/li>\n<li><strong>Queue size<\/strong> on each mail server (spikes can indicate a problem)<\/li>\n<li><strong>Disk usage<\/strong> where queues and mailboxes live<\/li>\n<li><strong>TLS certificate expiry<\/strong> on all SMTP endpoints<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/\">VPS monitoring and alerts without tears<\/a>.<\/p>\n<h3><span id=\"Keep_SPF_DKIM_and_DMARC_in_Sync\">Keep SPF, DKIM and DMARC in Sync<\/span><\/h3>\n<p>Every outbound server that sends mail for your domain must be:<\/p>\n<ul>\n<li>Included in your <strong>SPF<\/strong> record<\/li>\n<li>Signing with <strong>DKIM<\/strong> keys published in DNS<\/li>\n<li>Aligned with your <strong>DMARC<\/strong> policy<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Document_Your_Routing_Rules\">Document Your Routing Rules<\/span><\/h3>\n<p>Write a short internal document that answers:<\/p>\n<ul>\n<li>Which MX records exist and why<\/li>\n<li>Which servers are primary vs backup<\/li>\n<li>Which users live on which backend in a split-delivery setup<\/li>\n<li>What to do when a queue grows unusually large<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Conclusion_Designing_Email_Redundancy_You_Can_Trust\">Conclusion: Designing Email Redundancy You Can Trust<\/span><\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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\u2014without losing a single important message along the way.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When teams start taking email reliability seriously, the conversation quickly moves from \u201cWhere is our mailbox?\u201d to \u201cWhat happens when that mailbox endpoint is down?\u201d 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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2807,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2806","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2806","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2806"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2806\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2807"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2806"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2806"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2806"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}