What happens when your primary email server goes offline?

You send an email to [email protected]. The server is down. No response. But the email still arrives. How?

It’s not magic. It’s MX record routing logic when primary server is unreachable — a built-in safety net in email delivery.

When your primary mail server goes offline due to downtime, network issues, or overload, the sending server doesn’t give up. It checks your domain’s DNS for MX records. If multiple servers are listed with different priority levels, it moves to the next available one in order.

This fallback behavior is why emails keep flowing during brief outages — but only if you’ve set up redundant servers properly.

Key takeaways

  • MX routing logic automatically retries delivery on the next-highest-priority mail server if the primary is unreachable.
  • Delivery continuity depends on having at least one secondary mail server configured with a valid MX record and correct priority ranking.
  • Even with proper MX setup, failure to maintain server availability or correct DNS configuration can cause delivery delays or bounces.

How does MX record routing logic work under normal conditions?

When you send an email, the sending server checks the recipient's domain for MX records—DNS entries that tell it which mail servers are authorized to receive messages for that domain. These records are ranked by priority: lower numbers mean higher priority. The sending server tries the highest-priority server first; if that server doesn’t respond, it moves down the list in order until it finds one that accepts the message.

Priority-Based Routing Is the Default Behavior

Each MX record has a priority number. A record with priority 10 is tried before one with priority 20. If the server at priority 10 doesn’t reply within a set timeframe, the sending server attempts the next one in line. This is standard behavior defined in RFC 5321, which governs SMTP.

This system is designed to handle temporary outages or load balancing. For example, if your primary mail server goes down during maintenance, messages are still delivered to the backup server—assuming it’s correctly configured and available.

What Happens When the Primary Server Is Unreachable?

When the highest-priority MX server doesn’t respond—due to downtime, network issues, or misconfiguration—the sending server checks the next one in the priority list. It keeps going until it finds a working server or exhausts all options, at which point it returns a permanent failure (bounce). No automatic fallback to lower-priority records occurs unless the higher ones are unresponsive.

It’s important to note that this routing logic applies only during message submission. Once a message is accepted by a server, delivery continues via the usual SMTP handshake, regardless of priority.

While this process is reliable in theory, real-world delivery failures often stem from misconfigured MX records, DNS propagation delays, or blacklisting. Even small errors can cause emails to bounce silently, especially with large lists. Before you send marketing campaigns, it’s wise to verify your email list with a tool like bulk verification to catch invalid or misrouted addresses early.

For deeper insight, you can review how DNS works at scale through tools like IANA’s list of DNS record types, which includes MX records. You can also test your own MX setup using public checkers like MxToolbox.

Which scenarios trigger MX record routing logic to activate?

MX record routing logic activates when the primary mail server fails to respond or explicitly rejects incoming mail due to a permanent issue. This includes hardware failure, maintenance, network outages, timeout during delivery attempts, 5xx SMTP errors, or firewall-based rejections. The email system then falls back to secondary MX servers based on their priority values. This process is defined in RFC 5321, the core SMTP standard.

When the primary server is unreachable

  • The primary mail server is down due to hardware failure or unplanned maintenance, preventing any incoming mail delivery.
  • Network outages cause the server to be unreachable, meaning no TCP connection can be established within the expected timeout window (typically 300 seconds).
  • The server does not respond to SMTP handshakes within the configured timeout period, triggering the mail relay to try the next MX in the list.

When the primary server rejects mail permanently

  • SMTP error codes in the 5xx range (e.g., 550, 552, 554) indicate a permanent failure, meaning the server cannot accept the message at this time.
  • Firewall rules block incoming connections, resulting in a hard rejection and triggering fallback routing.
  • Authentication restrictions (like IP blocks or strict TLS policies) cause the server to reject the connection before acceptance can occur.
  • Server overload or resource exhaustion (e.g., memory, disk space) leads to inability to process new messages, often reflected as a 5xx error.

These scenarios are common in production email systems. According to the Internet Engineering Task Force (IETF), the design of MX routing is intended to allow graceful degradation during server failures. This makes proper MX configuration a non-negotiable part of email reliability.

Still, the path to inbox delivery doesn’t stop at MX logic. You also need to ensure your sender reputation is strong and deliverability isn't blocked by blacklists or filters. Tools like bulk email verification can validate your list against real-world delivery conditions before sending.

Can MX routing logic bypass a failing server automatically?

Yes — MX routing logic can bypass a failing primary server automatically, but only if the next MX record in priority order is active and reachable. If all servers in the priority list are down or unresponsive, the sender’s mail server will eventually time out and return a permanent bounce. This means the delivery failover depends entirely on the configuration and availability of backup MX records.

How MX priorities and failover work in practice

When a mail server receives an email for a domain, it checks that domain’s MX records in order of priority — lower numbers mean higher priority. If the top-priority server doesn’t respond, the sending server moves to the next one in the list, up to three attempts per server before it gives up.

That’s why having at least one secondary MX server with a higher priority number (e.g., 10) is a standard best practice. It gives the sender a chance to deliver the message even if the main server is down for maintenance, network issues, or misconfiguration.

What happens when no MX server is reachable?

If every MX record in the list fails — due to downtime, misconfiguration, or connectivity issues — the sending server will eventually conclude that delivery is impossible and issue a hard bounce. The bounce message typically says the recipient server is unreachable or timed out. This failure is permanent, not temporary, unless the sender retries after the issue is fixed.

That’s why email deliverability relies as much on proper infrastructure as it does on sender reputation. Misconfigured or unresponsive MX records can cause even legitimate emails to fail silently.

Proactively verifying your email list ensures you’re not sending to addresses with no working MX records. Tools like bulk email verification help identify invalid domains or misrouted addresses before they hurt your deliverability.

The behavior of MX routing is defined in RFC 5321, the core SMTP specification, which outlines how mail servers should handle fallbacks. The system is designed to prioritize reliability through redundancy, but only when configured correctly.

For more on how to test whether your domain’s MX setup supports valid failover, check the inbox placement feature, which simulates delivery across real mail providers with detailed outcome reports.

What role does DNS caching play in MX record fallbacks?

DNS caching stores MX records for their assigned TTL, usually 300 seconds or more. If your primary mail server goes down and you update your MX records, cached responses may still point to the old server for up to the TTL duration. This delay means fallback routing won’t take effect immediately, even if you’ve set up secondary servers. The result: delayed delivery during failover scenarios.

How long does cached MX data stick around?

Most DNS resolvers cache MX records for the full TTL period defined by the domain’s DNS zone file. A common TTL is 300 seconds (5 minutes), but some domains set it much higher—up to 86,400 seconds (24 hours) or more. That means even if you update your MX records to route traffic to a backup server in response to a failure, some clients may still attempt delivery to the original server for hours.

Let’s say you’re running a campaign and your primary mail server becomes unreachable mid-send. If the change to your MX records isn’t widely propagated, the DNS cache can prevent new messages from reaching the backup server for as long as the TTL persists. This isn't a server-side issue—it’s systemic.

Why this matters for deliverability and failover

Delayed adoption of updated MX routing directly impacts inbox placement. If messages are routed to a non-responsive server due to outdated DNS caches, they may experience timeouts or be marked as undeliverable. This increases the rate of hard bounces and can trigger spam filters or sender reputation penalties over time.

Even if your email infrastructure is resilient, DNS caching can mask the failover. The solution isn’t just setting up backup servers—it’s also reducing TTLs for critical records ahead of time. That way, when changes are needed, fallbacks activate faster. You can’t control how long other DNS servers hold onto data, but you can prepare by configuring your DNS records with shorter TTLs when high availability is essential.

While DNS cache behavior is well-documented in RFC 1035, actual cache durations vary across networks. Resolvers on corporate or ISP networks often honor TTLs strictly, but some may cache longer for performance reasons. You can test your own DNS propagation using tools like MXToolbox to verify when changes have taken effect globally.

Proactive validation of email list health—especially during infrastructure shifts—helps ensure your messages aren’t landing in a queue based on outdated DNS data. You can check for deliverability risks in your list with a real-time email verification system: try inbox placement testing to see how your emails are received across major providers.

How do mail servers decide when to retry failed deliveries?

When a mail server can’t deliver a message, it follows an SMTP retry schedule—typically trying every 5 to 15 minutes for 5 to 7 attempts. If all attempts fail and no alternative MX server is available, the message is returned as undeliverable with a bounce. This logic ensures persistence while preventing endless retry loops.

The SMTP retry mechanism in action

After a delivery failure—whether due to server downtime, full inbox, or temporary network issues—the sending server consults the recipient’s MX records. It begins retrying based on a time delay specified in the SMTP protocol (as defined in RFC 5321), usually starting at 300 seconds and increasing on subsequent attempts (exponential backoff). Most systems complete 5 to 7 retries before giving up entirely.

Let’s say your email bounces because the recipient's mail server is down. The sending server won’t give up immediately. It waits, then tries again in 5–15 minutes—sometimes longer. This is how the internet handles intermittent outages. If the server never comes back online and no fallback MX exists, the message is returned to you with a permanent failure notice. This is what you see as a bounce.

It’s important to know that mail delivery isn't instantaneous. A 15-minute delay between retries is normal. If you’re sending campaigns and seeing delivery delays, it’s often not your fault—just the email system doing its job. The real problem arises when MX records are misconfigured, or when a catch-all server isn’t set up properly, leading to undeliverable bounces.

What happens when MX records don’t provide fallbacks?

MX records define a prioritized list of mail servers responsible for receiving email for a domain. If the primary MX server fails and there’s no secondary server, there’s no path forward. The sending server has no alternative—it must return the message as permanently undeliverable.

Most domains have at least two MX records: one primary, one backup. If only one entry exists, and it's unreachable, delivery fails regardless of retry attempts. This is why verifying your list for correct MX routing is critical. A single failed MX configuration can cause a cascade of bounces that sink sender reputation.

Using a tool like bulk email verification helps find invalid addresses early—before you send. It checks DNS, catches unreachable domains, and flags MX routing issues before they break your deliverability.

What happens when the backup MX server is also offline?

If both the primary and backup MX servers are unreachable, the sending server eventually gives up and returns a permanent hard bounce—typically a 5.0.0 error—to the originator. This means the email never reaches an inbox and is permanently rejected. The bounce can also trigger sender reputation issues, especially in large-scale campaigns, because repeated hard bounces signal poor list quality or unreliable infrastructure.

Permanent bounces and sender reputation

When a sending server receives a 5.0.0 or similar permanent error, it marks the recipient address as undeliverable. If this happens across thousands of addresses in a list, it impacts your sender reputation. ISPs and email providers track these failures in reputation systems—over time, this can lead to filtering or outright blocking of your messages.

It’s not just about one failed delivery. The ripple effect can hurt future emails sent to other recipients, even if they’re valid. For example, if your sending domain is repeatedly associated with high hard bounce rates, it may be flagged as a potential spam source, even from clean messages.

Preventing failure cascades

Let’s be honest—no one wants to be the sender blamed for missed communication. Most email delivery failures come from outdated or invalid addresses. But when both MX servers are down, it’s not just about the address—it’s about infrastructure reliability. That’s why proactive list hygiene matters.

Before you send, verify every email on your list. Tools like bulk email verification can catch invalid addresses before they cause bounces, and they also flag potential issues with domain routing, including malformed MX records or known blacklisted domains.

It’s equally important to monitor your own MX server health. Regular checks via tools like MXToolbox or RFC 5321, Section 5.4 (which defines SMTP delivery behavior) help you catch outages before users notice. If you’re managing your own mail server, automated monitoring reduces downtime risk.

While you can’t control every part of the delivery chain, you can manage your end. Cleaning your list, validating domains, and checking server status regularly reduce the chance of cascading failures. That’s not just good email hygiene—it’s smart, sustainable sending.

Can email verification tools detect unreachable MX servers?

Yes — email verification tools like Emaillistchecker.io don’t just check if an email looks valid; they test whether the domain’s MX records actually route to a server that’s online and accepting connections. If the mail server is down, overloaded, or misconfigured, the tool flags the address as invalid or risky, preventing wasted sends and protect your sender reputation.

How verification tools test MX reachability

When you verify an email, the system performs a real, low-level check: it attempts to connect to the domain’s MX servers using standard SMTP protocols. It doesn’t stop at DNS resolution. It actually tries to handshake with the server and waits for a valid SMTP response — like "220" for greeting — to confirm it’s reachable and capable of receiving mail.

If no server responds, or the response is non-standard (e.g., a timeout or connection reset), the tool treats the address as undeliverable. This isn’t guesswork. It’s a direct test of what the mail transport layer experiences.

What happens when MX routing fails

If a domain’s MX record points to a server that’s offline, misconfigured, or behind a firewall that blocks external SMTP traffic, the email will never reach its intended destination. Tools that skip this step risk calling an address “valid” while it’s just a ghost — an empty mailbox that absorbs no mail.

That’s why Emaillistchecker.io includes real-time server testing as part of its core process. You’re not just seeing syntax. You're seeing whether the destination is actually listening.

For example, a catch-all mailbox may accept any email, but only if the server is up. If it’s unreachable, even a catch-all fails. Tools like ours detect that failure early — so you don’t end up with a high bounce rate or blocked senders.

Learn how this works in practice with our bulk verification tool, which checks thousands of emails simultaneously and returns results with granular verdicts — including "unreachable MX", "invalid domain", or "risky" — so you know exactly what’s failing and why.

SMTP RFC 5321 defines the protocol-level tests that reliable tools follow, which is why our verification process aligns with industry standards. It’s not about theory — it’s about delivering mail to real inboxes, not servers that just don’t respond.

How does Emaillistchecker.io help prevent delivery failures from unreachable MX records?

Our real-time verification API checks if a domain’s MX server is reachable and responsive before you send. It identifies and removes email addresses tied to unreachable or hard-failing MX records, so your campaigns don’t hit bounces due to non-operational mail servers. This cuts delivery failures at the source, improving inbox placement and sender reputation.

What happens during MX record routing when the primary server is unreachable?

When the primary MX server is unreachable, mail servers follow the MX record priority list and try the next available server. But if all servers fail, the message is rejected with a permanent error — a hard bounce. These failures hurt deliverability and signal poor list hygiene to providers like Gmail and Outlook.

Let’s be clear: a valid email format doesn’t mean the server will accept mail. A domain might pass basic syntax checks, but if its MX record points to an offline server, delivery fails. That’s why domain-level reachability testing is critical.

How Emaillistchecker.io stops failures before they happen

Our verification process goes beyond syntax. It checks the underlying MX record routing logic by reaching out to the actual mail server. If the server is unreachable or returns a hard failure, we flag the address as invalid. This happens in real time and applies to every email in your bulk list.

With 98.9% accuracy, Emaillistchecker.io ensures only domains with operational mail servers remain in your list. This means fewer bounces, lower risk of being flagged for spam, and stronger sender reputation — which directly impacts inbox placement.

Our real-time API integrates directly into your workflow, so you catch issues before sending. You can verify lists of any size, from small campaigns to enterprise-scale sends, using a simple API call at https://www.emaillistchecker.io/api.

Deliverability is not just about content or headers. It starts with whether the destination server exists and accepts mail. You’re not just validating email addresses — you’re validating the infrastructure behind them.

As the RFC 5321 standard outlines, proper SMTP handshake procedures depend on server responsiveness. Tools that skip server reachability testing miss a critical step in the validation chain.

For teams managing high-volume sends, this level of pre-verification reduces wasted sends, maintains list health, and prevents the slow degradation of sender reputation that comes from repeated hard bounces.

What should you do when an MX record points to an unreachable server?

If an MX record routes mail to a server that’s down, your emails won’t deliver. First, confirm the MX record is correct using tools like MxToolbox or dig. Then, ensure your backup mail servers are online, accepting connections, and properly configured. If you're on Gmail or Microsoft 365, verify your DNS settings match the service’s requirements. Finally, scan your email list with a bulk verification tool to catch domains with invalid or unreachable MX records before you send.

Diagnose the root issue

  1. Check your MX records with a public DNS tool. Use MxToolbox or the command-line dig to confirm current MX entries. Misconfigured or outdated records are a common reason for routing failures. A record may point to a server that no longer exists, or worse — it might be blocked by firewall rules.
  2. Verify backup mail servers are active. MX records can list multiple servers with different priority levels. If the primary server is unreachable, mail should fall back to the next-highest priority server. Confirm these backups are online, have open inbound ports, and are configured to accept mail for your domain. Many systems fail here because the backup is misconfigured or not properly registered.
  3. Validate cloud provider settings. If you're using Gmail, Microsoft 365, or another service, ensure your domain’s DNS records match the provider’s documented setup. A mismatch—like using the wrong SPF or MX records—will break routing even if the servers are online. Providers often update their infrastructure, so always cross-check your configuration against your service’s latest guidance.
  4. Filter invalid domains from your list. Even if your own infrastructure is sound, sending to domains with unreachable MX records wastes bandwidth, harms your sender reputation, and increases bounce rates. Use a bulk verification tool to identify and remove those domains. Bulk email verification helps isolate risky domains before you send—cutting delivery failures and improving deliverability.

Prevention and maintenance

Regular checks are critical. MX records can change unexpectedly due to migrations, outages, or configuration errors. Schedule routine audits using DNS tools or monitoring services. When you do send bulk mail, validate the list first—not just for syntax, but for real-time deliverability readiness. A single unreachable server can derail an entire campaign.

Why does MX routing logic matter for deliverability?

When the primary mail server is unreachable, MX routing logic determines whether email retries reach a working backup. Failure to do so increases hard bounce rates, directly harming sender reputation.

Consistent delivery failures—especially from unverified or invalid destinations—can trigger blocklisting or throttling by inbox providers. These signals reflect poorly on the sender domain and reduce inbox placement over time.

Validating MX record reachability and server health before sending prevents wasted sends and maintains domain hygiene. This proactive step ensures only deliverable traffic reaches the mail stream.

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

What is an MX record?

An MX record is a DNS entry that defines which mail server is responsible for accepting email on behalf of a domain.

How many MX records should a domain have?

At least two — one primary and one backup — to ensure delivery continuity during outages.

What happens if no MX record exists for a domain?

Emails to that domain will fail to deliver, as the sender has no destination to route to.

Can MX records be used for load balancing?

Not directly — MX records support failover, not load balancing. Multiple servers must be ranked, and delivery flows sequentially by priority.

How long does it take for MX routing changes to take effect?

It depends on DNS TTL settings, typically 300 seconds to several hours, depending on the cache.

Does Emaillistchecker.io check MX records?

Yes — it validates the reachability of MX servers as part of email verification, flagging domains with unreachable or non-responsive mail servers.

What does a 'risky' verdict mean in email verification?

A risky verdict indicates the domain’s MX record is reachable but may have delivery issues such as greylisting, throttling, or high bounce rates.

Can I test inbox placement with Emaillistchecker.io?

Yes — the service includes inbox-placement testing to assess whether emails land in inboxes, not spam folders.

Regularly — ideally before each major send. Use real-time verification to catch changes in MX availability or server health.

Are disposable email domains a concern for MX routing?

Yes — disposable domains often have no stable MX records or lack active mail servers, resulting in immediate bounce failures.

Do MX records affect sender reputation?

Indirectly — high bounce rates due to unreachable MX servers can harm sender reputation and lead to filtering.

Can an email be sent to a domain with no MX record?

No — without a valid MX record, the sending server has no address to deliver the email to, and the message will be bounced.