MX Record Weights for Failover & Load Balancing

Why MX record weights matter for email delivery reliability

You send a critical campaign, and half your messages vanish into the void. No bounce, no error—just silence. It’s not spam filters. It’s not a misconfigured inbox. It’s a single overlooked detail in your DNS: the weights on your MX records.

MX records aren’t just a list of servers. They’re instructions with priorities. Without proper weights, you’re trusting one mail server to handle all your traffic—and if that server crashes, your entire email flow goes dark. It’s not just inconvenient. It’s a delivery failure you can’t recover from.

Setting MX record weights correctly isn’t about theory. It’s about engineering your email service to survive server outages and scale under load. You don’t need perfect redundancy to avoid downtime—you just need smart weights.

Key takeaways

MX record weights determine the order in which mail servers receive email, with lower numbers taking precedence.
Using equal weights across servers creates a load-balancing effect, reducing the risk of single-point failure.
Proper weighting enables automatic failover—when a primary server is unreachable, mail routing shifts to secondary servers without interruption.

How do MX records work with weights and priorities?

MX records tell email systems which servers should receive mail for your domain. You set priorities: lower numbers mean higher priority. If the top server is down, mail automatically routes to the next available server in the list—this is failover. You can also use multiple records with equal priorities for load balancing across backup servers, spreading incoming mail while maintaining reliability. This is how domains maintain inbox delivery during outages or high traffic.

Priority vs. Weight: The Real Difference

Many confuse "priority" with "weight." Priority determines the order in which servers are tried—lower is better. Weight, on the other hand, is used when multiple servers share the same priority to distribute load. For example, two servers with priority 10 and weights 50 and 100 will receive roughly 33% and 67% of mail, respectively. This isn’t part of the original RFC, but widely supported by modern MTAs like Postfix and Exim.

Let’s say you have two mail servers: server1.example.com with priority 10 and server2.example.com with priority 20. If server1 fails, incoming mail will automatically be delivered to server2. That’s failover. But if you have two servers at priority 10, and both have a weight of 50, the system will distribute incoming messages between them—this is load balancing. This behavior is consistent across most email providers and isn’t just theoretical; it’s how large organizations like Google and Microsoft manage their mail infrastructure.

Setting Up MX Records for Resilience

To set up resilient email delivery, add multiple MX records with lower priorities for primary servers and higher ones for backups. For load balancing, assign identical priorities with different weight values. Keep your primary server’s priority low (e.g., 10) and backups higher (e.g., 20, 30). This ensures that delivery attempts start at the fastest, most reliable server first.

Your DNS provider’s control panel is where you configure this. You’ll see fields for priority and target—enter the mail server hostname and its priority. If you’re using a self-hosted mail solution, your mail server software should report delivery status via SMTP return codes to confirm MX handling is working.

When testing, use tools like MxToolbox or dig to verify your records resolve correctly and in the right order. Always test in a staging environment first. Misconfigured MX records can result in email delivery delays or outright rejection, hurting sender reputation.

If you’re managing large mailing lists, you might want to ensure your email domains are not flagged as spam. A clean list helps with deliverability. Use a real-time email verification service to clean your list before sending, and monitor bounce rates and feedback loops to maintain reputation. For example, bulk verification can help detect invalid or risky addresses before they hurt your sender score.

What is the role of MX weight in load balancing?

MX weight determines how email traffic is distributed among servers with the same priority, enabling load balancing across multiple inbound mail servers. When multiple MX records share the same priority, mail clients randomly pick one based on weight — lower values are preferred — allowing you to spread inbound email across servers without overloading any single one.

How MX priority and weight differ

It's common to confuse MX priority with weight — they serve entirely different purposes. Priority dictates the order in which servers are attempted; lower numbers are tried first. Weight only comes into play when multiple servers have identical priority, and it controls how much traffic each one receives.

For example, if you have two servers with priority 10, setting one a weight of 10 and the other 20 means incoming mail is sent to the first server roughly twice as often as the second. This lets you fine-tune traffic distribution based on server capacity.

Setting up load balancing with MX records

Let’s say you’re running three mail servers behind a load-balanced infrastructure. You’d assign each the same priority — say, 10 — and then give them different weights: 10, 20, and 30. Mail clients will then route messages to each server in proportion to their assigned weights.

This approach works best when servers are similarly configured and capable. If one server has lower capacity, you’d assign it a lower weight to avoid bottlenecks. The exact ratio depends on your infrastructure’s performance and scale.

For more on how email routing and infrastructure integrity affect deliverability, see how inbox placement testing can help validate that your setup actually reaches inboxes, not just mail servers.

How to set up MX records for failover using weight and priority

You can configure MX records for failover by assigning a lower priority number (e.g. 10) to your primary mail server and a higher number (e.g. 20) to your secondary. When the primary is unreachable, mail servers automatically try the secondary. Weight only affects load distribution; priority alone handles failover.

Set up your MX priorities correctly

Log in to your DNS provider’s control panel (like Cloudflare, AWS Route 53, or GoDaddy).
Create an MX record for your primary mail server with a priority of 10.
Add a second MX record with priority 20 pointing to your secondary server.
Save the changes. Propagation may take a few minutes to a few hours.

Mail servers always try the lowest priority number first. A priority of 10 is preferred over 20. If your primary server is down or unreachable, the sending server will attempt delivery to the secondary with priority 20. This is how failover works — no weight needed.

The 4 steps described in “Set up your MX priorities correctly”, in order.

When to use weights vs. priority

Weight affects how often mail is sent to each server — it's for load balancing, not failover. If you want to share load 70/30 between two servers, you could use weights 7 and 3. But if you’re only securing against server downtime, prioritize correctly and skip weights.

For example, if your primary goes offline, the sending server will retry the secondary after a timeout — usually within minutes. That’s enough to maintain delivery continuity. As the IETF outlines in RFC 5321, mail transport systems expect this priority-based fallback behavior.

Once set up, verify your MX records with a tool like MXToolbox or DNS.com’s DNS checker to ensure both records are properly published and reachable.

Let’s be clear: this setup doesn’t prevent downtime — it just ensures mail delivery doesn’t break entirely when a server is offline. For best results, keep your secondary server reliable and regularly maintained.

If you're managing a large email list, keep it clean. Use a tool like bulk email verification to identify and remove invalid addresses before sending, so your mail flow stays predictable and less prone to delivery issues that could trigger unnecessary fallbacks.

How to configure load balancing with MX weights

You can distribute incoming email traffic across multiple mail servers by setting identical MX priority values and assigning different weights. Mail clients will select servers in proportion to their weights—higher weight means a higher chance of being chosen. This approach balances load and supports failover without requiring complex routing logic.

Set up MX records for balanced delivery

Assign the same priority number (e.g., 10) to multiple mail servers. This tells mail clients they’re equally preferred, so the decision between them comes down to weight distribution.
Define distinct weights for each server (e.g., 50, 100, 150). Higher values increase the likelihood a server receives incoming mail. RFC 5321, the foundational email standard, outlines how mail transport agents evaluate multiple MX records during delivery routing, relying on priority and weight parameters.
Use weight values in ratios, not absolute numbers. A 100:200 ratio behaves the same as 50:100. The relative proportion matters more than the specific values assigned.
Test the setup using tools like MXToolbox or by sending test emails to confirm delivery paths. Real-world behavior can vary slightly based on client policies, so monitoring is essential.

Why weight-based load balancing works

When mail clients evaluate MX records, they prioritize the lowest priority number first. If multiple records share that priority, they’ll use the assigned weights to decide which server to relay to. This method ensures no single server becomes a bottleneck, even during high traffic.

For example, if you have three mail servers with weights 50, 100, and 150, the system will route approximately 20% of messages to the first, 40% to the second, and 40% to the third. Adjusting weights lets you favor faster or more reliable servers during peak times.

If a server becomes unreachable, clients automatically fall back to others with lower priority or higher weights—no manual intervention needed. This behavior is a core part of how modern email delivery handles failure redundancy.

You can verify the integrity of your email infrastructure by checking for misconfigured MX records, catch-all setups, or suspicious domains. Use our bulk verification tool to audit large lists and ensure deliverability isn’t undermined by faulty addresses or invalid MX configurations.

Common mistakes when setting MX record weights

Setting identical priorities and weights for multiple MX servers creates unpredictable delivery paths, as mail providers may treat them as equal—leading to inconsistent routing and no real failover. You might think you’re balancing load, but without properly weighted priorities, messages can get stuck in queues or sent to underperforming servers. The fix? Use distinct priorities and test every path.

Identical priorities cause routing chaos

Using the same priority value across multiple MX records (e.g., two servers both set to priority 10) means mail servers treat them as equally preferred—but don’t trust that they’ll split traffic evenly.
Some mail servers will cycle through them, others may pick the first one they resolve, leading to uneven load and potential bottlenecks.
For true failover and balance, set different priority values (e.g., 10 and 20), then use weights only within the same priority group to fine-tune distribution.

Weight imbalance misallocates traffic

Assigning a lower weight to a server that’s already slow or unreliable means more traffic gets routed there—even if that server is already strained.
High-weight servers should reflect performance and capacity—not just theoretical uptime. Weighting should mirror actual availability, not just configuration.
Monitor your mail logs and delivery performance regularly—especially if a server is nearing maximum connection limits or has recent downtime.

Testing failover is non-negotiable

Never assume failover works unless you’ve tested it—simply disabling a server during a maintenance window reveals whether backups are truly active.
Tools like inbox placement testing can help you monitor how message delivery changes when one server is offline.
The real test? Send a few verified messages to your own domains during a simulated outage. If delivery fails or takes minutes, your MX setup isn’t reliable.

For deeper insight into how mail routing and delivery reliability work, review RFC 5321 (SMTP) and RFC 5322 (Internet Message Format) from the IETF. These define the protocols governing mail delivery paths and server behavior—something every operations team should understand.

How to verify MX record configurations are effective

You can verify MX record settings work as intended by checking DNS propagation with tools like MxToolbox, simulating failover by disabling a server, monitoring SMTP logs for bounces or delays, and confirming traffic splits during load tests. These steps ensure your mail routing behaves predictably under normal and failover conditions.

Validate DNS propagation before testing

Use MxToolbox or run dig MX example.com from multiple global locations to confirm MX records are visible everywhere, not just locally.
Wait 24–48 hours after making changes if using standard TTLs—some ISPs cache DNS longer than others.
Check that the record's weight values (e.g., 10, 20) are applied correctly across all authoritative name servers.

Test routing behavior under real conditions

Temporarily disable one mail server and send test messages to confirm the next-highest-priority MX is used—this validates failover logic.
Monitor SMTP logs on both servers: look for rejected connections, timeouts, or delayed deliveries that suggest misrouting or queue congestion.
Run a load test using tools like RFC 5322 compliant scripts to simulate traffic spikes and confirm messages distribute according to weight settings.
Use inbox placement testing to simulate real-world delivery and check whether messages arrive promptly across different inboxes.

How email verification helps maintain clean delivery infrastructure

You can’t rely on your MX records alone to ensure reliable email delivery. Even with perfect DNS configuration, sending to invalid, outdated, or risky addresses harms sender reputation, increases bounce rates, and can trigger spam filters. Regular email verification catches these risks before they reach your server, keeping your list clean and your inbox placement consistent. This is how you maintain a delivery infrastructure that works reliably over time.

Invalid emails are hidden threats to your sender reputation

Every email to an invalid address is a potential misstep. These failures don’t just create bounces—they can signal list fatigue or poor list hygiene to inbox providers. In severe cases, spam traps can be triggered by old or never-activated addresses that still receive mail, resulting in hard bounces and reputation damage. According to Spamhaus, even a small number of undeliverable addresses can negatively impact deliverability over time.

Think of your sending infrastructure like a well-maintained engine: it only runs efficiently when every component—DNS, authentication, and your list—is in top shape. Sending to invalid addresses is like pouring sand into the fuel. It doesn’t stop the engine immediately, but it wears it down over time, eventually causing failure.

Verification stops risks before they impact delivery

Let’s be clear: you don’t want role-based emails (like sales@ or info@), catch-all inboxes, or disposable domains in your sends. These aren’t just low-quality addresses—they’re deliverability hazards. Catch-alls accept any email, so they aren’t reliable indicators of engagement. Role addresses are often ignored or flagged. Disposable domains are commonly associated with spam. Sending to these types of addresses inflates your bounce rate and confuses inbox providers.

That’s where bulk email verification comes in. It checks thousands of addresses in minutes, flagging invalid, risky, or non-deliverable ones. You’re left with a clean, high-quality list—only the addresses that are likely to open and engage. This directly supports your sender reputation, reduces bounce rates, and improves inbox placement over time.

Every verification step you add between your list and your send server builds confidence in your delivery stack. It doesn’t replace DNS checks or DKIM alignment—but it ensures you’re not sending to addresses that will fail anyway. A clean list isn’t just about fewer bounces; it’s about building a reputation that inbox providers trust.

Real-world impact: what happens when MX records are misconfigured

When MX records aren't weighted correctly, emails delay, vanish, or get marked as spam. Without failover, a single server outage can knock your entire domain offline. Spam filters notice inconsistent delivery patterns and may flag your domain. Blocklists follow. This isn’t theory — it’s what happens when you skip proper configuration.

How misconfiguration breaks delivery in practice

Messages may sit in queues for hours or be dropped entirely if no backup MX is available — you’ve lost the email, but not the sender reputation.
Spam filters increasingly monitor delivery consistency. Sudden spikes or drops in inbound traffic from a domain can raise red flags, especially if logs show irregular routing.
Without failover, a single server crash can cause a full service outage — outbound email volume spikes unpredictably when retry mechanisms kick in, overwhelming fallback systems.
Continuous delivery failures — even a few per day — can trigger domain reputation penalties. Your domain may be listed on major blocklists like Spamhaus, meaning legitimate messages won’t reach inboxes.

What you’re actually risking

MX misconfiguration isn’t a minor glitch. It’s a direct line to reputation damage, lost customer communication, and inbox placement failure. The RFC 5321 standard outlines the expected behavior of mail transfer agents, including how they handle multiple MX records — getting it wrong means you’re not just failing a process, you’re breaking protocol.

“Email deliverability is not a one-time setup. It’s an ongoing discipline tied to infrastructure reliability, policy consistency, and reputation management.” — RFC 5321 (SMTP)

Even a small error in weight assignment can cause routing loops or skipped backups. You might think your system is healthy, but logs may show only secondary servers receiving connections. That’s not load balancing — that’s poor design.

Before you deploy any email-based workflow, validate your MX setup using tools that test routing behavior across global networks. You can test email delivery paths, including failover resilience, with inbox placement tools that simulate real-world conditions.

Check your domain’s MX records in real time with a trusted verification tool before you send. If you’re managing large lists, bulk verification helps catch invalid or misrouted addresses before they cause delivery issues. Use bulk email verification to test delivery readiness and eliminate risky addresses.

Best practices for maintaining reliable MX record configurations

You can ensure consistent email delivery by testing changes in staging, documenting your MX roles, monitoring DNS with alerts, and aligning your MX setup with strong SPF, DKIM, and DMARC policies. These steps reduce risk, prevent downtime, and improve inbox placement. Let’s break down what actually matters.

Test and validate before going live

Always test MX changes in a non-production environment first. Even small errors can cause emails to fail silently.
Use tools like MXToolbox to check propagation and verify records across multiple locations before applying to production.
Monitor responses from major email providers—like Gmail, Outlook, and Yahoo—to ensure the new setup accepts mail reliably.

Document and monitor for clarity and control

Keep a living document of all MX records, their priority weights, and their intended purpose—e.g., primary, backup, or load-balanced.
Assign roles clearly: lower numbers mean higher priority in SMTP delivery. Misordering can lead to failover delays or imbalance.
Set up automated monitoring using DNS health checks. Services like DNSPerf or built-in platform alerts can notify you of unexpected changes.
Combine MX reliability with cryptographic email authentication. SPF, DKIM, and DMARC prevent spoofing and improve sender reputation.
Use bulk email verification to clean your sender list and avoid sending to invalid or risky addresses that could harm your domain’s reputation.

There’s no substitute for visibility. The better you understand your DNS configuration and how it interacts with deliverability signals, the fewer surprises you’ll face. A single unverified address or misaligned record can trigger filtering—even if every other part of your setup is perfect.

Remember: MX records don’t exist in isolation. They’re part of a larger system of trust, deliverability, and infrastructure health. When paired with proper authentication and a reliable verification process like the one our real-time API enables, you’re not just managing records—you’re protecting your sender identity.

Failover and load balancing are not optional — they’re essential for email resilience

Email failure is not a matter of if — it's a matter of when. Infrastructure changes, outages, or spikes in traffic will happen. Relying on a single MX record is a single point of failure.

Properly weighted MX records ensure continuity during outages and distribute load during peak times. This DNS-level configuration is the foundation of resilience — but it only works when your email list remains clean and deliverable.

Combining weighted MX records with ongoing verification and monitoring strengthens both delivery and sender reputation. Tools like Emaillistchecker.io help catch invalid, catch-all, and disposable addresses before they harm your sender score — ensuring your verified list reaches inboxes consistently.

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 MX records with the same priority handle load balancing?

Yes, when multiple MX records have identical priority, mail servers randomly select one, distributing load across them based on weight settings.

What happens if all MX records fail?

Mail delivery fails. There is no fallback beyond DNS; messages are returned to the sender with a hard bounce.

Do MX weights apply to all email providers?

Most providers respect MX weights, but delivery behavior can vary slightly based on server implementation and queueing logic.

Can I use MX records for failover without load balancing?

Yes — simply assign different priorities. Lower priority servers only receive mail when higher priority ones are unreachable.

How often should I test MX record failover?

Test at least quarterly, or after any change to DNS or infrastructure. Automated monitoring is more reliable than manual checks.

Does Emaillistchecker.io verify MX records?

No — Emaillistchecker.io specializes in verifying email addresses for validity, deliverability, and hygiene. It does not test DNS or MX configuration.

How does email verification improve deliverability?

Validating addresses reduces bounces, prevents spam trap exposure, and maintains sender reputation — all key to inbox placement.

Can a domain’s reputation be damaged by misconfigured MX records?

Yes — persistent delivery failures due to misconfiguration can trigger spam filters and lead to blocklisting.

Is it safe to change MX record weights in production?

Only if the change is tested and monitored. Deploy during low-traffic windows and verify delivery immediately after.

What’s the difference between failover and load balancing in MX setup?

Failover uses priority to switch to backup servers if primary ones fail. Load balancing uses weight to distribute traffic across servers of equal priority.

How do I know if my MX records are properly weighted?

Test by disabling one server temporarily and monitor delivery logs. Traffic should shift to the next available server based on weight and priority.

Does Emaillistchecker.io help with email infrastructure health checks?

It doesn’t check MX records or DNS, but it helps maintain list hygiene — a critical component of overall deliverability health.