MX Preference Values Explained | Emaillistchecker.io

Why MX preference values matter in email deliverability

You send an email campaign. It lands in spam, or worse—never arrives at all. You check the address. It’s valid. The domain exists. So why did it fail?

The answer often lies in something invisible to most: MX preference values. These numbers, tucked into DNS records, directly decide which mail server gets your message first. Get them wrong, and even a perfect email address hits a dead end. Understanding this mechanism isn't just technical trivia—it’s how you diagnose delivery failures and protect your sender reputation.

MX preference values explained for email deliverability analysis reveals why some domains fail silently, even with flawless syntax and clean lists. This isn’t about guesswork. It’s about routing logic that impacts inbox placement, bounce patterns, and long-term deliverability.

Key takeaways

MX preference values determine the order in which mail servers receive incoming messages, directly affecting delivery success.
Misconfigured MX preferences can cause delays or failures even with valid email addresses and proper authentication.
Checking MX preference alignment helps diagnose recurring bounces and supports healthier sender reputation over time.

How do MX preference values work in practice?

You can think of MX preference values as a priority list for email delivery. Each domain has one or more MX records, each with a number; lower numbers mean higher priority. When a sender tries to deliver mail, the receiving server first tries the MX with the lowest preference value. If that server is unreachable or rejects the message, it proceeds to the next one in order—up to five attempts total—before giving up.

Order matters: how delivery routes are chosen

Every mail server has a defined order based on these numeric preferences. An MX record with a value of 0 is tried first. If it’s down or unresponsive, the system moves on to the next lowest number—say, 5—then 10, and so on. This is standardized in RFC 5321, which governs how SMTP handles mail routing. The system is designed to keep delivery attempts efficient while supporting redundancy.

Let’s say your company’s domain has three MX records: one at 0, one at 5, and one at 10. The first attempt goes to the server with preference 0. If that server fails to respond within a timeout, the sender moves to the one at 5. If that also fails, it tries the one at 10. After five such attempts—each to a different server—the sending system may ultimately fail to deliver, unless a backup policy or retry mechanism is in place.

If you're running email campaigns, misconfigured MX settings can cause deliverability gaps. For example, if the lowest-preference server is overloaded or misconfigured, the next one might be ignored altogether due to the order. That’s why verifying the full set of records—and their current status—is critical. You won’t catch this with a simple "valid" check; you need to validate the actual mail server behavior.

Why this matters for deliverability analysis

MX preference values alone don’t guarantee delivery, but they’re a core part of the routing process. A single failed server on the top priority list can still let your message through—if the next preference is working. However, if all servers in the chain are unreachable or rate-limited, delivery fails.

That’s where tools like bulk email verification help. Instead of guessing which servers are online, they test the complete path by simulating real delivery attempts. They check not just if an email exists, but whether the associated MX records are actively accepting mail. This kind of insight goes beyond basic syntax checking.

For automated systems, integrating with a real-time verification API like EmailListChecker’s API lets you validate MX settings and server responsiveness in real time, helping avoid long-term delivery dead ends.

What happens when multiple MX records exist with different preferences?

When multiple MX records exist, mail transfer agents (MTAs) always try the one with the lowest preference number first. A record with preference 0 is attempted before one with preference 10, and so on. This allows you to prioritize your primary mail server and set up backups in a predictable way.

How MTAs Use Preference Values

Imagine your organization has two MX records: one with preference 0 pointing to your main mail server, and another with preference 10 pointing to a backup. When an email arrives, the sending MTA checks the DNS and immediately attempts delivery to the preference 0 server first. If that fails due to downtime or network issues, it moves to the next highest-priority record — in this case, the preference 10 server.

This is how redundancy and failover are managed at scale. You aren’t relying on a single point of failure. The system gracefully degrades, which is essential for consistent deliverability. This behavior is defined in RFC 5321, the core SMTP specification, and is followed by all modern mail servers globally.

Why MX Preference Matters for Deliverability

If you have misconfigured preferences — say, a backup server set to a lower number than your primary one — you risk routing mail to the wrong destination, even if your primary server is up. This can cause delays, bounces, or delivery to the wrong inbox.

It also affects how sending reputation is tracked. If your primary server is down and mail gets rerouted to a server with no history, the receiving server might flag it as suspicious or mark it as spam. That’s why setting up your MX preferences with redundancy in mind isn’t optional — it’s part of a robust deliverability strategy.

Use bulk verification to check the entire list of MX records across your domain and ensure they’re properly prioritized and active. It’s a quick way to catch misconfigurations before they impact your campaigns.

Preference is not about speed — it’s about order of attempt. 0 is always first, 10 is second, and so on.

You can test how your MX setup behaves using tools from reputable providers like MXToolbox or DNSStuff. These services show you exactly how your records are processed across the globe. Knowing that the lowest-numbered record is always tried first gives you control over reliability, failover, and ultimately, inbox placement.

Common misconfigurations that hurt deliverability

You’re not just choosing mail servers—you’re setting up a delivery roadmap. Misconfiguring MX preference values can cause routing chaos, delay messages, or trigger spam filters. Even one flawed record can lead to temporary bounces or inbox placement issues. Let’s fix what’s broken, starting with the most common pitfalls.

Incorrect or duplicate MX preference values

Setting multiple MX records with the same preference value (e.g., all set to 10) causes random routing. The receiving MTA picks one at random, which can delay delivery and degrade sender reputation over time.
Preference values above 50 are often ignored by modern message transfer agents (MTAs) like Google’s SMTP servers. This means backup mail servers simply won’t be considered, reducing redundancy and increasing the risk of message loss.
Missing or malformed MX records trigger temporary bounces (5xx errors) during delivery attempts. These errors may look harmless but can flag your domain as unreliable to filtering systems.

Why proper MX setup matters

Each MX record should have a unique, descending preference number—lower numbers mean higher priority. For example: 10, 20, 30, 50. This ensures clean, predictable routing.
Never assume all MTAs will handle duplicate preferences or high-values correctly. RFC 5321 (the SMTP standard) leaves this behavior implementation-dependent, so reliability falls on you.
The best practice is to keep your primary MX at 10, and secondary servers at progressive values, with no value above 50—many major providers like Microsoft and Gmail disregard anything beyond that.
Use tools like MxToolbox or RFC 5321 to validate your records and catch errors before sending.

Let’s be clear: even a single misconfigured MX record can cost you deliverability. You can’t trust your mail delivery to chance. Use bulk verification to spot broken domains, or our real-time API to validate records programmatically before they go live.

How to verify MX preference settings with real-world tools

You can verify MX preference values using command-line tools like dig or nslookup, then cross-check results with third-party DNS validators such as MxToolbox. These tools help ensure your MX records are logically ordered and publicly visible, which directly affects email delivery success. Consistent, correctly prioritized MX preferences reduce the risk of misdirected messages and improve deliverability outcomes.

Use command-line tools to inspect MX records

Open your terminal or command prompt. Run dig MX example.com to retrieve the MX records for a domain. This returns both the mail server hostname and the preference value (a number from 0 to 65535).
Look for multiple MX records. A well-configured domain often has at least two: one primary (lower preference number) and one backup (higher number). The lower the number, the higher the priority.
Verify the preference values are in ascending order: 0, 10, 20, etc. If they’re out of sequence, email clients may route messages to the wrong server or delay delivery.

Validate public visibility and consistency

Copy the output from your command-line query and paste it into a tool like MxToolbox or DNSChecker.org. These services cross-validate DNS records across global recursive resolvers, confirming your settings are consistent and visible to major ISPs.
Compare the results. If your local dig query shows a preference value of 0, but MxToolbox returns 100, that’s a red flag — it suggests your DNS zone isn’t propagating correctly.
Check for inconsistencies like duplicate hostnames, expired TTLs, or missing SPF/DKIM records, which can interfere with sender reputation and inbox placement.

Some deliverability issues stem from invisible or misconfigured MX settings — even a single incorrect preference value can cause delivery delays. Running these checks manually ensures you’re not relying on assumptions.

The 3 steps described in “Use command-line tools to inspect MX records”, in order.

For teams managing large lists, automating verification is faster. Bulk verification tools can test hundreds of domains at once, flagging malformed or inconsistent MX records before they impact your campaign performance. The same API enables real-time validation during onboarding or campaign setup.

“DNS configuration errors account for a significant share of email delivery failures — especially when preference values are missing or illogical.”

Tools like MxToolbox and DNSChecker.org provide transparency into how your domain is perceived globally. A domain that resolves one way locally but differently worldwide is a delivery risk. Always validate both internally and externally.

How email verification tools like Emaillistchecker.io detect MX issues

When you verify an email list, tools like Emaillistchecker.io don't just check if an address exists—they examine the domain’s MX records in real time. We look for unbalanced preference values, conflicting or missing MX entries, and misconfigured routing that could delay or block delivery. This detection happens before you send, so you catch problems before they impact your campaign performance.

Real-time MX validation during verification

Our verification API checks a domain’s actual MX configuration during every validation, not just from cached data. If a domain has multiple MX records with non-standard preference values—like two records both set to 10—it can confuse email routers and lead to delivery delays. We flag these anomalies immediately, letting you see which addresses are at risk due to infrastructure issues. This level of inspection goes beyond simple syntax checks and reveals real-world routing flaws.

Inbox-placement testing uncovers routing flaws early

Let’s say you’ve cleaned your list, but delivery still fails. The issue might not be the email—it could be how the domain routes inbound mail. Our inbox-placement testing simulates sending to real inboxes by working through actual mail servers. It exposes failures caused by MX misconfiguration—like improper preference settings or missing backup routes—before you launch a campaign. It’s like a dry run for deliverability, and it works with all major providers, including Gmail, Outlook, and Yahoo.

Some domains use non-standard MX preference values or omit backup servers entirely. This creates a single point of failure and increases the risk of bouncebacks or delayed delivery. The RFC 5321 spec outlines best practices for MX prioritization, and while not all providers enforce it strictly, consistent routing matters. You can learn more about standard configurations via the Internet Engineering Task Force (IETF) RFC 5321, which defines how SMTP handles mail routing.

For teams doing large-scale campaigns, our bulk verification process checks every email’s domain, including MX health. You can run this on your full list through our bulk verification tool. If you're integrating verification into your workflow, our real-time API checks MX infrastructure as part of every email validation. We also help find missing emails with our email finder, and track deliverability with our inbox placement tests.

The role of catch-all and role accounts in MX routing behavior

Catch-all mailboxes accept all incoming messages, even if the recipient doesn’t exist, which can mislead routing and expose domains to spam abuse. Role accounts like info@ or sales@ often rely on default MX settings that aren’t optimized for delivery, increasing the risk of delays or blacklisting. When all traffic is funneled through a single high-preference MX, it can create bottlenecks, especially under load. These routing patterns directly impact deliverability and should be evaluated during email list hygiene.

Catch-all mailboxes: convenience with hidden risks

Catch-all addresses are tempting for senders because they guarantee message delivery even if the exact recipient isn’t found. But this convenience comes at a cost: spammers exploit them to test valid addresses, leading to higher spam scores and potential blocklisting by major providers. Even if your domain uses a catch-all, it doesn’t mean every message sent there will end up in the right inbox. You should verify whether a domain uses a catch-all, as it often signals poor email infrastructure.

Some email verification tools, including bulk verification, detect catch-all patterns during list cleanup. This helps avoid sending to domains where your message might get flagged as spam or routed incorrectly. The best approach is to avoid relying on catch-alls and instead verify actual recipient addresses.

Role accounts and suboptimal MX configurations

Role addresses like support@ or admin@ are often treated as static endpoints, but they’re frequently backed by default MX records that aren’t optimized for delivery reliability. These MX records may point to older systems, shared hosting platforms, or non-secure gateways, reducing inbox placement rates. Worse, when all traffic for a domain—including transactional, marketing, and automated messages—relies on a single high-preference MX, it creates a single point of failure.

This setup can lead to delays or rejections, especially during peak sending periods. A strong deliverability strategy accounts for MX distribution: if a domain uses high-preference MXes for high-volume routes without redundancy, it’s a red flag. You can test how your email handles these routes with inbox placement testing, which checks real-world delivery across major inboxes.

For a deeper look at email infrastructure, the SMTP RFC 5321 defines how MX records and routing work at scale. It’s a baseline for understanding why routing behavior matters beyond simple address validation.

Does DMARC or SPF interact with MX preference values?

No — SPF and DMARC do not affect how MX preference values route email. MX records determine the mail server responsible for receiving messages, based on their numeric preference values. SPF and DMARC validate sender authenticity and domain alignment, which are separate from delivery path selection. While SPF failures don’t change routing, they can hurt sender reputation, indirectly affecting inbox placement.

How MX preference values actually work

When an email is sent, the sender’s mail server checks the recipient’s DNS for MX records. Each record has a preference value: lower numbers mean higher priority. The mail server tries to deliver to the highest-priority server first, then falls back to the next if that fails. This is purely about delivery path selection and doesn’t involve authentication methods like SPF or DMARC.

Why SPF and DMARC don’t alter MX routing

SPF (Sender Policy Framework) checks if the sending server is authorized by the domain’s SPF record. DMARC (Domain-based Message Authentication, Reporting & Conformance) validates alignment between the 'From' domain and authentication results. Neither touches the DNS-based MX decision-making process. The system is designed this way: routing decisions are independent of authenticity checks, allowing for layered security without blocking delivery.

But here’s the catch: if SPF fails, it can signal to receiving servers that the email might be forged, even if the MX record is perfectly valid. Over time, repeated SPF failures can degrade sender reputation. Reputable ISPs such as Gmail and Outlook use reputation signals to filter messages — even if the MX route is correct, poor authentication can land your message in spam or reject it outright.

For example, a domain with strict SPF policies but misconfigured sending IPs will fail DMARC alignment. The MX path still works, but the rejection isn’t due to routing — it’s because of trust signals. This is why a clean MX setup alone isn’t enough. You must ensure SPF, DKIM, and DMARC are all correctly set and verified.

Let’s say you’re managing a large email list — knowing your MX preference values is critical, but only one piece of the puzzle. You also need to validate that every address can actually receive messages and that your authentication setup is solid.

That’s where tools like bulk verification help. They check for invalid addresses, catch-alls, and risky domains before you send — reducing bounces and protecting your reputation. You can also run inbox placement tests to see how your messages perform in real inboxes, across platforms like Gmail, Outlook, and Apple Mail.

For more context on how these systems interlock, see the IETF’s DMARC specifications or RFC 7208 for SPF. They’re technical, but they clarify that routing and authentication remain separate layers in email delivery.

What should you do if you find invalid MX preference values?

If your DNS records show invalid MX preference values—like duplicates, gaps, or incorrect order—fix them immediately. Misconfigured MX preferences can cause mail routing failures, increase bounce rates, and harm sender reputation. Let's walk through the exact steps to correct them.

Check and correct your MX record priorities

Verify your DNS zone file and ensure the lowest-numbered MX preference (e.g., 0 or 5) points to your primary mail server. This ensures optimal routing by default.
Set backup mail servers with incrementally higher values—such as 10, 20, 50—to allow step-by-step failover if your primary server is unreachable. This prevents message loss during outages.
Remove any MX records with duplicate preference values. Having multiple MX entries with the same priority breaks routing logic and can lead to inconsistent delivery.
Do not skip numbers or use arbitrarily high values (e.g., jumping from 10 to 100). Use small, incremental steps so mail servers can reliably prioritize delivery.

Test and validate your changes

After updating your DNS records, validate the changes using tools like MXToolbox or RFC 5321, the standard defining SMTP behavior. Wait for DNS propagation—this can take up to 48 hours—and then verify inbox placement using real-world tests.

For large lists, use bulk verification to catch MX-related issues at scale. Our bulk verification tool checks for invalid MX records, catch-all detection, and deliverability risks across thousands of addresses in minutes.

How to use Emaillistchecker.io to test deliverability and catch MX issues

You can test email deliverability and uncover MX configuration issues by uploading your list to Emaillistchecker.io. The tool checks MX preference values, validates inbox routing, flags catch-all or risky addresses, and runs inbox-placement tests under real-world conditions. Our AI assistant then interprets results and guides fixes — all without requiring technical mail server access.

Upload your email list for bulk verification. Go to Emaillistchecker.io’s bulk verification tool and upload your list. The system checks each email for validity, catch-all status, and routing via MX records. It surfaces malformed addresses, role accounts (like admin@), disposable domains, and invalid formats — common sources of hard bounces.
Check MX preference values and routing configuration. The tool analyzes MX records, including preference (priority) values. Lower values indicate higher priority routing. Misconfigured MX preferences can delay delivery or cause routing failures. This is especially critical when managing multiple servers or backup routes. While RFC 5321 defines SMTP behavior, real-world delivery relies on correct MX priority alignment.
Run an inbox-placement test to simulate real delivery. Use the inbox-placement test to send test messages through the actual network paths used by major providers. This simulates what happens when your campaign runs — checking if messages land in the inbox, spam folder, or are rejected. It reveals issues like greylisting (temporary rejection), low sender reputation, or IP blocklists.
Use the in-app AI assistant to interpret and fix results. After scanning, our AI assistant breaks down the findings. It highlights why certain emails are risky (e.g., catch-all vs. non-existent), suggests which domains have outdated MX setups, and recommends actions. For example: "Domain has multiple MX records but no preference values set — this causes inconsistent routing." This reduces guesswork and speeds up remediation.

Why MX preference values matter in deliverability analysis

MX preferences determine which server receives mail for a domain. If values are missing or duplicated, mail can get routed incorrectly or delayed. Even minor misconfigurations — such as two MX records both set to priority 0 — can cause delivery issues. Tools like Emaillistchecker.io detect this early, before your campaign runs. You won’t see this in standard DNS checks, but it’s a known issue in email infrastructure and affects deliverability performance.

Integrate results into your workflow

Use the API at Emaillistchecker.io’s API to automate verification in your CRM, email platform, or marketing stack. This keeps your list clean in real time. Integrations with Mailchimp, HubSpot, Klaviyo, and SendGrid allow you to sync verified data directly — no manual work needed. Start with 100 free verifications at our pricing page — credits never expire.

Final thoughts: MX preference is foundational, not optional

Even with a strong sender reputation, misaligned MX preferences can prevent messages from reaching inboxes. DNS records must reflect actual mail server capabilities to ensure delivery.

Proactive verification ensures your outbound mail flow matches the recipient’s DNS configuration. This prevents avoidable bounces and maintains consistent inbox placement.

Tools like Emaillistchecker.io deliver 98.9% accuracy with real-time feedback, identifying issues before they impact deliverability. This level of precision is not optional for reliable email operations.

Sources

Deliverability experts classify a bounce rate under 1% as excellent, 1–2% as acceptable, 2–5% as concerning, and anything over 5% as dangerous for sender reputation. — Verified.email bounce rate benchmark (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 a good MX preference value to use for a primary mail server?

Use the lowest available number, typically 0 or 5. This ensures the primary server is prioritized during delivery attempts.

Can MX preference values be set to zero?

Yes — preference 0 is valid and commonly used for primary mail servers. It signals the highest priority.

Why does my email bounce even with a correct address?

MX misconfiguration — such as equal or high preference values — can cause delivery delays or failures, even with valid addresses.

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

Check that the lowest preference number points to your primary mail server, followed by incrementally higher values for backup systems.

Does DKIM depend on MX preference values?

No — DKIM signing is independent of MX routing. However, inconsistent DNS configurations can affect authentication checks.

Can a domain with no MX record still receive email?

No — a domain without any MX record will fail delivery. All domains must have at least one valid MX entry.

How does greylisting interact with MX preference values?

Greylisting delays delivery until a second attempt, which depends on MX routing. Poor MX ordering may prolong delays.

Is it safe to set multiple MX records with preference 10?

Not ideal. Multiple records with identical preferences create unpredictable routing and reduce resiliency.

How often should I audit MX preference settings?

Audit at least quarterly, especially after infrastructure changes, or when unexpected bounce patterns appear.

Can email verification detect MX preference errors?

Yes — a good verification service like Emaillistchecker.io checks DNS records during validation and flags misconfigurations.

Why are MX values important for cold outreach deliverability?

Even if your sender infrastructure is good, poor MX routing at the recipient’s end can cause delays or failures in outreach campaigns.

What happens if an MX record has a preference value above 50?

Most MTAs ignore preference values above 50, treating them as ineffective. Use lower values for operational servers.