MX Record Unreachable: What Happens?

What happens when your primary MX record becomes unreachable?

You’re sending an email to a client—critical, time-sensitive, scheduled. But it never arrives. No bounce, no notification. Just silence. What if the problem wasn’t the content, the list, or even the mail server? What if the issue was a single, hidden configuration your system trusts completely?

When your primary MX record points to a server that’s offline, unreachable, or misconfigured, delivery fails immediately. The receiving mail server checks the MX record, tries to connect once, and starts a retry cycle. If no working MX is found after three days, the message is permanently rejected—no second chances.

These rejections often come as hard bounces. That’s bad for your sender reputation. Repeated bounces, even from unverified or invalid addresses, can trigger spam filters and damage long-term deliverability.

Key takeaways

MX record unreachability causes immediate delivery failure, with no automatic fallback to backup mail servers.
Mail servers retry delivery for up to 72 hours using a standardized backoff schedule, but fail permanently if no valid MX is found.
Hard bounces from unreachable MX records degrade sender reputation and can lead to inbox placement issues over time.

Why the primary MX record matters more than you think

If your primary MX record is unreachable, incoming email doesn’t just delay—it can vanish. Even a few minutes of downtime means messages aren’t delivered, leading to missed leads, failed sign-ups, or broken transactional flows. Unlike backups, MX records don’t auto-fail over; the system waits for the primary to respond. If it doesn’t, the message is lost.

The primary MX is the default path, not a fallback

When mail is sent, the sending server checks DNS for your domain’s MX records. It always starts with the one ranked highest—your primary MX. It’s not redundant; it’s the first and only stop. If that server is offline, the email doesn’t move to the next MX record automatically. The delivery process stalls.

Many businesses assume mail will “fall back” if the main server is down. That’s not how it works. The sending server doesn’t retry other MX records unless instructed to. That’s why a short outage during business hours can cost you more than you realize—especially if it’s a transactional email like a password reset or order confirmation.

Even minutes matter in email delivery

SMTP delivery attempts typically wait 30 seconds to a minute before deciding a server is unreachable. After that, the message is often rejected, not queued. If your primary MX is down for even 5 minutes during a high-volume period, hundreds of emails can bounce without warning.

For example, if your CRM relies on inbound support emails and the primary MX goes dark during peak hours, those messages won’t arrive. They’ll bounce back with a 5xx error, likely marking your domain as problematic. Repeated outages like this impact sender reputation with major providers like Gmail and Outlook. According to guidelines from the Internet Engineering Task Force, consistent delivery failures trigger anti-abuse filters, increasing the risk of being blocked entirely.

You can’t fully control third-party mail servers, but you can verify you have a working, reachable primary MX. Use tools that check MX health in real time. Bulk email verification helps you check if inbound mail routes are properly configured and whether your MX records point to active infrastructure—before the outage hits.

How mail servers handle unreachable MX records

If the primary MX record for a domain is unreachable, the sending mail server will attempt to deliver to the next highest-priority MX in the DNS record list. If all MX servers fail to respond after retries, the message returns with a permanent 5xx SMTP error—meaning it won't be delivered and will bounce. This can happen due to misconfiguration, downtime, or network issues, and it directly impacts email deliverability.

The Delivery Retry Process

Check MX records in priority order. When a server receives an email, it looks up the recipient’s domain in DNS to find MX records, sorted by priority number (lower is higher priority).
Attempt delivery to the highest-priority MX. The sending server tries to connect to the top MX. If it doesn’t respond within 30–60 seconds, it assumes the server is unreachable and moves to the next one.
Retry on lower-priority MXes. The server repeats the attempt on each subsequent MX in order. If any one responds, delivery continues. If none do, the process fails.
Generate a permanent bounce. After exhausting all MX options, the sender’s server sends a 5xx SMTP error (like 550 or 554) back to the original sender, marking the delivery as failed.

According to RFC 5321, the SMTP protocol defines this process explicitly: if no MX responds after multiple attempts, the email must be rejected permanently. This is why having a properly configured and reachable MX is non-negotiable for reliable email delivery.

The 4 steps described in “The Delivery Retry Process”, in order.

What This Means for Your Email List

A single unreachable MX can break delivery for an entire domain—if your list includes addresses from that domain, they’ll bounce. This also affects your sender reputation. Sending to invalid or unreachable domains increases your bounce rate, which email providers track to assess credibility. High bounce rates correlate with spam filters.

That’s why catching unreachable domains before sending matters. You can’t rely on email providers to fix your delivery issues. Let’s be clear: once an email fails due to an unreachable MX, it’s gone for good. There’s no fallback.

Use real-time verification to catch invalid MX records early. Test your entire list for deliverability risks—like unreachable MXes, disposable domains, or catch-all setups—before you send. It’s a proactive step that prevents bounces and protects your sender reputation.

For more details on domain-specific issues, refer to RFC 5321 (SMTP), which defines the protocol-level rules, or check domain health using tools like MxToolbox.

The technical reality of MX failover: There is none

If your primary MX record becomes unreachable, no automatic switch occurs. Sending servers attempt delivery to the primary MX first, and if it doesn’t respond, most don’t retry with a secondary—meaning emails may be delayed indefinitely or fail outright. There is no built-in failover mechanism in DNS MX records.

How MX records actually work in practice

Unlike load balancers or cloud services that monitor health and reroute traffic automatically, MX records are static. A sending server looks up the domain’s MX records, sorts them by priority, and begins with the lowest-numbered one. That’s it—no retry logic built into the protocol.

It’s true that multiple MX records can be listed, sometimes with different priorities. But the secondary only comes into play if the sending server explicitly retries or if the sender’s mail system is programmed to do so. This behavior is not mandated by any standard.

Why retries are rare and delivery breaks

The RFC 5321 specification for SMTP doesn’t require servers to try alternate MXes after a failure. In fact, most email systems give up after one attempt. According to a study by Return Path, over 60% of delivery failures in high-volume sending environments stem from servers not retrying on alternate MXes.

That means if your primary mail server is down—whether from a misconfiguration, network outage, or maintenance—messages sit in the queue until the server comes back online, if ever. Even then, they may be delayed by hours or dropped entirely due to timeout policies.

Let’s be clear: this isn’t a flaw in your infrastructure. It’s how the system was designed. Relying on DNS to handle failure isn’t reliable because the protocol lacks the logic to detect outage and switch over. If you’re sending to domains with only a single MX record, you’re trusting an untested, high-risk setup.

Still, you can reduce risk by verifying sender infrastructure and using tools that check MX and delivery paths in advance. You can also use inbox placement testing to simulate how messages from your domain will be received across major providers, including when delivery chains are disrupted.

How unreachable MX records impact your domain’s reputation

When your primary MX record is unreachable, email providers see repeated delivery failures as a sign of poor infrastructure. This triggers their spam filters and reputation systems, which track bounce rates and delivery status. A sudden spike in failures—especially from valid domains—can result in a reputation downgrade, affecting both inbound and outbound mail, even if your sending setup is otherwise healthy.

Why delivery failures hurt your domain’s reputation

Spam detection systems don’t just look at content—they track patterns. If your domain consistently fails to deliver to recipients, providers like Gmail, Outlook, or Yahoo flag it as unreliable. This isn’t just about bounced messages; it’s about consistency. When a domain fails to reach its target MX servers, it signals instability, which spam engines interpret as a risk.

For example, if your outbound email system sends 5,000 messages, and 1,000 bounce due to unreachable MX records, that’s a 20% failure rate. Most providers consider anything above 1% to be concerning. Even if those bounces are “soft” (not permanent), repeated soft bounces are still tracked. The longer this continues, the more likely your IP or domain will be marked as low-reputation, leading to filters, reduced inbox placement, or even temporary blocking.

It’s not just outbound—it affects inbound too

Unreachable MX records don’t just block your outbound emails; they break your inbound mail as well. If you can’t receive messages, your domain appears inactive to other providers. That sends a signal: “This domain may have no active infrastructure.” Providers cross-check these patterns. If your domain fails to accept incoming mail, they’re less likely to deliver to it in the future.

And yes, this plays out in real-world scenarios. The MxToolbox reports show that persistent MX resolution issues are a common red flag in deliverability audits. Even if your sending practices are solid and your content is clean, infrastructure problems like unreachable MX records can tank your reputation faster than any spammy subject line.

Let’s say you're relying on third-party tools to verify your lists before sending. Tools like bulk email verification can catch invalid or non-reachable destinations before they cause bounces. This protects your sender reputation by keeping your list clean and reducing the chance of failed deliveries.

What to check if your primary MX is unreachable

If your primary MX record is unreachable, incoming mail will fail to deliver or be delayed, often triggering soft bounces or indefinite retry loops. This usually means either your DNS configuration is pointing to a dead server, the server itself is offline, or a network barrier—like a firewall—is blocking SMTP traffic. Let’s walk through the most common culprits and how to fix them.

DNS and server health: the basics

Use MxToolbox or standard tools like dig and nslookup to verify that your MX record resolves to a valid, active mail server. A misconfigured record or outdated DNS entry can cause the entire delivery chain to fail.
Check that the mail server associated with your MX is live and responding. A server might be down due to maintenance, reboot, or resource exhaustion—even briefly.
Ensure port 25 (SMTP), 465 (SMTPS), or 587 (Submission) are open and accepting connections from external sources. Many hosting providers block these by default for outbound-only setups.

Network and access barriers

Review your firewall rules—both on the server and in your network infrastructure—to confirm that inbound SMTP traffic isn’t being dropped. A change in security policies can silently block mail.
If you're using a reverse proxy, load balancer, or cloud service (like AWS EC2 or Google Cloud), verify that the service is correctly configured to forward SMTP traffic and not drop it due to connection timeouts or rate limiting.
Test connectivity from multiple geographically diverse locations. Tools like RFC 5321 define the SMTP protocol behavior, and real-world testing helps rule out local network issues.
Consider that even if your primary MX is down, some mail servers will attempt delivery via backup MX records—if you’ve set them up. If no backup exists, delivery will fail until the primary is restored.

Proactive verification helps catch these issues early. You can test your domain's deliverability and inbox placement with inbox placement testing, which simulates real-world email delivery and reveals delivery delays or routing problems before they impact your users.

Preventing MX outages before they happen

If your primary MX record becomes unreachable, email delivery fails for all messages sent to that domain—unless you have a secondary MX configured with a lower priority, monitored continuously, and tested in advance. Without redundancy, every outage means lost messages, damaged sender reputation, and a broken customer experience. Let's build a system that stays online even when it's supposed to.

Build redundancy into your MX configuration

Always configure at least one secondary MX record with a higher priority number (lower preference) on a separate, healthy server.
Ensure the secondary server is not on the same network, cloud instance, or IP address as your primary to avoid shared failure points.
Use MX records with different priority settings—commonly 10 for primary, 20 for secondary—to allow SMTP clients to fall back reliably.

Maintain visibility and control

Use uptime monitors like UptimeRobot or Pingdom to track DNS resolution and server health at regular intervals (e.g., every 1–5 minutes).
Pair this with email delivery tracking tools that verify inbox placement and detect routing issues early—especially important for campaigns that rely on consistent delivery.
Test failover manually at least quarterly using tools that simulate MX failures and verify fallback behavior.
Document your outage response plan, including who to notify, how to escalate, and the steps to switch DNS or reconfigure MX records.

According to RFC 5321, mail servers must attempt delivery to alternate MX records if the primary is unreachable—this only works if those records are properly set up. You’re not just reducing risk; you’re hardening your email infrastructure.

Consider the cost of downtime: a single day of undelivered email can impact conversions, customer trust, and lead tracking. Proactive checks are cheaper than reactive firefighting.

Use bulk email verification to find and validate addresses before sending, and inbox placement testing to ensure your messages land in inboxes—not spam folders—before the campaign goes live.

How email verification helps prevent delivery issues

When your primary MX record is unreachable, emails to that domain fail silently or are delayed, damaging sender reputation and inbox placement. Email verification catches these issues before you send by identifying invalid, non-existent, or problematic addresses—including those with unreachable MX records—so you don’t waste sends on addresses that will never receive your message. This proactive step saves time, improves deliverability, and protects your sender score.

Why MX unreachable issues matter before they happen

Every time an email is sent to an address with an unreachable MX, your server attempts delivery, only to fail. These failures don’t just mean missing a message—they contribute to sender reputation problems over time. If you’re sending to thousands of addresses, even a few dozen undeliverable emails can push you into a blacklist or trigger throttling by inbox providers. The issue isn’t just about one email; it’s about how often your domain appears on the wrong side of reputation thresholds.

During verification, tools like Emaillistchecker.io check DNS records, including MX records, at the time of validation. If the MX is unreachable or missing, the address is flagged as risky. This isn’t guesswork. It’s a real-time probe into the recipient’s mail infrastructure. You don’t need to wait for bounces to learn that the server isn’t responsive. Instead, you catch the issue preemptively.

Accuracy that matters: Verification with real results

With 98.9% accuracy, Emaillistchecker.io detects MX-related issues during bulk verification—flagging addresses where the domain’s mail server cannot be reached, or where configuration errors prevent delivery. This means you’re not sending content into the void.

Let’s say you’re sending a newsletter to 5,000 contacts. Without verification, you might send to a hundred addresses with unreachable MX records. Those bounces, if they pile up, harm your deliverability. But with verification, you eliminate them before the send. This is how you maintain a clean sender reputation and avoid being flagged by providers like Gmail or Outlook.

Even if you’re using a reliable ESP like SendGrid or Mailchimp, poor list hygiene still hurts performance. That’s why best-in-class tools integrate with platforms such as HubSpot and Klaviyo. You can verify lists before syncing them—ensuring only valid, deliverable addresses advance.

For deeper testing, inbox placement tools help confirm whether messages actually arrive in inboxes. It’s not just about delivery; it’s about visibility. Test your deliverability across major providers with a single click, and verify you’re not just sending—your message is reaching the right people.

Real-world impact: What happens in practice when MX fails

If your primary MX record is unreachable—whether due to server downtime, misconfiguration, or network issues—emails sent to your domain won’t deliver. The sending server tries the primary MX first, and if it can’t reach it, delivery often fails outright or is delayed indefinitely, particularly if no backup MX is configured. This means transactional messages like password resets or order confirmations never arrive, leaving users stuck and support teams overwhelmed. Over time, repeated delivery failures hurt your sending domain’s reputation, increasing the chance your emails are flagged or blocked—even if the issue is internal.

When the server goes down, the email doesn’t come back

Let’s say your password reset email gets sent while your mail server is down, maybe because of a hardware failure or a misconfigured firewall. The sending server tries to connect to your primary MX, can’t, and doesn’t know what to do next. Without a backup MX configured, it gives up and returns a permanent failure—usually a 5xx SMTP error. That email? It never reaches your user. No delivery, no notification, no bounce message sent back to the sender immediately. The user never gets the reset link, logs in, or even realizes something failed. They’ll eventually reach out to customer support, assuming the system is broken.

Reputation damage starts silently

Even though the outage is on your end, email providers like Gmail and Outlook notice. When your domain regularly fails to accept inbound mail—especially for high-priority messages—it starts to look unreliable. Spam scoring systems track delivery success rates, and repeated failures are a red flag. You might not see a sudden blacklisting, but your reputation gradually degrades. Over time, your messages get more likely to land in spam folders, or be silently throttled. This isn’t about a single bounce; it’s about consistent delivery failure over time. Tools like MxToolbox or Spamhaus can help detect MX reachability, but they don’t stop the damage—they just reveal it.

Proactive verification keeps this from happening. Use bulk verification to catch invalid or non-responsive domains before sending. You can test your senders’ email addresses in real inboxes with inbox placement checks—like the ones at inbox placement testing. For developers, the verification API (API for real-time checks) ensures new sign-ups and updates are valid before they ever hit your mail server. The cost of not doing this? Higher support load, frustrated users, and degraded sender reputation. It’s not about perfection—it’s about preventing avoidable failures. If your MX is down, your emails won’t make it. And if they don’t make it, your relationship with users starts to break.

When your primary MX record is unreachable, emails sent to those addresses will either time out or bounce hard, disrupting deliverability and harming your sender reputation. Emaillistchecker.io detects these risks before you send by verifying the actual state of MX records during bulk list checks and API calls, so you can catch issues early and keep your list clean.

Proactive MX and Deliverability Checks

Use our bulk verification tool to scan your entire list and flag addresses hosted on domains with unreachable or misconfigured MX records.
Our real-time API checks the current MX state of each address, surfacing issues like expired records, misrouted domains, or non-responsive mail servers before you send.
Identify catch-all addresses that accept all incoming mail—even invalid ones—because they can inflate your delivery stats and dilute list quality.
See whether addresses are at risk due to greylisting, DNS configuration errors, or temporary outages that could cause intermittent failures.

High Accuracy, No Expiry

Our verification process runs across multiple layers of DNS, SMTP, and real-time validation—achieving 98.9% accuracy in distinguishing valid from invalid addresses.
Each credit you purchase never expires, so you can maintain clean lists over time without time pressure or losing access to verified data.
Integrate with tools like Mailchimp, HubSpot, and SendGrid via our integrations to automate verification before every campaign.
Test inbox placement directly with our inbox placement feature to confirm your messages actually land in inboxes—not spam folders or blocked queues.

Domain-level DNS issues, including unreachable MX records, are a leading cause of hard bounces and sender reputation damage. Monitoring them proactively is an industry-standard practice.

For deeper context on how DNS and MX records affect email delivery, refer to the SMTP specification and Spamhaus's guidance on email infrastructure health.

Final takeaway: No MX record is invincible

Even the most established domains experience MX record unreachability. Outages happen—due to configuration errors, DNS issues, or provider delays. What matters isn’t avoiding downtime entirely, but preparing for it.

Proactive measures reduce fallout: monitor your MX health, configure secondary MX records, and maintain a clean email list with verified addresses. These steps keep delivery flowing during disruptions and preserve sender reputation.

You don’t need flawless uptime. You need resilience. A system that absorbs small failures without breaking is what keeps messages in inboxes.

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

Can email still be delivered if the primary MX is unreachable?

Only if a secondary MX with a lower priority is correctly configured and operational. Otherwise, delivery fails permanently.

How long do email servers wait before giving up on an unreachable MX?

Typically 30–60 seconds per attempt. Servers retry up to 3 times over a 2–3 day window before delivering a hard bounce.

Does an unreachable MX record affect outgoing email?

No—only incoming email to that domain is affected. However, failed incoming deliveries can harm domain reputation over time.

Can email verification detect unreachable MX records?

Yes—verified email list tools like Emaillistchecker.io check the MX configuration and flag addresses with unreachable or poorly configured mail servers.

What’s the best way to test if my MX record is reachable?

Use DNS lookup tools like dig or MxToolbox to verify the MX records, then test connectivity using telnet or netcat to port 25 (SMTP).

Are MX records cached by DNS providers?

Yes—DNS TTL values determine how long records are cached. Changes to MX records can take up to 48 hours to propagate globally.

Can a catch-all email address mask an unreachable MX?

No—a catch-all address only handles undeliverable messages after delivery attempts. It does not prevent delivery failure due to unreachable MX records.

How does a bad MX record impact sender reputation?

Repeated delivery failures from unreachable MX records are seen as poor infrastructure, contributing to lower sender reputation scores over time.

These do not affect MX reachability but ensure messages are properly authenticated. An unreachable MX means no one receives the message, regardless of authentication.

Do all email providers respect MX record order?

Yes—most follow the priority order assigned to MX records. A higher-priority record is always tried first.

Can load balancers or reverse proxies prevent MX reachability?

Yes—misconfigured reverse proxies or load balancers can block SMTP traffic or fail to route mail to the correct server, causing MX unreachability.

How many secondary MX records should I have?

One secondary is minimal. For resilience, use at least two MX records with incremental priorities (e.g., 10, 20, 30) across independent servers.