What happens to email delivery when your primary MX server goes down?

You send an important email — and it vanishes. No bounce, no error. Just silence. Your team assumes it arrived. But what if your primary mail server went offline, and your DNS MX records weren’t set up to handle it?

Email delivery doesn’t stop when a server is down. It can reroute, but only if your MX records have proper priority levels and backup servers configured. Otherwise, messages are lost or delayed until the primary comes back.

MX records don’t just point to a server — they define a hierarchy. When the primary (lowest priority number) is unreachable, the next one (higher number, lower priority) takes over. This failover is automatic, but it depends entirely on correct setup. No setup? No failover. No delivery.

Key takeaways

  • Lower numeric values in MX records indicate higher priority; the lowest is used first.
  • When the primary MX server is unreachable, DNS routing automatically falls back to the next-highest-priority MX record.
  • Without multiple properly prioritized MX records, email delivery fails during primary server downtime.

How do MX record priorities actually work in practice?

MX records assign a numerical priority to each mail server for a domain, with lower numbers meaning higher priority. When sending an email, your server checks the domain’s DNS and tries the lowest-numbered MX record first—like priority 0 or 1. Only if that server is unreachable does it fall back to the next highest priority, such as 10 or 20. This ensures email delivery continues even if the primary server is down, as long as a backup is configured.

Real-world behavior: what happens when the primary MX fails?

Let’s say your domain has two MX records: one with priority 0 (primary) and one with priority 10 (backup). Your outbound mail server queries DNS, finds both, and immediately tries to deliver to the priority 0 server. If that server is unreachable due to downtime, network issues, or firewall rules, the sending server will wait briefly—usually 30-60 seconds—before moving on to the next option.

This is where timing matters. If the primary server is slow or unresponsive, the timeout can delay delivery. But since the backup MX is listed, the message won’t be lost. It gets routed to the next highest-priority server, so your inbox still receives it. This is the core of redundancy in email delivery.

Why priority order is critical to inbox placement

Proper MX configuration isn’t just technical—it affects deliverability. If your primary MX is unreachable, but your backup is misconfigured or lacks proper SPF/DKIM setup, the receiving server may reject the message. This increases the risk of bounces or spam filtering. Tools like bulk verification can help you catch invalid or poorly routed addresses before they send, reducing the chance of delivery failure.

Keep in mind that some mail servers don’t retry immediately. If the primary is down for hours, and the backup doesn’t have a valid sending identity, the message may be dropped or delayed indefinitely. RFC 5321 (the SMTP standard) defines the behavior of retries, but implementations vary. It’s why setting up multiple reliable MX records with correct authentication is essential.

For more on how email routing affects real-world inbox placement, look at DMARC analyzer’s guides on email authentication or the IETF’s SMTP specification. These resources explain how DNS and protocol behavior intersect to determine whether a message arrives—and where it lands.

Can you set up MX failover without risking delivery delays?

You can — if your MX records are properly prioritized and your backup server is always online, configured to accept mail, and reachable from the internet. Setting up multiple MX records with increasing priority values means mail will automatically route to the next available server if the primary fails, reducing delivery delays. The key is ensuring both servers are active and properly maintained.

How to build a resilient MX failover setup

  • Define at least two MX records: one primary (priority 0 to 5) and one secondary (priority 10 to 20) to allow automatic fallback.
  • Ensure both servers are hosted in different geographic locations or by different providers to avoid simultaneous downtime due to regional outages.
  • Test that both servers accept incoming mail by sending test messages through tools like MxToolbox or Spamhaus’s diagnostic tools.
  • Regularly verify server reachability using public domain checkers; a down server with low priority won’t be used unless the higher-priority one fails.
  • Monitor logs on both servers to confirm messages are received reliably during failover attempts, and ensure DNS TTL is low enough (e.g., 300 seconds) to allow fast rerouting if needed.
  • Avoid setting too many MX records with close priority numbers — this can create unpredictable routing and delay message delivery.

What can go wrong — and how to prevent it

Common breakdowns happen when the backup server is inactive, misconfigured, or unreachable. Even if the primary MX fails, mail won’t be delivered if the secondary is offline. It’s not enough to just set a priority — both servers must be fully functional.

Also, avoid assuming "high priority" means "instant delivery" — SMTP uses a sequence: it tries the highest-priority MX first, and only moves to the next one after a timeout. This delay can be anywhere from 30 seconds to several minutes, depending on network conditions and server responsiveness. You can reduce latency by minimizing the number of MX entries and ensuring servers are highly available.

For teams managing large email lists, validating list health and bounce rates regularly helps catch issues early. Use real-time tools to check if email addresses are valid, active, and deliverable — before they break your SMTP routing or trigger spam filters.

Verify your entire email list in bulk to detect invalid, outdated, or risky addresses. A clean list improves sender reputation and ensures your MX failover strategy works when it counts.

Why does failed SMTP routing often go unnoticed until it's too late?

Most email systems don’t alert you when a secondary MX receives mail—because it’s not technically an error. When your primary MX is down, mail still flows to the backup, but with significant delays that standard monitoring tools miss. These delays can silently degrade delivery for time-sensitive messages like order confirmations or campaign emails, eroding reliability without a single bounce or alert.

SMTP routing doesn’t fail—just slows down

When your primary MX server goes offline, DNS MX record priority steps in: mail gets routed to the next highest-priority MX. That’s the design. But this isn’t a failure—it’s normal behavior. Most systems don’t log or report this shift because receiving mail on a backup MX isn’t an error. The email isn’t lost. It’s just delayed, sometimes by minutes, hours, or more—depending on how quickly the backup server processes the queue.

Let’s say your transactional email system relies on immediate delivery. A 30-minute delay in a password reset email can cause real friction. Or a marketing send scheduled at launch time lands hours late, missing its peak engagement window. No bounce occurs. No error is reported. The system still "works"—so no one notices.

Delayed delivery is hidden by standard monitoring

Standard email monitoring tools focus on bounces, spam complaints, or deliverability scores. They don’t track delivery latencies. A message that arrives 15 minutes late is flagged as “delivered” by most systems, even though that delay might be unacceptable for your use case.

This is where real-time inbox placement testing helps. It simulates sends under actual conditions, including routing and server responsiveness. You can catch delivery bottlenecks before they affect real users. For example, inbox placement testing lets you verify how your message behaves across major inboxes before sending to a full list.

Even if your MX priority setup is correct, delays can accumulate when multiple systems are involved. The RFC 5321 specification defines how mail is routed based on priority, but not how performance should be measured across tiers. RFC 5321 governs SMTP transmission, but not monitoring. That gap is where problems go undetected.

You can detect routing issues earlier by testing your configuration with tools that simulate real-world delivery paths. The goal isn’t perfection—it’s consistent timing. If you’re not catching these delays during testing, you’re running blind.

What happens if your secondary MX is also down or misconfigured?

If your primary MX is down and your secondary MX is also unreachable or misconfigured, incoming mail will fail to deliver and be permanently bounced. This happens after SMTP servers exhaust retry attempts—typically over several hours—because no working MX record is available to accept the message. The sender receives a hard bounce, and repeated failures can hurt their sending reputation over time.

Delayed delivery and permanent failure

When the primary MX is unreachable, mail servers try the secondary according to the priority order defined in your DNS MX records. But if the secondary is also down or misconfigured, the sender’s server will eventually give up—often after 24 to 48 hours of retry attempts. This delay means emails may not arrive for a full day, which is unacceptable for time-sensitive communications.

SMTP systems follow a retry schedule defined in RFC 5321: they try again every few minutes for the first 4–6 hours, then extend intervals to several hours. After about 24–48 hours, the mail is marked as undeliverable. RFC 5321 specifies these retry behaviors, which vary by mail provider but are generally consistent across major platforms.

Reputation damage from repeated failures

Each hard bounce counts toward the sender’s reputation score. Services like Spamhaus and Microsoft’s SmartScreen track delivery failures. If your outbound mail consistently fails to reach recipients due to misconfigured MX records, your IP or domain can be flagged as unreliable, reducing inbox placement across major inboxes.

Let’s say you’re automating customer notifications, and your system relies on incoming email replies. If your secondary MX is broken, replies never arrive. That creates a feedback loop where your email sends are seen as low-quality, which worsens your standing with inbox providers.

Before sending large volumes, verify your entire email infrastructure—including MX records, SPF, and DKIM. You can spot these issues early with bulk email verification, which checks not just syntax but real-time deliverability indicators like MX reachability and server responsiveness.

How does DNS caching affect MX failover timing?

When your primary mail server goes down, DNS caching can delay MX failover for hours—even after you've updated your DNS records—because resolvers store responses based on TTL values, often for 24 hours or longer. This means clients may still try to deliver mail to a down server until the cached record expires, causing delivery delays or failures during maintenance windows.

Why DNS TTLs create delivery lag

Every DNS response includes a TTL (Time to Live) value, which tells resolvers how long to cache the record before checking again. By default, many domains set this to 86,400 seconds (24 hours). Even if you update your MX records to point to a backup server right away, the global DNS network may still be serving the old, outdated record for up to a full day.

Let’s say you do a planned maintenance window on a Monday morning. You update your DNS to reflect a new primary MX server. But because ISPs, email providers, and other resolvers have cached the old record, some mail will still be routed to the offline server. By the time caching expires, your campaign or transactional flow may already be behind schedule.

This delay isn't a flaw—it's how DNS works. The system is designed for efficiency, not real-time responsiveness. If every query required a fresh lookup, the internet would be slower. But it does mean that planned outages, especially those involving mail server changes, can have longer-than-expected delivery impact.

How to reduce cache-induced delays

While you can’t control the TTLs of external resolvers, you can plan for it. Preemptively lowering your MX record’s TTL to 300 seconds (5 minutes) a few days before maintenance ensures faster propagation when changes are made. However, doing so increases DNS load and isn’t ideal for everyday use.

You can also monitor DNS propagation using tools like MxToolbox or DNSWatch to verify that updates are being picked up in real time. Still, don’t rely solely on this; expect delivery delays during maintenance windows even with accurate records, especially if you're not using a robust fallback strategy.

If you're managing a large email list, verifying address validity before sending helps avoid delivery issues entirely. Invalid or dormant emails can still trigger timeouts and bouncebacks—especially during fragile routing conditions. You can run a bulk verification to prune bad addresses and improve inbox delivery rates.

What are the real-world consequences of poor MX configuration?

When your MX records aren’t set up with proper priority and failover logic, mail delivery becomes unreliable. Some recipients get messages; others don’t. During outages, this leads to higher bounce rates, failed delivery attempts, and long-term damage to sender reputation—especially if your email system keeps retrying invalid addresses without verification.

How bad MX configuration breaks delivery in practice

  • Messages may be delivered to some users but not others, depending on which MX server is temporarily reachable—this inconsistency frustrates users and undermines trust in your communications.
  • Without a properly configured fallback MX, email queues grow during downtime, and retry loops can trigger spam filtering or temporary blocking by recipient servers, especially when the same IP sends repeated failures.
  • Undeliverable messages increase bounce rates. A sustained bounce rate above 2% can signal poor list hygiene to ISPs and lead to your domain being flagged or blocked.
  • Repeated failed delivery attempts—especially to invalid or non-routable addresses—harm your sender reputation. ISPs like Gmail and Outlook track authentication and delivery behavior over time; poor patterns reduce inbox placement.
  • Failures aren’t just technical—they’re business-critical. Missing a crucial invoice, order confirmation, or support email can damage customer relationships, especially in time-sensitive industries like finance or e-commerce.

How to prevent these issues

Let’s be realistic: MX records are simple, but their impact is large. If the primary MX is down, mail shouldn’t stop flowing—unless your backup MX is misconfigured or not active.

Use DNS tools like MXToolbox or RFC 5321 to validate your MX hierarchy and ensure lower-priority records are correctly set. Test failover scenarios during maintenance windows.

Preventing delivery problems starts before the mail leaves your server. Clean your list regularly with a tool like bulk email verification to spot invalid, role-based, or disposable addresses that can increase bounces and hurt deliverability.

How can you test MX failover behavior reliably?

You can test MX failover by simulating SMTP routing across multiple MX records, sending test emails from different geographic locations using a dedicated test domain, and confirming both primary and secondary servers log accepted messages during outages. This approach exposes real-world routing decisions and ensures fallback systems work as designed.

Simulate real-world routing behavior

  1. Use tools like MXToolbox or Mail-Tester to analyze your MX record configuration and verify priority order. These tools inspect DNS responses and confirm correct precedence, which is foundational before testing failover.
  2. Run automated SMTP tests with multi-MX-aware tools that can simulate delivery attempts across multiple servers. These tools track whether the system correctly retries lower-priority MX entries when higher ones fail—this mimics how real mail relays behave under duress, per RFC 5321.
  3. Verify that the lowest-priority MX records are not skipped or ignored during the routing process. A misconfigured priority sequence can cause delivery to halt even when backup servers are available.

Validate behavior under realistic failure conditions

  1. Set up a temporary, dedicated domain (e.g., test.yourcompany.com) with multiple MX entries, each pointing to different mail servers. Avoid using production domains to prevent unintended impacts or false positives.
  2. Send test messages from geographically diverse sources—use cloud-based email testing services or SMTP clients hosted in regions like the US, Europe, and Asia—to observe if routing adapts to local network conditions and DNS resolution times.
  3. Check logs on both the primary and secondary mail servers during the test. If the primary server is down, the secondary must accept incoming mail. Look for SMTP response codes (like 250 OK or 4xx transient errors) to confirm behavior matches expected failover logic.
Failover is not automatic. It depends entirely on proper record configuration and server readiness. Test behavior under actual conditions, not just in theory.

Regular testing ensures you’re not relying on a theoretical fallback that never triggers. Tools like inbox placement tests can simulate real delivery paths and reveal issues like dropped mail during outages—giving you confidence in your email resilience before it matters.

How does Emaillistchecker.io help avoid deliverability issues caused by bad MX setups?

You can catch MX configuration problems before they disrupt delivery by using Emaillistchecker.io to verify your email list. It checks for valid MX records, flags domains with missing or unresponsive MX entries, and validates routing readiness in real time—preventing bounces, delays, and inbox placement issues caused by misconfigured or down primary MXs.

Bulk verification detects broken MX routing early

  • Run a bulk verification on your list via our bulk verification tool to scan thousands of addresses at once.
  • Our system checks each domain’s MX records and validates their responsiveness, identifying cases where primary MX servers are down or misconfigured.
  • Domains with expired, unreachable, or absent MX records are flagged as "invalid" or "risky" to prevent outbound sends to unreliable destinations.
  • When a primary MX is unreachable, email delivery can fail or experience delays—this is especially critical if there’s no secondary MX configured, a common gap we detect.
  • This process mirrors best practices in RFC 5321, which defines SMTP delivery behavior, including how agents should handle failed primary MX attempts and fallback routing.

Real-time API confirms delivery readiness before you send

  • Integrate our real-time verification API to validate address validity and MX configuration on every send.
  • Before adding an address to a campaign, the API checks whether the domain’s MX records are functional and properly prioritized.
  • If the primary MX is down and no backup is in place, the API returns a clear flag—so you can exclude that address or alert the sender to fix the setup.
  • By catching MX-level issues preemptively, you avoid the kind of widespread bounce rates that damage sender reputation and hurt inbox placement.
  • Test your message delivery path with our inbox placement testing to see how your email performs across major providers under real-world conditions.
Even one unresponsive MX record in a high-volume list can result in thousands of undelivered messages. Prevention beats recovery.

What role does sender reputation play when MX failover triggers delays?

When MX failover causes repeated delivery delays or bounces, sender reputation takes a hit—because systems like Return Path and Google’s SpamAssassin measure latency and failure rates over time. Even a single domain with unresolved MX issues can drag down your overall deliverability if it’s part of a high-volume campaign, especially if it's tied to key users or critical messages.

Delay is a signal, not just a glitch

Every delayed or failed SMTP delivery is recorded. When that happens repeatedly across domains, reputation engines treat it as a red flag—indicating infrastructure instability or poor list hygiene. A single misconfigured server with a down primary MX might not block all mail, but the cascading delays signal to recipients' filters that your sending behavior is inconsistent.

Let’s be clear: DNS MX records don’t just route mail—they inform reputation systems how reliably you deliver. A delay of more than 10 minutes per message is commonly flagged in industry-standard monitoring tools. Tools like MxToolbox or Spamhaus don’t track MX priority directly, but they do track the resulting delivery behavior. If a domain consistently fails to connect within window, that’s logged as an anomaly.

Reputation is cumulative, not isolated

Even if you have a healthy sender reputation elsewhere, one domain with chronic MX issues can still affect overall campaign results—especially when it’s part of a high-priority segment. Reputations are assessed holistically: Google’s Gmail and Microsoft’s Outlook use long-term patterns to decide whether to filter or delay messages, not just single failures.

For example, if your newsletter sends to 100,000 users and 1% of them are on domains with unresolved MX failover, that’s 1,000 delayed or bounced messages. Over time, that pattern gets flagged. Reputation systems track both volume and consistency—so even brief failures, if repeated, accumulate.

Proactive verification helps. You can detect invalid or unstable domains before they hurt your sender score. Bulk email verification identifies domains with failing MX configurations or catch-all setups, so you can clean your list before sending. Catch-all domains often fail delivery in subtle but harmful ways—they accept mail but never deliver it, creating silent bounces that degrade your reputation over time.

Reputation is not just about spam filters—it’s about trust. And that comes from reliable, consistent delivery. Even a delayed SMTP connection can be the first sign of deeper infrastructure problems. When primary MX servers go down, the failover process must be fast, reliable, and tracked. Otherwise, you’re not just losing a message—you’re slowly eroding the trust that keeps your emails in inboxes.

Final takeaway: DNS MX priority isn’t just technical — it’s deliverability-critical

Proper MX record priority ensures incoming mail routes to backup servers when the primary is unreachable. Without it, messages are lost or delayed during outages, undermining reliability.

But priority alone isn’t enough. Backup servers must be operational, properly configured, and accessible over the network. An MX chain is only as strong as its weakest, live link.

Tools like Emaillistchecker.io verify not just individual email addresses, but also the health of your mail infrastructure—including DNS resolution, server reachability, and configuration consistency—before issues impact real deliveries.

Sources

  • Catch-all addresses made up 9% of all emails checked in 2025 — over 1 billion addresses that can look valid but still bounce and damage sender reputation. — ZeroBounce Email List Decay Report (2025)
  • A 2025 list quality analysis found 11.7% of emails are invalid and another 7.9% are risky (spam traps, disposable addresses), meaning 19.6% of a typical list can damage sender reputation. — Apollo.io sender reputation guide (2025)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does every domain need multiple MX records for failover?

Not every domain needs multiple MX records, but having at least one backup is strongly recommended for production services.

What is the optimal priority range for secondary MX servers?

Use priority values 10–20 for secondary servers. Values too close to primary (e.g., 1 vs 2) can cause race conditions.

Can MX failover happen within seconds?

No — DNS caching delays can extend failover up to 24 hours. The process is not instant.

How do I check my MX records right now?

Use tools like MxToolbox or dig with the command `dig MX example.com` to inspect current records.

No — catch-all addresses accept mail for any user, but they don’t resolve MX routing issues during downtime.

Why does mail sometimes arrive hours late after a primary server outage?

Delays occur due to DNS TTL caching and retry intervals built into SMTP protocols.

Do all email providers respect MX priority values?

Yes — all major email providers honor MX priority settings during routing decisions.

Can a poorly configured MX affect email deliverability even if the server is online?

Yes — if the secondary server is misconfigured, it can reject mail, leading to delivery errors and reputation damage.

When should I update my MX records for a switch to a new provider?

Update records well before migration and set lower priorities on new servers to ensure smooth failover.

What’s the difference between MX priority and SMTP retry logic?

MX priority controls initial routing; SMTP retry logic manages how often a server attempts delivery if first attempts fail.

Can I use Emaillistchecker.io to verify if a domain has a healthy MX setup?

Yes — our bulk verification identifies domains with invalid or unreachable MX records, helping prevent delivery failures.

Does Emaillistchecker.io test whether a secondary MX is reachable?

Yes — our verification API checks for active, responsive mail servers listed in MX records, including secondary entries.