How to Interpret MX Preference Values

Why MX preference values matter for email deliverability

You’ve double-checked your MX records. The syntax is correct. DNS propagates. But emails still bounce or arrive hours late. Why?

It’s not just about listing mail servers — it’s about the order in which they’re tried. MX preference values are the invisible traffic directors for your inbound mail. Get them wrong, and delivery fails silently.

Understanding how MX preference values work isn’t just technical minutiae. It’s the difference between reliable inbox placement and erratic delivery delays, even when every other DNS record is flawless.

Key takeaways

MX preference values determine the priority order for mail server attempts during delivery.
Misconfigured preferences can cause delays or outright delivery failures despite correct DNS records.
Setting appropriate priorities enables high-availability email infrastructure by enabling fallback routing during outages.

What is an MX record and what does it do?

An MX (Mail Exchange) record tells incoming email systems which server is responsible for receiving messages sent to your domain. It points to a hostname—like mail.yourcompany.com—where inbound emails should be routed. Multiple MX records can exist, each with a preference value that determines priority: lower numbers are tried first.

How MX records direct email flow

When someone sends an email to yourdomain.com, their mail server checks your DNS for an MX record. That record lists the mail servers allowed to receive email on your behalf, along with a numerical preference—lower is higher priority. If the primary server is down, the sending server will try the next one in line based on preference.

Let's say you have two MX records: one with preference 10 (primary) and another with preference 20 (backup). The sender’s server will first try the one with 10. Only if that fails will it move to the 20 one. This setup protects against downtime and ensures email delivery even during outages.

Preference values: how they work in practice

Preference values are not about speed or load balancing—they're purely about failover order. A value of 0 is the highest priority, though values like 10, 20, or 50 are more common in practice. You can set multiple servers with the same preference to enable load distribution, but only if the servers are configured to handle shared inbound mail.

If you set preferences too high (e.g. all at 100), the system may appear to fail silently if no server responds, because the sender won’t try alternate routes immediately. That’s why balancing preferences across multiple servers—with one slightly lower than the rest—is a reliable, standard practice.

Understanding this helps when you’re diagnosing delivery issues. If emails aren’t arriving, checking your MX records for correct preference values and valid hostnames is one of the first steps. Misconfigurations here are common—and easily fixed with tools that validate DNS settings.

For example, if you're validating a list of customer emails and want to ensure the domains can receive mail, you can use the bulk verification tool on Emaillistchecker.io to flag domains with missing or misconfigured MX records before sending.

How MX preference values work in practice

Lower MX preference numbers mean higher priority—so a record with preference 0 is tried before one with preference 5. Mail servers attempt delivery in order, starting with the lowest-numbered MX. If that server is unreachable or rejects the message, the sending server moves to the next highest preference, continuing until a server accepts the mail or all options are exhausted.

Priority is determined by number, not alphabet or order

MX preference isn’t about the order you write records—it’s about the number. A preference of 0 means "try me first," while a preference of 10 means "I’m a backup." You might see multiple MX records with the same number, which means those servers are treated as equals and chosen randomly during delivery attempts.

For example, if you have MX records set to 0, 5, and 10, your mail will go to the 0 server first. If that server is down or rejects the message, the sender tries the 5 server. Only if that fails does it fall back to the 10 server. This is how failover works in practice.

Some ISPs and larger organizations use multiple low-numbered MX records (like 5 and 10) to balance load across servers. But mixing preference numbers incorrectly—like using 0, 1, 1, 2—can still result in uneven traffic, especially if one 1-level server goes offline unexpectedly.

What happens when a mail server rejects or doesn’t respond

There’s no magic timeout—this all depends on the sending server’s configuration. But generally, if the target server doesn’t respond within a few minutes (typically 5–10), the sender will move to the next MX record. This includes both timeouts and explicit rejections (e.g., a 5xx error or a “550 User unknown” response).

If no MX record can accept the message, the sender returns a hard bounce. This is why it’s important to test MX configurations regularly—especially when switching providers or updating infrastructure. An outdated or misconfigured MX record can silently cause entire mail streams to fail.

For insight into real-world delivery behavior, you can study how email providers handle delivery via protocols like SMTP, as defined in RFC 5321. This document is the foundation for how mail servers communicate and resolve delivery paths.

Use tools that let you validate your mail setup before sending. Bulk verification helps catch issues across large email lists, including malformed or non-existent domains—many of which stem from incorrect DNS records like MX preferences.

While MX preferences guide routing, they don’t guarantee inbox delivery. That depends on other factors like sender reputation, content quality, and whether the recipient’s server has the right SPF, DKIM, and DMARC policies in place.

How to interpret MX preference values: a clear guide

MX preference values are relative priorities for incoming mail servers—lower numbers mean higher priority. A value of 0 is the preferred server; 10 is next in line, only used if the first fails. You can assign identical values to multiple servers for redundancy, but delivery order among those is unpredictable. These settings are only meaningful within the same domain’s MX records.

Understanding the hierarchy

When email arrives for a domain, the receiving mail server checks all MX records and tries them in numeric order. A record with preference 0 is attempted first. If that server is unreachable, the system moves to the next lowest preference—like 10, then 20, and so on.

No value is absolute. Preference 10 doesn’t mean "next after the top 10"; it means "second in line within this domain’s MX list." The actual numerical value only matters in comparison to others in the same DNS zone.

Using identical preferences wisely

You can assign the same preference value (say, 10) to two or more mail servers. This is commonly done for load balancing or failover. But because SMTP delivery systems don’t guarantee which server gets tried first when preferences are equal, you should not rely on predictability in this setup.

For example, using two MX records with preference 10 means both are treated as second-tier — but one might be tried first, and the other second, depending on the mail client’s implementation and timing. This unpredictability is normal and expected.

Best practice: use a low preference (0 or 1) for your primary mail server, and higher values (10, 20) for backups. If you have multiple primary servers for resilience, assign them identical low values but monitor logs to ensure delivery is balanced in practice.

For accurate delivery testing, use tools that simulate real-world sending. You can test your domain’s mail routing with inbox placement checks that verify delivery to inboxes, not just DNS checks. Test real inbox delivery with our inbox placement feature, which covers major providers and gives you actionable feedback.

Setting up multiple MX records with proper preference ordering

You set up multiple MX records by assigning lower preference values to your primary mail server and higher values to backups. The lower the number, the higher the priority. Always ensure your primary server has the lowest value, and use higher values (like 10, 20, or 30) for backups—never set defaults to 100 or 200. If the primary is unreachable, mail will attempt delivery to the next lowest preference. Only assign identical preference values to multiple servers when both are active; otherwise, delivery delays can occur.

How to assign MX preference values correctly

Use values like 0, 5, or 10 for your primary mail server—lower numbers mean higher priority.
Assign higher values (e.g., 20, 30, 40) to secondary or backup servers.
Avoid using 100 or 200 as default preferences—this creates long, inefficient fallback chains that delay mail delivery.
If you have two active servers, give them the same preference value only when both are intended to handle inbound mail simultaneously.
If only one server should be used at a time, ensure preference values are distinct and ordered correctly to prevent routing confusion.

Understanding fallback behavior and delay implications

When your primary MX server is unreachable, mail servers check the next lowest preference value. But if you’ve set multiple servers to the same preference (e.g., two servers both at 20), the receiving server may randomly attempt delivery to either—this can cause delays or inconsistent delivery, especially with high-volume senders.

Avoid this by using sequential preferences (e.g., 10, 20, 30) unless you have a high-availability setup where failover between identical servers is intentional and monitored.

For email list hygiene and deliverability, you need to validate your mail server setup. Use tools that check MX records and DNS configurations to catch misconfigurations before they affect delivery. Bulk verification can help you identify invalid or misrouted email addresses early in your campaign.

The behavior of MX preference values is defined in RFC 5321, the core specification for SMTP. You can review the standard at tools.ietf.org/html/rfc5321.

Common MX preference mistakes and how they hurt deliverability

You're likely experiencing inconsistent email delivery, higher bounce rates, or delayed inbox placement because your MX records use identical preference values, overly high priorities, or no testing after changes. These misconfigurations break routing logic and force mail servers to retry, increasing delivery risk. Let’s fix that.

How MX preference values actually work

MX preference values aren’t about speed—they’re routing order. Lower numbers are tried first. If that server fails, the next-highest-priority one is used. It’s not a failover; it’s a sequence.

You can find the official specification in RFC 5321, which governs SMTP and defines how mail delivery attempts are ordered.

Setting all MX records with the same preference (e.g., 10 for every server) defeats the routing purpose—mail servers pick one at random, leading to inconsistent delivery paths and unpredictable failures.
Using high preference values (like 100) for your primary mail server delays delivery. Incoming mail may attempt a secondary server first, causing latency and a higher chance of temporary failures.
Changing preference values without testing can redirect mail to an unhealthy or misconfigured server, especially if failover routing is misaligned with actual server status.
Assigning preferences without considering server uptime or geographic proximity ignores real-world delivery efficiency. A closer or more reliable server should rank higher, regardless of arbitrary numbering.

How to avoid these pitfalls

Let’s be clear: you’re not trying to optimize for “fastest” delivery, but for predictable, reliable routing. Here’s how:

Use a single primary MX with a low preference (e.g., 5–10) and backup servers with incrementally higher values (e.g., 20, 30).
Monitor server health and adjust preferences only after testing. A failed server shouldn't remain in the MX sequence.
Use DNS tools like MxToolbox to verify your MX propagation and routing behavior across networks.
Don’t rely solely on default values. They may conflict with your actual infrastructure setup.

For teams managing bulk email or complex routing, verifying DNS configurations and server reachability ahead of send is critical. You can test this with inbox-placement testing to see how real-world providers treat your mail after DNS changes.

Verifying your MX setup before sending email

You can't send mail reliably if your MX records aren't correctly set up and reachable. Before sending to your list, verify your DNS MX records using tools like dig or nslookup, check that the primary server (lowest preference) resolves to a live, accessible host, test delivery with a real address on your domain, and monitor logs for any delivery failures after changes. This process catches routing errors before they hit your sender reputation.

Check your MX records and preferences

Run a DNS lookup using dig MX yourdomain.com or a tool like MXToolbox to confirm your MX records are published and have the correct preferences. The record with the lowest preference (e.g., 0 or 10) should be your primary mail server.
Verify that the hostname resolves to a reachable IP address. Use dig A mail.yourdomain.com to ensure the server’s A record exists and points to a real, active host. If it doesn’t resolve, your mail server won’t receive messages.
Confirm reachability with ping or telnet on port 25 (or 587 for submission). If the server is unreachable, check firewall rules, network configurations, or DNS propagation delays.
Test inbox delivery by sending a message from outside your domain to a real email address on your domain. Check the inbox, spam folder, and mail logs for delivery success. Use tools like RFC 5321 as a baseline for SMTP behavior to understand how messages should be processed.
Monitor logs post-change for bouncebacks, delayed deliveries, or timeouts. Even after a correct setup, misconfigured SPF, DKIM, or DMARC records can cause rejection. Logs help identify whether the issue is routing or policy-based.

Common pitfalls and how to avoid them

Many teams assume DNS propagation is instantaneous. It can take up to 72 hours. Always test after waiting at least 24 hours. Also, avoid setting up multiple MX records with identical preferences—this can cause undeterministic routing. Use only one primary server unless you have a specific failover setup.

Let’s say you’re sending to a list of 10,000 contacts. You should first validate that your domain’s MX setup is correct. Then use bulk verification to flag any invalid or risky email addresses before sending, ensuring only deliverable addresses are processed.

How email-verification tools can help validate your email infrastructure

Tools like Emaillistchecker.io go beyond DNS checks by simulating real email sends to confirm your domain’s MX records are not just correctly configured, but actively accepting mail. This tests the actual behavior of your mail server, catching issues like greylisting, spam filters, or misconfigured catch-all policies that DNS alone can’t reveal. You’re not just verifying syntax—you’re validating delivery readiness.

Testing real-world delivery, not just DNS syntax

MX preferences matter, but they only tell part of the story. A domain might have correct MX records in DNS, yet still fail to deliver due to server-level filtering, temporary unavailability, or poor sender reputation. That’s where tools like Emaillistchecker.io step in—they don’t just read DNS; they send test messages and trace the full delivery path, from SMTP handshake to final acceptance or rejection.

Unlike simple DNS lookups, which only validate entries, Emaillistchecker.io simulates a real email transaction. It checks whether your mail server responds with a success code (250), or if it drops the connection, rejects the sender, or queues the message indefinitely. This reveals problems like misconfigured SPF, DMARC policy conflicts, or firewall rules that block inbound mail—even if DNS says everything's fine.

Confirming inbox placement, not just server acceptance

Receiving a "250 OK" from your mail server doesn’t mean your message lands in the inbox. It could be dropped into spam, the trash, or filtered by the user’s client. That’s why inbox-placement testing is essential. Emaillistchecker.io’s inbox-placement reports simulate real inboxes across major providers (Gmail, Outlook, Yahoo) and measure actual deliverability, not just server-side acceptance.

Mail that reaches the server but lands in spam harms engagement and damages sender reputation. By testing across real inboxes, you identify issues like mismatched content, poor authentication, or blacklisting that would otherwise go unnoticed. This visibility separates theoretical correctness from practical performance.

Use the inbox-placement tests to validate your campaigns before launch. For ongoing list hygiene, the bulk verification tool checks your entire list at scale, flagging risky, invalid, or catch-all addresses that could hurt deliverability. You can also verify single addresses using the real-time API, or enrich your database with the email finder. All tools support key integrations with platforms like Mailchimp, Klaviyo, and SendGrid via the integration hub. With 98.9% accuracy and credits that never expire, Emaillistchecker.io helps you move from DNS theory to real-world email reliability.

Emaillistchecker.io: real-time verification for delivery-ready domains

When you check MX preference values in DNS, you're verifying not just routing, but whether the domain is actually ready to receive email. Emaillistchecker.io goes beyond DNS lookup—it runs a real-time validation of MX records to confirm they’re properly configured and actively accepting inbound mail, so you don’t waste sends on domains that silently reject messages. This step ensures your campaign or outreach won’t fail at the door.

Real-time checks that prevent delivery failure

MX preference values alone don’t tell the whole story. A low number doesn’t guarantee the server responds. That’s why our API doesn’t just read DNS—it attempts an SMTP handshake with each domain’s mail server in real time. It confirms whether the MX is live, accepts connections, and is configured to receive email. You’re not guessing. You’re verifying. This is how you avoid sending to domains that bounce silently or get flagged as invalid.

The accuracy is verified at 98.9% on real-world data across industries. You don’t need to take our word for it—third-party tools like MxToolbox and Spamhaus confirm the importance of active MX validation as a standard step in email hygiene. A misconfigured server might respond to ping tests but reject actual mail. We catch that.

Scale verification without the risk

Let’s say you’re preparing a campaign for a 10,000-email list. Bulk verification through our bulk verification tool instantly identifies domains with misconfigured MX records—those that might appear valid in DNS but are dead ends in practice. These are the ones that’ll cause hard bounces, hurt your sender reputation, or trigger spam filters.

You can integrate this check directly into your workflow. Our integrations with Mailchimp, Klaviyo, and SendGrid allow you to validate email addresses just before sending. That means your campaigns start from a clean list—no surprises after launch. No more wondering why half your emails disappeared.

Whether you’re doing cold outreach or targeted campaigns, inbox placement isn’t just about content. It starts with domain readiness. That’s why every verification runs an inbox test. It tells you not just if an address exists—but if it’s actually deliverable. Use the inbox placement test to simulate how your message will land in real inboxes. You’re not just checking syntax. You’re testing delivery. And that’s not optional. It’s essential.

What happens if your MX preferences are incorrect?

If your MX preference values are set incorrectly—such as using the wrong priority order or pointing to a non-existent server—emails may be routed to the wrong mail server, fail to deliver, or be delayed. This can cause high bounce rates, harm your sender reputation, and increase the chance of messages being marked as spam. Proper MX configuration is essential for reliable email delivery.

Delivery failures and incorrect routing

You might think a single misaligned number won’t matter, but it does. Mail transfer agents (MTAs) rely on MX preference values to decide which server should receive messages first. If the order is wrong, your mail could end up on a backup server—especially if that server is offline or misconfigured. In extreme cases, emails may never be received.

For example, if you have multiple MX records like 10 mail.example.com and 20 backup.example.com, and the 20-priority server is unreachable or unreachable due to incorrect DNS propagation, incoming mail might not be delivered at all—especially if the higher-priority server also fails. This is why validating MX records with tools like MXToolbox is a recommended industry-standard practice.

Reputation risk and spam filtering

Consistently failing to deliver or routing messages to invalid destinations harms your sender reputation. ISPs and spam filters monitor delivery success rates and DNS health. A domain with mixed or missing MX records may be flagged as suspicious—even if you’re sending legitimate messages.

Spam filters often look for red flags like a single MX record with no backup, unresolvable domains, or conflicting DNS entries. These aren’t just technical quirks—they’re indicators of poor infrastructure. According to email deliverability guidelines from RFC 5321, mail servers must have valid MX records in place for reliable delivery.

Regularly testing your DNS setup—especially before sending campaigns—helps avoid these pitfalls. Use bulk verification tools to spot invalid or unreachable domains in your list. Pair that with real-time checks via the API to catch issues before they impact delivery.

Final tips for managing and monitoring your MX preferences

MX preference values dictate how mail servers prioritize delivery. Misconfigured preferences can result in delayed or failed delivery, even with valid records.

Review your MX records at least quarterly or immediately after infrastructure changes. This reduces the risk of overlooked misconfigurations that impact inbox placement and delivery reliability.

Best practices in action

Use DNS monitoring tools to detect outages, misconfigurations, or propagation delays before they affect mail flow.
Maintain a documented preference hierarchy based on server performance, redundancy, and uptime metrics.
Always test changes in a staging environment before applying them to production domains.

Even small errors in DNS can lead to significant delivery issues. Proactive management ensures consistent, high-volume mail delivery.

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 does an MX preference value of 0 mean?

It means the server is the highest priority for receiving email. Mail servers will try this one first.

Can multiple MX records have the same preference value?

Yes, but they are treated as equal priority. The sending server may choose any of them at random.

What happens if the primary MX server is down?

Mail servers will attempt the next-highest preference value in the list until one accepts the message.

Are MX preference values required to be consecutive numbers?

No. They only need to be numeric and ordered correctly. Gaps (e.g. 0, 10, 50) are valid.

How do I test if my MX preferences are working correctly?

Use a tool like Emaillistchecker.io to test inbox placement and real-time delivery behavior.

Why should I care about MX preference values if I use a third-party email service?

Even with a third-party provider, you must set the correct MX records with accurate preferences to ensure reliable delivery.

Do high MX preference values guarantee backup delivery?

No. They are only tried if higher-priority servers fail. If all fall back to a single high-value server, delivery risk increases.

Can MX preferences affect spam filtering?

Indirectly. Inconsistent or misconfigured MX records can raise red flags with spam filters due to poor infrastructure reliability.

Do MX preferences apply to outgoing mail?

No. They only apply to incoming mail. Outbound mail routing is governed by SPF records and sending behavior.

How often should I update my MX preference values?

Only when there is a change in server availability, location, or load balancing strategy.

Is it safe to change MX preferences during a campaign?

No. Changing MX preferences mid-campaign can cause message delivery delays or failures.

What is the default MX preference value if none is set?

The default is 0. Setting no preference value is not supported; a numeric value must always be provided.