Using dig to Check MX Record Configuration for Email Delivery

Why MX Record Failures Cause Email Delivery Failures

You send an email. It vanishes into the void. No bounce, no error—just silence. You check your logs. Everything looks fine. But the recipient never sees it. The culprit? An MX record misconfiguration you never noticed.

MX records are the postal code for your domain’s email. They tell the internet: “Mail for this domain goes here.” If they’re wrong—missing domains, incorrect priorities, expired TTLs—email delivery collapses before it even starts.

Even tiny flaws break deliverability. You can’t fix what you can’t see. That’s why checking your MX record configuration using dig is not optional—it’s essential for consistent inbox placement and sender reputation.

Key takeaways

• MX record misconfigurations are a leading cause of undelivered emails, even when sender reputation and content are sound.
• Using dig to verify your MX record configuration ensures your mail server is properly advertised to the global email infrastructure.
• Monitoring MX records regularly prevents unexpected delivery failures, especially after DNS changes or server migrations.

Using dig to Check MX Record Configuration for Email Delivery

You can use the dig command to verify that your domain’s MX records are correctly published in DNS, ensuring incoming email reaches the right mail servers. This checks both the existence and accuracy of the configuration your mail server relies on. It’s a fast, reliable way to catch routing issues before they cause delivery failures.

How to Verify MX Records with dig

1. Open your terminal or command prompt. You’ll need access to a system with dig installed—available by default on most Linux, macOS, and many Unix-like systems.
2. Run dig MX yourdomain.com. Replace yourdomain.com with your actual domain. This queries the DNS for the Mail Exchange (MX) records associated with that domain.
3. Check the output for the correct priority and target. A valid response includes one or more MX entries with priority values (like 10, 20) and the hostname of the mail server (such as mail.yourdomain.com).
4. Validate that the target server is reachable. Look for a corresponding A or AAAA record for the mail server hostname. If dig returns an empty or incorrect value, your MX record may be missing, misconfigured, or delayed in propagating.
5. Compare with your mail server’s configured settings. Discrepancies between your DNS and your mail server setup can cause email to be rejected or routed incorrectly.

MX records are part of the core email delivery infrastructure. According to RFC 5321, the standard for SMTP, MX records direct incoming email to the correct server. If they're misconfigured, messages may be rejected outright by the receiving server.

Why This Matters for Deliverability

Even minor errors—like a typo in the domain name or an expired or unreachable mail server host—all lead to failed deliveries or higher bounce rates. Using dig gives you visibility into the actual DNS state, not just what you think is configured.

You can also use inbox placement testing to see how your emails perform in real inboxes after verifying the infrastructure. This layer confirms that your DNS setup isn't just correct, but also trusted by major providers.

For a quick check, bulk verify your email list to catch invalid, outdated, or non-deliverable addresses early. Many bounce issues originate from incorrect DNS records, so verifying your configuration is a strong first step in reducing delivery failures.

Step-by-Step: Running dig to Query MX Records

You can validate your email delivery setup instantly by using the dig command to query MX records. Run dig MX yourdomain.com in your terminal, then check the ANSWER SECTION for valid mail server priorities. Confirm the hostname resolves to an actual IP via an A record lookup—this ensures your domain’s email routing is configured correctly and reduces the risk of bounces or delivery failures.

1. Open your terminal or command prompt. You need access to a system with dig installed—available on Linux, macOS by default, or via Windows Subsystem for Linux (WSL).
2. Enter: dig MX example.com. Replace example.com with your actual domain. This queries the DNS system for your domain’s mail exchange records, which determine where incoming email should be routed.
3. Look for the ANSWER SECTION. This section lists all MX records assigned to your domain, each with a priority number and mail server hostname. For example: 10 mail.example.com. Lower numbers indicate higher priority.
4. Check that at least one record has a valid mail server hostname. A hostname like mail.yourdomain.com should exist in DNS. If you see example.com or a placeholder, your DNS setup may be incomplete.
5. Confirm the hostname resolves to an IP address. Use dig A mail.example.com to check that the hostname in the MX record resolves to a real IP address. If it’s missing or fails, your mail server won’t accept incoming email.

Why This Checks Matter

MX record misconfiguration is a top cause of email delivery failure. According to industry data from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), improperly set or unreachable mail servers lead to 15–30% of outbound email being rejected at scale. Validating the full path—MX record to A record resolution—is a foundational step in maintaining sender reputation.

When to Run This Test

Use this check when setting up a new domain, troubleshooting failed deliveries, or auditing your email infrastructure. It’s part of the broader practice of DNS health checks, which also include SPF, DKIM, and DMARC verification.

For teams managing large lists, automating these checks can prevent thousands of bounces. Tools like bulk email verification services can identify invalid or misconfigured domains at scale, helping you maintain a clean sender reputation and avoid blocklists.

What to Look for in a Valid MX Record Response

When using dig to check MX record configuration for email delivery, look for a priority value (lower is better) and a valid host name that resolves to an A record. Multiple MX records with different priorities improve reliability, and TTL values should be current—no expired or excessively long TTLs to avoid caching delays during DNS changes. A well-configured MX chain ensures your messages reach their destination without routing breaks.

Core Elements of a Working MX Record

• Priority number (e.g., 10, 20, 30) — lower values mean higher preference. A single MX with a priority of 10 doesn’t guarantee delivery if the server is down; multiple records with varying priorities offer fallback options.
• Hostname (e.g., mail.example.com) — this must resolve to an actual IP address via an A record or AAAA record. If the host name doesn’t resolve, the MX is useless, even if the record itself appears valid.
• Multiple MX entries — having two or more records with different priorities improves redundancy. If the primary mail server fails, mail flows to the next preferred one.
• TTL (Time to Live) should be in the normal range (e.g., 300 to 3600 seconds) — too low increases DNS load, too high delays changes. Avoid TTLs set years in the future or ones that have expired (e.g., past the current date in your DNS tools).

Verification and Real-World Testing

Even with correct DNS records, email delivery can fail for other reasons. For example, a missing SPF record or a misconfigured DKIM can still result in messages being marked as spam or rejected. Use tools like bulk email verification to confirm that your list’s domains are both technically sound and deliverable — this process checks MX records, catch-all behavior, and more in one workflow.

Dig is your first line of defense in troubleshooting delivery issues, but it’s only half the picture. The inbox placement test simulates real-world filtering behavior across major providers—Gmail, Outlook, Apple Mail—to show whether your emails would actually land in the inbox or be quarantined. This helps catch issues that DNS checks alone can’t detect.

For developers or admins, validating DNS configurations with our real-time verification API adds automation and scale. It checks MX, SPF, and DKIM records on demand, with consistent accuracy across domains.

According to RFC 5321, the Simple Mail Transfer Protocol defines how email routing via MX records should work. It specifies that mail transfer agents must attempt delivery in order of priority and retry lower-priority servers only if higher-priority ones are unreachable. This standard underpins why a proper MX hierarchy isn't optional—it's required for reliable delivery.

Common MX Record Errors Detected with dig

Using dig to check MX records reveals issues that break email delivery: no MX records, broken server pointers, missing priorities, duplicate entries, or overly low TTL values. These mistakes prevent mail servers from routing messages correctly. Let’s walk through the most common ones and why they matter.

No MX Records or Invalid Server Targets

If dig mx example.com returns no records, incoming mail has no destination — delivery fails. This is often caused by a missing MX record or a typo in the DNS zone. Even if an MX record appears, it must point to a valid domain with a matching A record. If the domain doesn't resolve or lacks an A record, email delivery fails silently until the DNS is fixed.

For example, an MX record pointing to mail.example.com but no A record for that host breaks routing. You can test this with dig A mail.example.com. If it returns no answer, you’ve found a broken chain. This is a common root cause of undeliverable messages.

Priorities, Duplicates, and Poor TTL Settings

Each MX record must have a priority number — lower numbers mean higher priority. Missing priority fields trigger syntax errors that DNS validators reject. You can check this with dig mx example.com and verify all entries have a number (e.g., 10 mail.example.com).

Duplicate entries or priority numbers over 100 are unusual and may cause delivery delays. Some MTAs treat high-priority numbers as fallbacks, but excessively high values (e.g., 1000+) can be ignored. While not always wrong, they’re a red flag for misconfiguration.

TTL (Time to Live) set below 300 seconds forces frequent DNS lookups. This increases load on your server and can delay message routing, especially during outages. A TTL of 300 seconds (5 minutes) is a standard baseline. Setting it too low — like 60 seconds — causes unnecessary overhead, especially on large lists or high-volume sends.

For a deeper look at how DNS configurations affect deliverability, the Internet Engineering Task Force (IETF) outlines MX record best practices in RFC 5321.

Even with correct MX records, real-world email delivery depends on broader factors like sender reputation and inbox placement. You can test this end-to-end with inbox placement testing, which simulates delivery across major providers.

How dig Integration with Emaillistchecker.io Enhances Deliverability

Using dig to check MX record configuration is a foundational step in email deliverability — but Emaillistchecker.io goes beyond basic DNS lookup by embedding those checks into real-time email verification. It validates MX records in live DNS queries, identifies misconfigurations or missing records before you send, and combines this with live SMTP testing across real inboxes, reducing bounces and protecting sender reputation.

Real-Time DNS Validation Prevents Pre-Send Failures

Let’s be clear: sending emails to invalid or misconfigured domains wastes bandwidth, harms deliverability, and damages reputation. Emaillistchecker.io performs real-time DNS checks — including MX validation — during every verification. This isn’t just a one-off scan; it’s a continuous assessment that detects malformed or missing MX records the moment you upload a list.

You don’t need to run dig manually for each address. The tool does it for every email in your list, catching issues like non-existent domains, incorrect MX records, or DNS propagation delays. This reduces hard bounces before they happen.

Bulk Verification Meets Inbox Reality

What truly separates Emaillistchecker.io is how it combines DNS-level checks (like those from dig) with live SMTP validation across thousands of real inboxes. You get a realistic prediction of inbox placement — not just a “valid” or “invalid” result, but a clear signal of whether an email will land in the inbox, spam, or be blocked.

This dual-layer approach means your sender reputation stays intact. According to industry standards, consistent hard bounces (even 0.1%) can trigger filters at providers like Gmail and Outlook. By catching invalid configurations early, Emaillistchecker.io helps you avoid those pitfalls. The validation process uses industry-standard protocols and follows guidelines outlined in RFC 5321 and RFC 5322 for SMTP transaction handling.

See how it works end-to-end: verify a list in bulk and immediately see which domains are ready to receive. The tool also supports automated workflows via the real-time verification API, integrating directly into your CRM, ESP, or email platform. You can run a pre-send check on a list of 10,000 addresses in minutes — all while protecting your sending infrastructure and inbox placement performance.

Why Manual dig Checks Aren’t Enough for Campaigns

Running dig to check your MX records confirms DNS configuration, but it doesn’t tell you if emails actually land in inboxes. Even with perfect DNS, spam filters, blacklists, or weak sender reputation can block delivery. You need real-time inbox placement testing to see if messages reach recipients’ inboxes — not just DNS servers.

dig Only Confirms DNS, Not Delivery

You can validate an MX record with dig and still have emails rejected or buried in spam folders. The tool shows what your DNS says — not whether the receiving mail server accepts the message. It’s like checking if a door is unlocked in a building, but not whether the occupant will let you in.

For example, a domain may have correct MX records but still be on a spam blacklist like Spamhaus, or have its sender reputation severely damaged. These issues are invisible to dig. Mail delivery isn't just about DNS — it's about reputation, content, engagement, and authentication (SPF, DKIM, DMARC).

Real Inbound Results Require Real Tests

Only inbox placement testing simulates actual delivery scenarios across real email providers. You send test messages to known inboxes (Gmail, Outlook, Yahoo, etc.) and track if they land in the primary inbox or are filtered. This gives measurable proof of deliverability, not just DNS compliance.

Spam scoring systems used by providers like Google and Microsoft evaluate sender history, engagement rates, and list hygiene — none of which dig can assess. According to industry reports from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), over 30% of emails fail to reach inboxes due to reputation or filtering issues, even with correct DNS settings.

That’s why combining DNS checks with tools like inbox placement testing gives the full picture. You can verify DNS with dig, then test actual delivery outcomes at scale. For ongoing campaigns, this means fewer bounces, lower spam complaints, and measurable delivery success — not just theoretical correctness.

Using bulk email verification alongside inbox tests helps you catch invalid addresses, risky domains, and role accounts before sending. It’s a layered defense: validate DNS, clean your list, then test real delivery. The result? More messages landing where they’re meant to — in the inbox.

Verifying MX Records Across Multiple Domains in Bulk

You can’t manually check MX records for thousands of domains with dig without wasting days. Bulk tools like Emaillistchecker.io automate the process, scanning DNS records at scale to verify MX configuration, priority order, and A record resolution across entire domains lists. This catches misconfigured or non-existent email setups before campaigns go live.

Why Manual Checks Fail at Scale

Running dig MX example.com on hundreds of domains is tedious and error-prone — you’ll miss patterns, skip records, or misread results. It’s not just time-consuming; it’s inconsistent. For list hygiene, you need reliability across every domain, not a few spot checks.

Automated Verification at Scale

Tools like Emaillistchecker.io don’t just run dig over and over — they interpret the output, flag broken DNS chains, check MX priority order, and validate that corresponding A records resolve. If a domain lacks an MX record, has multiple MX entries with conflicting priorities, or points to a non-routable IP, the system surfaces it immediately. This is how you prevent delivery failure before sending.

These tools also detect common red flags: domain spoofing patterns, disposable email domains, or catch-all setups that inflate deliverability risks. You don’t need to guess if an email is valid — the system checks whether the domain’s DNS infrastructure supports real delivery.

Industry standards — including RFC 5321 and RFC 5322 — define how mail servers should route and accept messages. A domain with no MX record, or an MX pointing to a defunct or blacklisted IP, violates these standards and will fail. DNS health is foundational to deliverability, and automated validation keeps you compliant.

Let’s say you’re preparing a high-volume email campaign. You have 10,000 domains in your list. Manually checking any subset is pointless. But running them through a bulk verification service gives you a full health report: which domains have valid MX records, which have misconfigured priorities, and which fail A record resolution. You correct or remove these before sending.

As RFC 5321 outlines, MX records are the core of email routing. Without them, messages can’t find a delivery path. Tools that verify this at scale aren’t just convenient — they’re necessary for reliable deliverability.

For teams running repeated campaigns or managing large lists, automation is non-negotiable. With Emaillistchecker.io, you can verify thousands of domains in minutes, spot configuration issues, and maintain sender reputation by only sending to domains with proper DNS setup.

Best Practices for Maintaining MX Record Health

Regularly checking MX records with tools like dig helps you catch misconfigurations before they disrupt email delivery. You should verify MX records quarterly, or right after any DNS change, to ensure your domain’s mail routing remains consistent and resilient. A solid MX setup prevents delivery failures and maintains sender reputation.

Monitor and Verify Your MX Configuration

• Check MX records at least every 3 months using dig mx yourdomain.com or similar DNS tools to confirm they’re active and correctly prioritized.
• Always validate DNS changes immediately after updating MX records to avoid routing delays or mail loss.
• Use a tool like bulk email verification to test if domains in your list still route mail properly, especially after major infrastructure updates.

Design a Resilient MX Setup

• Use at least two MX records with different priorities (e.g., 10 and 20). This setup ensures that if one server is unreachable, mail routes to the backup.
• Avoid relying on a single MX record—this creates a single point of failure. Even a minor outage on that server can disrupt all inbound delivery.
• Keep your primary MX server as reliable as possible, but always plan for redundancy. The RFC 5321 standard for SMTP emphasizes handling delivery failures gracefully—your setup should mirror that principle.
• Document every MX change in your internal systems. Include dates, responsible parties, and the purpose of the change. This supports auditing and helps debug issues later.
• Track changes over time using DNS monitoring tools or logs. You can also use email verification API integrations with your mailing system to auto-validate domain health post-change.
• Never assume your MX records are correct just because they worked last week. They can change due to misconfigurations, service transitions, or third-party errors.

For a comprehensive view of how your email infrastructure performs, test inbox placement using inbox placement testing—it reveals how your messages fare across real email providers, including spam filters and routing gates.

Remember: MX record health isn’t a one-time task. It’s part of ongoing email delivery maintenance. Let’s treat DNS like infrastructure—monitor it, verify it, and adapt it.

How Emaillistchecker.io Integrates with Delivery Workflow

You can connect Mailchimp, SendGrid, HubSpot, or Klaviyo directly to Emaillistchecker.io, automatically verify every email in your list before sending, and catch domains with broken MX records—preventing bounces and protecting your sender reputation. Verification happens in real time, before each campaign runs, without interrupting your workflow.

How It Works in Practice

1. Connect your email service provider—Mailchimp, SendGrid, HubSpot, or Klaviyo—directly through our integrations hub. No API keys to manage manually. Once connected, your campaigns flow seamlessly into the verification step.
2. Trigger verification before each send. Every time you launch a campaign, Emaillistchecker.io runs a full check on every email address, including DNS-level validation like MX record presence and reachability.
3. Get real-time feedback on record health. If a domain lacks an MX record, has a malformed one, or is unreachable, the system flags it as invalid before you send. This stops delivery failures at the source, not after they happen.
4. Remove bad addresses automatically. Validated lists are cleaned in place—addresses with missing or unreachable MX records are excluded. This directly reduces your bounce rate and protects your sender reputation, which is tracked by third-party services like Spamhaus and MxToolbox.
5. Send only to addresses ready to receive. Once the list is verified, you send to a clean audience—every address has a working inbound path. This improves inbox placement, especially when combined with proper SPF, DKIM, and DMARC setup.

Why This Matters for Deliverability

MX records are the foundation of email delivery. If a domain’s MX is missing or misconfigured, mail servers reject messages—even if the email address is correct. According to RFC 5321, MX lookup is a mandatory step in SMTP delivery. Letting those failures pass into your campaign creates hard bounces, harms reputation, and risks blacklisting.

Emaillistchecker.io catches these issues before you send. You’re not just checking syntax—you’re validating delivery infrastructure. This is the difference between sending to a list and sending to a list that’s actually ready to receive.

For deeper testing, you can also use our inbox-placement testing to confirm your messages arrive in inboxes, not spam folders, across major providers.

Conclusion: dig is a Foundation, but Verification is the Proof

Using dig to check MX record configuration is a necessary step in diagnosing email delivery issues. It confirms DNS setup is correct and helps rule out basic misconfigurations.

But a proper MX record does not guarantee inbox delivery. Valid DNS records can point to a catch-all address, a role account, or a blacklisted domain — all of which may still cause bounces or deliverability problems.

For reliable email delivery, validation must go beyond DNS. Combine dig checks with real-time email verification and inbox-placement testing. This full chain ensures only deliverable, active addresses are used.

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)
• Validity's analysis of 22+ million domains found 84% of domains used in email From addresses have no published DMARC record at all. — Validity (2024)

Keep reading

• Free email checker tools: syntax, MX, SMTP, disposable and catch-all checks (complete guide)
• Creating Test Scenarios with Invalid Email Syntax for Debugging
• Why Some Accept-All Domains Cause Email Verification Tools to Fail
• Economic Analysis of Per-Check vs Monthly Email Verification for SaaS
• Content-Based Filtering Advantages for Verifying Temporary Email Addresses

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

Frequently asked questions

What does dig MX mean?

dig MX is a command that queries DNS to retrieve mail exchange (MX) records for a domain, revealing how email is routed.

How do I check MX record configuration using dig?

Run `dig MX example.com` in your terminal. Check the ANSWER SECTION for valid records with correct priorities and resolvable hostnames.

Can MX records be invalid even if dig shows them?

Yes. dig shows DNS records as published, but they may point to unreachable servers or have incorrect priorities. Real delivery depends on server reachability.

Why does my email bounce even with correct MX records?

Bounces can still occur due to spam filtering, blacklisting, poor sender reputation, or mailbox limits—even with a properly configured MX.

Does Emaillistchecker.io test MX records?

Yes. Emaillistchecker.io includes DNS-level checks like MX validation during email verification, flagging domains with problematic or missing records.

Can dig detect if a mail server is down?

No. dig only shows DNS records. It does not test server availability or SMTP connectivity. Live delivery testing is required to confirm function.

How often should I check MX records with dig?

Quarterly, and always after DNS changes. Manual checks are useful for diagnostics, but automation is better for ongoing campaigns.

Is dig the only tool to check MX records?

No. Tools like MxToolbox, DNSCheck, and email verification platforms also check MX records, often with additional delivery context.

How does Emaillistchecker.io improve deliverability beyond MX checks?

It combines DNS validation, SMTP testing, inbox placement simulation, and spam detection to catch issues early—boosting inbox placement rates.

Can Emaillistchecker.io verify lists with many domains?

Yes. It supports bulk verification and integrates with platforms like Mailchimp and Klaviyo, making large-scale email hygiene manageable.

What’s the accuracy of Emaillistchecker.io’s email verification?

It achieves 98.9% accuracy by combining DNS checks, real-time SMTP validation, and in-depth inbox delivery simulation.

Do Emaillistchecker.io credits expire?

No. Purchased credits never expire, allowing teams to verify large lists at their own pace without time pressure.