What Happens When the Primary MX Record Fails?

You send an email. It goes out. Then, silence. No bounce, no error, just no delivery. You check your inbox and realize the message never made it. Behind the scenes, that’s often because the primary MX server failed—and the backup didn’t step in.

Email servers don’t guess where to deliver messages. They follow DNS records, and when the top-priority MX record is unreachable, they move down the list. The next MX in line takes over—but only if it’s online, configured correctly, and ready to receive. This is how email routing survives outages.

But here’s the catch: if the backup MX is misconfigured, offline, or doesn’t accept incoming mail, your message still fails. That’s why knowing how email servers determine the next MX record when primary fails isn’t theory—it’s essential for reliable delivery.

Key takeaways

  • When the primary MX record is unreachable, email servers consult the next MX record in the priority list to deliver mail.
  • Failover works only if the backup MX server is properly configured, accepting inbound mail, and actively available.
  • Monitoring and validating both primary and backup MX records prevents delivery failures during outages or misconfigurations.

How Are MX Records Prioritized?

When your primary mail server is unreachable, email servers follow the priority order in your MX records—lower numbers mean higher priority. A record with priority 10 is tried before one with priority 30. If the first server is down, delivery automatically attempts the next highest-priority server in line. Multiple servers can share the same priority, in which case one is selected at random to balance load.

Understanding MX Priority Numbers

MX records aren't just a list of servers—they include a priority number that tells sending servers which one to try first. The number isn’t a score or weight; it’s a strict ordering rule. A lower number equals higher preference. So, if you have two MX records—one at priority 10 and one at 30—the sender will always try 10 first. This is defined in RFC 1035, the foundational specification for DNS, which governs how email routing works.

Let’s say your primary mail server goes offline due to maintenance or a network outage. The sending server checks your MX records, sees the priority 10 server is unreachable, and moves on to the next available record—like the one with priority 30. This continues until delivery succeeds or the sender gives up after a timeout. Without this system, email could be lost during temporary downtime.

Load Balancing with Equal Priority

It's common to assign the same priority value to multiple servers. For example, two backup servers both with priority 30. In this case, the sending server doesn't follow a fixed order—it picks one at random. This is a standard way to distribute inbound email traffic evenly across redundant servers, reducing load on any single machine.

While this helps with performance, it also means you’re not guaranteed delivery to the same server every time. If one of these backups is misconfigured or fails silently, it can lead to inconsistent delivery behavior. That’s why it’s critical to monitor your full MX setup—not just your primary server. Tools like Emaillistchecker.io’s inbox placement testing help you verify that your email infrastructure behaves as expected under real-world conditions: test actual inbox delivery paths, including MX-based routing.

Remember: MX priority is just one piece of the puzzle. Even if your servers are correctly prioritized, email still depends on SPF, DKIM, and DMARC. A misaligned record can cause rejection regardless of priority. Ensuring your entire setup works together is key to reliable delivery.

How Do Servers Know the Primary Is Unavailable?

When a primary mail exchange (MX) server doesn’t respond within a standard timeout window—typically 10 to 30 seconds—the sending server assumes it's unreachable. It then checks the next MX record in the list, following RFC 5321 guidelines. If retries fail, it moves forward, ensuring delivery isn't blocked by a single down server.

The Timed Connection Attempt

You’re not guessing if the primary server is down—you’re measuring. SMTP connections start with a handshake. If the primary MX doesn’t respond within the time window, the connection is abandoned.

This timeout is often set between 10 and 30 seconds, depending on the sender’s configuration. If no response comes, the server logs a failure and proceeds.

RFC 5321 specifies that the sending server must allow enough time for a response, but it doesn’t define a universal duration. This means real-world behavior varies slightly by mail system.

  1. Initiate SMTP handshake with the highest-priority MX record (usually the primary).
  2. Wait up to 10–30 seconds for a successful connection. If nothing happens, the connection is deemed dead.
  3. Retry locally configured number of times—commonly 1 to 3 attempts—before moving to the next MX.
  4. Move to the next MX in the list by priority, if the current one fails to respond.
  5. Continue sequentially down the list, attempting each MX in order until delivery succeeds or all records fail.

Why Policy Matters

Not all servers retry the same number of times. Some systems allow up to three retries; others may only try once before giving up. These rules are set by local mail admin policies.

Some setups also delay retries by a few seconds to avoid overwhelming a failing system. This is common in high-volume sending environments.

Server-side behavior can vary between providers—some are more aggressive in retrying, others more conservative. The key is that the system doesn’t wait indefinitely; it acts based on time and failure patterns.

Let’s say you’re sending a newsletter and your primary MX goes down. If the receiving server doesn’t retry or times out too fast, your message might be discarded. That’s why maintaining a healthy, tested email list matters—from the sending side, but also from the recipient’s server perspective.

With bulk verification, you can identify invalid, catch-all, or unreachable addresses before sending. That way, your messages avoid hitting dead MX records to begin with.

Why Does the Secondary MX Matter?

If your primary mail server is temporarily unreachable, the secondary MX record acts as a safety net—accepting email and holding it until your primary comes back online. Without one, even a brief downtime can result in failed delivery, lost messages, and damaged sender reputation. Let’s break down why this fallback mechanism isn’t optional.

Mail Servers Don’t Wait Forever

Most sending mail servers follow a simple rule: if the primary MX is unreachable, they’ll try the secondary record once. If that fails too, the message is rejected with a permanent error—no retries. According to widely adopted email delivery standards in RFC 5321, delivery attempts are limited, and retry logic depends heavily on the receiving system’s configuration. Some servers do retry at a later time, but many don’t—especially during high-volume periods.

That means if your secondary MX isn’t set up or configured correctly, just a few minutes of server maintenance or network hiccups can lead to undelivered emails. For businesses relying on transactional messages—password resets, order confirmations, or onboarding alerts—this isn’t just annoying. It’s a direct hit to customer experience and trust.

Failover Isn’t Automatic—It’s Configured

There’s no magic in the DNS system. The secondary MX only works if it’s actually listening and ready to receive. Some companies assume that because they have a backup mail server in place, it’ll automatically pick up the slack. But the network stack depends on proper MX record prioritization and server availability.

And no, you don’t need a full duplicate setup. A secondary MX doesn’t need to process every message instantly—it just needs to accept and queue inbound mail until the primary is responsive. Some systems even store the message for days, depending on retry policies. That’s why having a secondary MX with a proper queue and retention policy is essential—especially for high-priority emails.

If you’re running a send-heavy campaign or managing a critical notification system, you shouldn’t be guessing whether your MX fallback is active. Use a tool like bulk email verification to audit your entire list and detect invalid or misrouted domains before they cause delivery issues. A single malformed MX record can disrupt delivery for dozens of recipients.

What If All MX Records Are Down?

If no MX records respond or if no valid MX records exist, the email server cannot route the message and returns a permanent failure—typically a 5xx SMTP error. This results in a hard bounce, meaning the message will never be delivered. For bulk senders, repeated failures like this raise bounce rates, hurt sender reputation, and increase the risk of being blocked by receiving providers.

Failure Chains: How Bounces Happen

When the primary MX record is unreachable, the sending server tries the next one in the priority list. But if every MX record fails to respond—because the domain has no records, the DNS is misconfigured, or the target mail server is down—there's no path for delivery. The sending server logs this as a permanent failure and generates a bounce message. This isn’t a temporary glitch; it’s a fundamental routing issue.

These hard bounces are often tagged with codes like 550 (no such user), 551 (user unknown), or 554 (rejected, no valid MX). Most reputable email providers treat repeated hard bounces as a red flag. If too many of your messages fail this way, your sending domain may get flagged or blocked entirely.

Prioritizing List Hygiene to Avoid This

Imagine sending to 10,000 addresses and getting 1,200 hard bounces because the domains are inactive or misconfigured. That’s not just wasted effort—it’s dangerous. High bounce rates are one of the top signals that a sender is untrustworthy, especially from a reputation standpoint.

Let’s be blunt: if you’re sending to invalid email addresses at scale, you’re not just wasting bandwidth—you’re risking your ability to reach anyone. The fix isn’t just better content or timing. It’s cleaner lists.

That’s where tools like bulk email verification come in. Instead of guessing, you can test entire lists for validity before sending—catching expired domains, non-existent users, and malformed addresses. This reduces hard bounces, protects your sender reputation, and keeps your messages in inboxes. Even with the best systems, some errors happen. But consistent hygiene makes those rare failures manageable.

How Can You Test Your MX Failover Setup?

You can test your MX failover setup by validating your DNS records with tools like MxToolbox or Dig, temporarily disabling your primary mail server to see if email routes to the secondary MX, and confirming delivery via real email clients or inbox placement tools during the outage simulation. This confirms your failover process works in practice, not just in theory.

Verify Your DNS Configuration First

Start by confirming your MX records are properly set in DNS with the correct priority order. Use tools like MxToolbox or the command-line dig tool to query your domain’s MX records. Check that the secondary server has a higher priority number (lower numeric value) than the primary, as email clients rely on this sequence to route mail.

For example, if your primary MX is listed with priority 10 and your secondary with priority 20, the mail server should fall back to the secondary when the primary is unreachable. A misconfigured priority order can cause delivery failures during outages.

  1. Run an MX lookup using MxToolbox or dig from the command line. Copy the output to verify both servers appear and the priorities are correct. This is a baseline check before simulating downtime.
  2. Temporarily disable your primary mail server. This can be done by stopping the mail service, blocking outbound connections, or temporarily adjusting firewall rules. Don’t do this during business hours unless you’re in a test environment.
  3. Send test emails to your domain from external accounts. Use a personal Gmail or Outlook account. If the emails arrive, your failover is working. If not, check your secondary MX’s mail logs for rejection reasons such as missing SPF, DKIM, or authentication failures.
  4. Use inbox placement testing tools to validate delivery. Services like inbox placement testing simulate real-world delivery and check if messages land in inboxes, spam folders, or are blocked entirely. This reveals issues that a simple connectivity test might miss.

Real-World Testing Matters

Testing with actual email clients or inbox placement tools shows whether failover works under real conditions. Email servers don’t just follow DNS records — they also evaluate sender reputation, blacklist status, and connection behavior. The secondary server must be ready to accept messages, authenticate properly, and avoid being flagged as a source of spam.

For example, if your secondary MX lacks proper SPF or DKIM alignment, even if email reaches it, it may be rejected or marked as spam. Use RFC 5321 (SMTP) and RFC 5322 (message format) as reference standards for how mail delivery is expected to behave during failure scenarios.

Once you confirm the failover works, re-enable your primary server and retest to ensure no residual misconfiguration remains. Regular testing — at least quarterly — ensures your email infrastructure stays resilient under pressure.

How Does This Affect Email Deliverability Testing?

If your email server’s MX failover chain is broken or inconsistent, messages may bounce during outages—even brief ones—hurting deliverability. Testing routes and failover behavior ahead of time helps catch routing flaws before they hurt campaign performance. Without it, you’re sending blind, risking lost messages and damaged sender reputation.

Why Failover Matters in Real-World Sending

When a primary mail server goes down, email systems look to the next MX record in priority order. If that secondary server is unreachable, slow, or misconfigured, the message can bounce or get delayed indefinitely. This isn’t rare—outages happen, even for well-managed domains. The difference between success and failure often comes down to how well the backup is set up and monitored.

Organizations without robust failover see measurable drops in inbox placement. A message that should arrive in a user’s inbox might instead be rejected or delayed by hours or days. That delays engagement and harms metrics like open rates and click-throughs—especially on time-sensitive campaigns.

Testing Routes Before You Send

Deliverability testing reveals whether your MX chain behaves as expected under real-world conditions. Tools like inbox placement tests simulate sending from a real IP to monitor how your message moves through the internet—and whether it hits the inbox or gets blocked, quarantined, or lost entirely.

Let’s say your backup MX is misconfigured. You might not notice until your campaign fails to deliver to thousands of subscribers. Testing helps find that before the first send. You can verify routing order, check DNS responses, and confirm your backups are responsive. It’s not just about the primary server—it’s the full chain.

For those relying on third-party platforms like Mailchimp or HubSpot, integrating a verification tool like our API lets you test addresses and validate routing patterns in real time. That includes checking if domains with multiple MX records behave predictably during failover situations.

Even if a domain claims a backup MX exists, that record may not resolve properly or may be unreachable. Tools like bulk verification can spot these gaps, helping you clean your list and reduce the risk of delivery issues linked to poor DNS configuration.

Ultimately, it’s not enough to have a backup. You need to know it works. That’s what deliverability testing is designed to prove.

What Role Does Email Verification Play in This Process?

When a primary MX record fails, email servers fall back to secondary MX records only if the domain’s mail routing is properly configured and the target address is valid. Email verification prevents you from sending to invalid or misconfigured domains in the first place—reducing hard bounces and protecting sender reputation. Tools like Emaillistchecker.io catch invalid addresses, catch-alls, and role accounts before they cause delivery failures.

Stopping Delivery to Non-Responsive Domains

If an email address points to a domain with no MX records or one that doesn’t respond, the server returns a hard bounce. You don’t want to waste bandwidth and harm your sender reputation chasing dead ends. Email verification filters these out early by checking real-time DNS records like MX and SPF—ensuring only domains with active mail configurations are targeted.

Let’s say you’re sending a campaign and a few thousand addresses point to outdated domains. Without verification, those messages will bounce, potentially triggering spam filters or blacklisting. With validation, those invalid entries are flagged before you send. This isn’t just about reducing bounces—it’s about building a reliable sending reputation, which directly affects whether your messages land in the inbox or are buried in junk.

Why Accuracy Matters in Real-World Delivery

Not all validation tools are equal. Some only check syntax or common disposable domains. Emaillistchecker.io’s 98.9% accuracy comes from deep validation: it checks MX records, validates SMTP responses, and detects catch-all setups that might appear "valid" but can’t receive messages meaningfully.

For example, a role account like [email protected] may return a "valid" status in some tools but will often not receive messages unless they’re explicitly routed. Emaillistchecker.io flags these as "risky" or "role-based," cutting down on silent failures. This level of precision matters—if your email tool only checks format, you might still send to addresses that silently fail.

A properly configured mail system relies on accurate DNS infrastructure. If the MX records can’t be resolved, or the domain doesn’t accept mail, the fallback process never matters. The best defense isn’t waiting for a secondary MX to kick in—it’s never sending to domains that don’t deliver.

For reliable bulk checks, see how bulk verification works in practice. It validates thousands in minutes, giving you a clean, deliverable list before you send.

How List Hygiene Improves MX-Based Deliverability

When your primary MX record fails, email servers try the next MX in priority order. A clean list ensures only valid, properly routed addresses are sent—reducing the risk that messages get stuck on fallback routes due to missing or misconfigured DNS records. You avoid wasted attempts on unreachable servers and keep your deliverability high.

Eliminate Invalid DNS and Unreachable Servers

Bad email addresses often lack working MX records or have servers that don't respond. You can't deliver to them, and the failed delivery attempts still count against your sending reputation. Cleaning your list with bulk verification catches these early—before you send. It’s like removing dead ends from a delivery route.

Using tools like bulk email verification identifies these addresses automatically. You’ll see results flagged as "no MX record," "server unreachable," or "timeout." Removing them before sending means your outbound mail reaches only addresses that can actually receive it.

Reduce Risk from Catch-Alls and Role Accounts

Catch-all email setups accept messages for any address on the domain—even invalid ones—then often route or discard them silently. That creates a poor user experience and spikes bounce rates. If multiple emails land in a catch-all but don’t get read, ISPs may interpret that as spam behavior.

Role accounts like admin@, support@, or sales@ aren’t usually monitored. Sending to these risks low engagement and can hurt your sender reputation. Tools that assess email type can flag these, so you can filter them out. According to RFC 5321 (the core email spec), such addresses should not be used for transactional or promotional delivery.

Even a few role accounts in a large list can cause problems. They generate soft bounces or high delivery failure rates. Using real-time API verification helps catch these issues dynamically as you grow your list—without waiting for delivery failures.

Support the Entire MX Chain, Not Just the First Hop

When primary MX servers fail, mail flows to backup servers. But if your list has many bad or unreachable addresses, you’re increasing load on those backup systems unnecessarily. This can affect your sender reputation over time.

Good list hygiene improves your overall sender profile. By sending only to addresses with working infrastructure, you reduce the chances of being flagged for high bounce, timeout, or non-responsive behavior. This consistency helps ISPs trust your domain and increases inbox placement rates. Keep your list clean—it isn’t just about preventing bounces. It’s about keeping your routing efficient and your reputation intact.

The Real-World Impact of Misconfigured MX Records

When your primary MX server is down, email servers don’t just wait — they try the next MX record in your priority list. But if that backup has no storage, no retry logic, or is misconfigured, messages get lost during outages. This isn’t rare: many systems fail silently, leading to delivery gaps that can go unnoticed for days. You might think your setup is resilient, but a poorly set up secondary MX doesn’t just delay messages — it can erase them. Let’s see how this breaks in practice.

Backup MX Servers That Don’t Actually Backup

Here’s the problem: you set up a backup MX, but it doesn’t store mail. When the primary server is unreachable, mail delivery fails outright. The sending server tries the next MX, but if it doesn’t accept or queue the message, the email is tossed. This happens even during brief outages. You might assume redundancy means reliability, but a backup that can’t receive mail? It’s not a backup at all.

According to the RFC 5321 standard, an MX record list defines a sequence of servers to try. But the protocol says nothing about what a server should do if it can’t process the message — only that it should try the next one. That’s where misconfiguration sneaks in: when no server in the chain has the ability to hold or retry delivery, even a 5-minute outage causes messages to disappear.

When Synchronization Is Required (But Not Enforced)

Some domains use two MX records that are supposed to handle email, but fail unless both are properly synchronized. If your primary and secondary MXes aren’t both accepting mail and sharing a common queue, the second MX may just reject the message with “no such user” or “550” — even if the domain is valid. This creates a false sense of resilience: you have multiple MX records, but the system isn’t resilient at all.

Imagine your team sends a time-sensitive email to [email protected]. Primary MX down. Server tries the next MX. It says “we don’t hold mail, and we can’t process it.” The sender gets a bounce. You didn’t lose data — you lost the message entirely. This isn’t just an edge case. It happens in real systems daily.

It’s not just about server availability — it’s about configuration logic. If you’re sending transactional or marketing emails at scale, even a 1% failure rate due to misconfigured MX chains can mean thousands of missed deliveries. You can use tools to check your MX record health, but they won’t catch every flaw. The best way to prevent this is to verify your entire sending infrastructure — including your domain’s MX setup — before launch or after major changes. For example, bulk email verification includes MX validation to catch issues before you send. That’s how you avoid sending a campaign only to find it never arrived.

Keep Your Email Infrastructure Resilient

When your primary MX record is unreachable, email servers rely on the next MX record in your DNS configuration. A misordered or untested MX setup can cause delivery failures, even if your infrastructure is otherwise sound.

Ensure Your MX Records Are Properly Ordered and Verified

MX records must be prioritized with the most reliable server first. Use tools like Emaillistchecker.io to test your DNS configuration and validate the reachability of each MX record in your list.

Monitor Server Health and Response Times

Even the best MX setup fails if servers go offline or become unresponsive. Regular monitoring of uptime, latency, and connection health ensures your secondary MX records are ready to take over when needed.

Before every send, remove invalid, risky, or catch-all addresses. Clean lists reduce bounce rates, protect sender reputation, and maintain inbox placement. Verify using a proven service.

Keep reading

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

Frequently asked questions

What happens if the primary and secondary MX records are both down?

The email is rejected with a permanent failure. No further attempts are made unless the sender’s system is configured to retry via a third backup—most do not.

Can MX records have the same priority?

Yes. Servers with the same priority are chosen at random, which helps distribute load across multiple servers when one is temporarily unreachable.

Does a higher MX priority always mean better delivery?

No. Priority only dictates the order of attempt. A higher-priority server is tried first, but delivery success depends on availability, not priority alone.

How long does it take for a server to switch to a backup MX?

Typically 10 to 30 seconds, depending on SMTP timeout settings. If no response is received by then, the server proceeds to the next MX in the list.

Can a catch-all email address affect MX routing?

Yes. Catch-all addresses may accept all emails, including those to invalid addresses. This can mask delivery issues and reduce accountability in routing failures.

How do spam filters interact with MX record failures?

Spam filters treat repeated delivery attempts to unavailable MX servers as a sign of poor sender hygiene, potentially lowering sender reputation and increasing spam risk.

What is a 'greylisted' MX record?

Greylisting is a temporary rejection mechanism. The sender is told to retry later. If the server is valid but the MX record is slow, it may delay delivery—making MX reliability essential.

Can reverse DNS affect MX server selection?

Reverse DNS is not used to select MX records, but it can impact sender reputation. Poorly configured reverse DNS may trigger filters even if MX routing works.

Is it safe to rely solely on a single MX record?

No. Single-point failures cause delivery loss during outages. A secondary MX with proper failover is required for reliable delivery.

How often should I test my MX failover?

Test at least quarterly, or after any DNS or server change. Use delivery testing tools before sending to live campaigns.

What tools can verify MX configurations and routing?

Use DNS lookup tools like MxToolbox or Dig. For end-to-end testing, use inbox placement or deliverability testing tools like Emaillistchecker.io.

Does Emaillistchecker.io validate MX records as part of verification?

Yes. It checks whether an email domain has a valid MX record and routes correctly, helping identify domains with failed or misconfigured mail routing.