Command Line Method to Verify MX Record Hierarchy for Domains

Why MX record hierarchy matters for email deliverability

You send emails. They don’t arrive. No bounce message, no error. Just silence. The culprit? A broken MX record hierarchy.

MX records are the postal code for your domain’s inbox. If they’re wrong, misplaced, or missing, email never reaches its intended server—leading to failed deliveries, higher bounce rates, and damage to your sender reputation.

Verifying the MX record hierarchy via the command line method ensures your mail is routed to the correct, active servers—before you send a single email.

Key takeaways

• MX records must be correctly ordered by priority to ensure reliable email delivery.
• Using the command line method to verify MX hierarchy gives real-time, precise feedback on DNS configuration.
• Incorrect MX records are a root cause of high bounce rates and poor inbox placement—especially in bulk email.

What happens when MX record hierarchy is misconfigured

If your domain’s MX record hierarchy is misconfigured, incoming email may be rejected outright, silently dropped, or routed to unintended destinations. This breaks email flow and can trigger spam filters that flag inconsistent routing as suspicious behavior. You’ll see delivery failures, bouncebacks, or no feedback at all—making troubleshooting harder. Tools like bulk email verification can help catch invalid or improperly configured addresses before they cause issues.

Rejected by the receiving server

When MX records point to non-responsive servers or missing mail exchangers, receiving mail servers will reject the message during the SMTP handshake. You'll get a permanent bounce—often with a 5xx error code. This typically means the domain has no functional mail server for the destination address, or the MX priority sequence is broken.

Messages sent to the wrong place or lost entirely

If the hierarchy uses unreachable or misordered MX entries, mail can be routed to backup systems that don’t accept it, or worse—silently dropped. No bounce is sent back to the sender, so you never know the message failed to deliver. This is common in organizations that misconfigure failover MX records or forget to remove outdated ones. According to RFC 5321, proper MX hierarchy ensures mail can be routed reliably even if primary servers are down. A misordered list breaks that expectation.

Even if the message reaches a server, inconsistent routing patterns—like sudden shifts between primary and backup MX servers—can trigger spam filters. Services like Spamhaus or Barracuda monitor these anomalies. If your domain exhibits erratic mail flow, your IP or domain reputation can degrade over time, especially when multiple receivers detect unreliable delivery patterns.

While you can diagnose MX hierarchy with command-line tools like dig or nslookup, validating the full chain of mail exchanger behavior requires more than syntax checks. A real-world test involves sending mail from known domains and tracking delivery. That’s where inbox placement testing comes in—one of the few ways to see if your configuration works in practice.

How to use the command line method to verify MX record hierarchy

You can verify MX record hierarchy using the dig command in a terminal. Run dig MX example.com to fetch all mail servers and their priorities. Check that the lowest-numbered (highest-priority) MX record resolves to a live server. Ensure no duplicate priorities exist, as this can cause inconsistent delivery. Finally, confirm each MX host responds to an SMTP HELO or EHLO handshake to validate reachability.

Step-by-step verification process

1. Open your terminal and ensure dig is installed. It's part of the ISC BIND suite and available on most Linux, macOS, and modern Windows environments via WSL or Git Bash.
2. Run dig MX example.com to retrieve all MX records and their priority levels. The output will list each host and its assigned priority (a number where lower means higher importance).
3. Verify the highest-priority MX record (lowest number) resolves to a valid, operational mail server. Use dig A or dig AAAA on the MX host name to confirm it resolves to a valid IP address.
4. Check for multiple MX records with identical priorities. This is common, but can lead to unpredictable routing. If you see duplicates, consider consolidating or adjusting priorities for clarity and reliability.
5. Test each MX host’s SMTP responsiveness. Use telnet or openssl s_client to connect to port 25 (or 587 for TLS) and send an EHLO command. A proper response confirms the server is accepting mail.

Why this matters for deliverability

MX records are foundational to email routing. A misconfigured hierarchy — such as a dead server, unbalanced priorities, or unreachable hosts — leads to delivery failures, increased bounce rates, and potential sender reputation damage. Proper MX validation ensures your emails reach the intended inbox, not a backlog or rejection queue.

Many senders overlook this step until they see high bounce rates or poor inbox placement. Tools like bulk verification can catch issues at scale, but validating the MX layer manually gives deeper insight into infrastructure health.

For real-time checks during campaign setup, consider automating with the email verification API. It includes DNS validation, MX checks, and catch-all detection — all behind a simple call.

Understanding MX record priority and routing order

MX records are processed in ascending order of priority number, with lower values taking precedence. If the primary server (lowest priority number) is unreachable, the sending mail server automatically tries the next highest-priority server. A well-structured hierarchy minimizes reliance on fallbacks by ensuring the primary MX server is consistently available and responsive.

The role of priority numbers in mail delivery

The priority field in an MX record isn’t a rank—it’s a number, and smaller values are tried first. For example, if you have MX records with priorities 10 and 20, the server with priority 10 is contacted first. This order is standardized in RFC 5321, the core specification for email delivery.

Let’s say your primary mail server goes down. Without a functioning fallback, delivery fails. But with a properly configured secondary MX (priority 20, 30, etc.), the sending server seamlessly tries the next available server. That’s the safety net in action.

Why routing order matters for reliability

Over-reliance on secondary MX servers often points to a misconfiguration or instability in the primary setup. If the main server is down, but the mail flow still works, it’s because the secondary is active. That’s fine temporarily—but it’s a signal to investigate the root cause.

For reliable inbox placement, you want the primary MX to be the one that receives and processes messages. A consistent, low-latency primary server ensures message delivery with minimal delay and reduces the chances of rejection by recipient systems.

You can verify the order and health of your MX records using command line tools like dig or nslookup. But automated validation is more effective at scale. Testing your list’s email addresses—including MX hierarchy—helps catch delivery issues before they impact your campaigns. Tools like bulk email verification can detect invalid, catch-all, or problematic MX configurations across thousands of addresses—ensuring you’re not sending to unresponsive servers.

Common pitfalls in MX record hierarchy setup

Setting up MX records isn’t just about listing servers—it’s about ensuring your email reaches inboxes reliably. The most common failures come from shared priorities, unqualified hostnames, or outdated records after a provider switch. These mistakes cause delivery delays, bounces, or silent drops—all avoidable with precise configuration and verification.

Incorrect priority assignment

• Assigning the same priority to multiple MX records creates load-balancing behavior, but doesn’t confirm if any server is actually available. This leads to undetected outages and inconsistent delivery.
• Always use unique priorities (e.g., 10, 20, 30) to define a clear failover path. Lower numbers win the priority, so your primary server should be lowest.

Using unqualified hostnames

• Using a hostname like mail instead of mail.example.com breaks DNS resolution. Most DNS resolvers treat unqualified names as local and fail silently.
• Always include the full domain suffix in MX records. A misconfigured record may pass syntax checks but never resolve, causing emails to be rejected or dropped.

Outdated records after provider change

• When switching email providers, old MX records often remain in DNS. This causes delays, greylisting, or outright rejection, especially if the new provider doesn’t accept mail for the old domain.
• Even a one-day delay in updating MX records can result in a 15–20% drop in delivery rates during the transition, according to industry data from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG).
• Verify the full DNS chain—including DNSSEC and TXT records—after any change. A single misconfigured record can break delivery, even if everything else appears correct.

Use a tool like bulk email verification with real-time DNS checks to spot these issues before sending. Many tools only check syntax; Emaillistchecker.io validates the full resolution chain, including MX, SPF, and DKIM, so you catch problems early.

Let’s not assume your setup works. Confirm it.

How to verify MX record reachability beyond DNS

Use telnet or nc to test if the mail server behind an MX record responds on port 25 or 587. A successful connection with a proper SMTP banner confirms the server is online and listening. No response means the MX is valid in DNS but the server is unreachable or misconfigured—common with overloaded systems, firewall blocks, or incorrect routing.

Step-by-step: Verify SMTP server reachability

1. Open your terminal and run telnet mail.example.com 25 (replace with your target mail server). If telnet isn't available, nc -z mail.example.com 25 works similarly. This tests if the mail server accepts inbound SMTP connections.
2. Observe the response. A valid server should return a banner like 220 mail.example.com ESMTP. This confirms the server is operational and ready to process mail, not just resolvable via DNS.
3. If you get a timeout or connection refused, the MX record may be correct, but the server is down, blocked by a firewall, or not accepting incoming connections. This happens routinely with shared hosting, greylisting setups, or temporary outages.
4. Try testing on port 587 (submission) for modern setups. Many modern servers no longer accept connections on port 25 unless they're authenticated. A response on 587 means the server is configured for secure, authenticated sends—common in business email services.

Why this matters beyond DNS lookup

Checking the MX record in DNS only tells you where mail should go. It doesn’t confirm whether the server actually answers or accepts mail. This step fills a critical gap: you’re validating real-time reachability, which is essential for deliverability. A server may be technically correct in DNS but offline, blacklisted, or rate-limited—common issues that cause bounces even with valid addresses.

According to RFC 5321, the SMTP protocol requires servers to respond to connection attempts with a 2xx code before processing any commands. Failure to do so is a red flag. Tools like MxToolbox or Spamhaus offer broader diagnostics, but telnet is the simplest, most direct way to spot server-level issues.

For teams sending at scale, combining DNS-level validation with live SMTP reachability testing improves inbox placement and reduces bounce rates. The difference between a valid MX and a responsive one can mean the difference between delivery and hard failure.

When manually auditing large lists, tools like bulk verification automatically check DNS records, SMTP responsiveness, and common validity flags—saving hours of manual telnet testing per domain.

The role of reverse DNS (PTR) in MX verification

Reverse DNS (PTR) must match the domain in your MX record to ensure deliverability. If the IP address of your mail server doesn’t have a PTR record pointing to your sending domain, most receiving servers will reject your email—even if your MX, SPF, and DKIM records are correct. This is a common but fixable cause of failed email delivery.

Why PTR alignment matters

When a mail server receives an email, it checks the sender’s IP address against its reverse DNS lookup. The result must match the domain used in the MAIL FROM (envelope from) field. If it doesn’t, the server assumes the email might be spoofed or sent from a misconfigured server.

Let’s say your MX record points to mail.example.com, and your mail server runs on IP 192.0.2.1. The PTR for 192.0.2.1 must resolve to example.com—not some unrelated domain. Misalignment here triggers spam filters, especially on servers using strict policies like those at Google or Microsoft.

Common consequences of ignoring PTR

Even with correct MX and SPF records, a mismatched PTR can lead to immediate rejection or placement in spam. Many large providers use this as a basic check before even evaluating content or reputation. You might pass all DNS checks but still fail to land in inboxes.

According to the RFC 5321 standards, which define SMTP behavior, PTR validation is not mandatory but widely implemented. The practice is so common that ignoring it is akin to skipping a fundamental security gate. A 2020 study by Return Path noted that alignment issues like these contribute to up to 20% of deliverability problems in transactional email.

Use tools like bulk email verification to catch this early. It checks not just MX records but also validates the underlying infrastructure, including reverse DNS—before you send to thousands of recipients.

How email verification tools can complement command line checks

You can automate the verification of MX record hierarchies across thousands of domains with tools like Emaillistchecker.io, which scan for missing, misordered, or incorrectly configured MX records at scale. This complements manual command line checks by turning a time-consuming process into one that runs silently in the background, flagging issues across entire email lists with consistent accuracy.

Scaling DNS validation beyond the terminal

While command line tools like dig or nslookup let you check individual domains, they’re impractical for large lists. You’d need to run dozens of queries manually, and even then, you’d risk missing subtle issues like conflicting MX priorities or missing fallback records. Emaillistchecker.io handles this by processing bulk domains automatically, verifying every layer of DNS hierarchy — including MX, SPF, and DKIM — in a single pass.

It identifies problems such as invalid MX records, records with duplicate priorities, or domains with no MX entry at all. These issues are common in poor-quality lists and directly impact deliverability. According to the RFC 5321 specification, an MX record is required for any domain expected to receive email, and its absence or misconfiguration is a top reason for email rejection.

Reducing manual effort with reliable automation

Instead of checking each domain one by one, you upload a list and let the tool validate the entire hierarchy in minutes. It reports back with a clear breakdown: valid, invalid, catch-all, or risky — all based on real-time DNS responses and known patterns from sender reputation data. This consistency beats human error and ensures every domain is tested under the same conditions.

For teams using Mailchimp, HubSpot, or SendGrid, Emaillistchecker.io integrates directly through its [integration hub](https://www.emaillistchecker.io/integrations), letting you clean your lists before every campaign. And if you need real-time verification, the [API](https://www.emaillistchecker.io/api) lets you validate email addresses as they’re entered, stopping invalid entries at the source.

The tool also verifies inbox placement, simulating delivery to major providers and detecting filtering behavior. Combined with full DNS checks, this gives you a complete picture of deliverability risk — something a command line check alone can’t deliver.

Real-time verification API: a better alternative to command line for teams

You don’t need to manually run dig MX for each domain in your list. Emaillistchecker.io’s real-time verification API checks MX record hierarchy across hundreds of domains in seconds, returning structured data on priority order, server reachability, and DNS resolution status — all without a single command-line script.

Scale beyond CLI limitations

Running dig or nslookup repeatedly is slow and error-prone when verifying dozens of domains. Each command returns raw DNS output that requires manual parsing. By contrast, the API automates this at scale, returning machine-readable results you can process in your workflow — no scripting needed.

Deeper insight than raw command-line output

Instead of seeing a list of MX servers, the API tells you if they’re actively reachable, what priority they’re assigned, and whether DNS resolve correctly. This structured data reveals delivery readiness faster than any CLI command can. For example, you can quickly identify domains with misordered MX records or unreachable mail servers — common red flags in email deliverability.

This isn’t just about checking records. You’re validating the entire inbound email path. As RFC 5321 outlines, proper MX hierarchy is foundational to reliable email delivery. But the real value comes when you correlate this data with other factors like sender reputation and domain authentication — which an API can automate alongside MX checks.

Use the email verification API to scan large lists, integrate with your CRM, or feed results into your onboarding pipeline. It’s built for teams that need consistent, reliable insights — not just isolated command-line outputs.

In practice, teams move from guessing to acting. You’re not just testing DNS. You’re validating the full delivery chain, one domain at a time, at speed. Whether you're managing a customer list, auditing partner domains, or preparing a campaign, this API delivers clarity where the CLI leaves you stuck in a loop of manual checks.

Integrating MX verification into your email list hygiene process

You can catch deliverability risks early by verifying MX records during domain validation. Use the command line method to check MX hierarchies as part of your email list acquisition workflow. Domains with outdated, unreachable, or misconfigured MX records increase bounce rates and hurt sender reputation. Eliminating these addresses before sending improves inbox placement and reduces spam complaints.

How to make MX verification part of your process

• Run a DNS MX lookup on every domain before adding it to your list—use dig MX example.com or nslookup -type=mx example.com to check the hierarchy and response order.
• Check for empty, obsolete, or inconsistent MX records (e.g., domains pointing to mail.example.com that doesn’t resolve or lacks A records).
• Look for domains with only a single MX record and no backup—if that one server is down, delivery fails. Prioritize domains with multiple, reachable MX records.
• Flag domains with MX entries pointing to non-responding servers or blacklisted IPs—tools like MxToolbox can help confirm if a mail server is reachable.
• Use automated checks in your verification pipeline. Tools like bulk verification include DNS-level validations, including MX hierarchy checks, to flag risky domains before you send.

Why this prevents real deliverability issues

Mail providers like Google and Microsoft evaluate sender reputation based on how consistently emails reach valid inboxes. A single misconfigured MX record can cause temporary or permanent failures, which are tracked as delivery anomalies. Over time, recurring failures hurt your sender score. By checking MX records at acquisition, you block domains that will never deliver.

The RFC 5321 specification defines the expected behavior of mail servers during DNS-based routing. Misconfigured MX records violate this standard and are often flagged automatically by receiving systems.

According to industry data, domains with unresolved or unreachable MX records have a 40%+ higher chance of being filtered or bounced compared to those with validated configurations. This isn’t about volume—it’s about reliability.

Let’s not assume every domain is valid. Let’s verify the basics—starting with the MX record hierarchy—before trusting the email address. If the path to delivery is broken at the first step, the message won’t arrive, no matter how clean the content.

Summary: command line verification as a diagnostic tool, not a workflow solution

The command line method using dig or similar tools gives precise, real-time insight into MX record hierarchies for individual domains. It’s reliable for validating server configurations and troubleshooting deliverability issues on a case-by-case basis.

However, it lacks scalability. Manually checking hundreds or thousands of emails with dig is impractical and error-prone. For consistent list hygiene and long-term deliverability, automated verification is necessary.

Use dig to diagnose specific issues — a failed MX lookup, a misconfigured domain, or a routing anomaly. Then, enforce quality at scale with tools like Emaillistchecker.io, which integrates with your email platform and maintains inbox placement through continuous validation.

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)
• By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)

Keep reading

• Free email checker tools: syntax, MX, SMTP, disposable and catch-all checks (complete guide)
• Content-Based Filtering Advantages for Verifying Temporary Email Addresses
• Google Workspace Routing Rules to Redirect Invalid Emails to a Catch-All
• Using dig to Check MX Record Configuration for Email Delivery
• Verdict Caching Time for Disposable Email Addresses by Domain in 2026

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I verify MX record hierarchy with just `dig`?

Yes, `dig MX domain.com` shows the MX records and their priorities, but it does not confirm server reachability or SMTP response. Additional tools are needed for full validation.

What is the highest priority MX record?

The MX record with the lowest priority number (e.g., 0 or 1) is processed first. A lower number means higher priority.

Why does my email bounce when MX records seem correct?

MX records may resolve correctly but point to a server that is offline, misconfigured, or lacks proper reverse DNS. Check server reachability and PTR records.

Can MX records point to a subdomain?

Yes, MX records can point to subdomains like mail.example.com, as long as the subdomain resolves to a valid IP address and supports SMTP.

How often should I verify MX record hierarchy?

Verify MX records when onboarding new domains, changing email providers, or after network outages. Automate checks for recurring validation.

How does a missing MX record affect email delivery?

A missing MX record results in immediate rejection of incoming emails. Receiving servers typically reject messages with a permanent failure unless they fall back to other methods.

What happens if two MX records have the same priority?

The sending server selects one randomly. This may lead to inconsistent delivery and reduced reliability, especially if one server is offline.

Are domain-based email providers less reliable with MX configuration?

Some providers simplify MX management, but manual errors can still occur. Always validate the resulting record hierarchy.

Can I fix MX hierarchy without using the command line?

Yes. Most email hosting providers offer web-based DNS management tools to update MX records without command-line access.

Does Emaillistchecker.io verify MX record hierarchy?

Yes. The service checks MX records as part of its domain validation and returns detailed results including priority order, reachability, and DNS status.

Does MX verification help with spam filtering?

Indirectly. A correctly configured MX hierarchy is part of sender authentication. Misconfiguration can trigger spam filters and harm domain reputation.

Can DNS caching affect MX record checks?

Yes. DNS resolvers cache records for their TTL duration. Use `dig +short` or `dig +noall +answer` to reduce the chance of outdated results.