Test DNS MX Records with IPv4/IPv6

Why DNS MX record testing matters for email deliverability

You send an email, and it vanishes. No bounce, no error — just silence. It’s not your inbox that’s broken. It’s your MX record.

MX records are the postal code for incoming mail. If they’re wrong, missing, or unreachable over IPv4 or IPv6, messages never arrive. This isn’t hypothetical — it’s a common root cause of silent delivery failures.

Testing your MX records with real IPv4 and IPv6 connectivity checks ensures your server can reach the intended destination, regardless of the network stack. It’s not just about DNS resolution; it’s about actual reachability.

Key takeaways

MX records must be validated not just for existence, but for actual connectivity across both IPv4 and IPv6 networks.
Ignoring MX record testing leads to undelivered inbound mail, higher bounce rates, and long-term sender reputation damage.
Tools that test MX records with live IPv4 and IPv6 connectivity are essential for ensuring mail servers can reach their intended destinations across dual-stack environments.

What DNS MX records actually do — and how they fail

MX records tell every mail server on the internet which server should receive emails for a given domain, using priority numbers to decide the order. If your MX record is missing, wrong, or misconfigured, messages fail instantly—no bounce, no delay, just a hard delivery failure. A single incorrect priority or outdated IP address can stall delivery or trigger bounces, undermining your sender reputation and inbox placement.

How MX records guide email delivery

When someone sends an email to your domain, the sending server checks the DNS records to find the correct mail server. The MX record lists one or more mail servers, each with a priority number—lower is better. If the primary server is down or unreachable, backup servers with higher numbers take over. This system is designed to be resilient, but it only works if records are correctly set and propagated.

Without an MX record, even a perfect email body and valid sender domain won’t help. The receiving system has no destination—it simply rejects the message. That’s a hard failure, often logged as “550 5.1.1 No such user” or “550 5.3.1 Unknown user”. It’s a silent killer of deliverability.

Common MX configuration failures

Even small mistakes in MX setup can cause real-world delivery problems. An expired DNS record means mail gets lost in transit. A typo in the server name or an old IP address—perhaps from a migrated mail system—means messages arrive at a dead server. These issues aren’t always visible in testing unless you check actual DNS responses.

DNS propagation delays can also break things temporarily. After changing MX records, it can take 24–72 hours for all servers to update. During that window, some emails may route correctly and others fail randomly, confusing both senders and receivers. This is why testing email delivery from multiple geographic locations and with IPv4 and IPv6 connectivity matters.

For deeper validation, tools that check both IPv4 and IPv6 MX resolution—plus actual SMTP handshake attempts—are crucial. These tests confirm not just that a record exists, but that the server responds when contacted. Real-world delivery isn’t about DNS alone. It's about whether the target mail server actually accepts messages.

Tools that test both DNS MX records and their actual connectivity—on both IPv4 and IPv6—are rare, but necessary. At Emaillistchecker.io's bulk verification service, we test email addresses not just by parsing their domain, but by simulating the full delivery path, including actual MX lookups and SMTP behavior across both protocols.

How IPv4 and IPv6 connectivity testing prevents delivery issues

You can't assume your outbound mail reaches recipients just because the email address is valid. If your mail server only supports IPv4 but the destination server listens on IPv6, or vice versa, delivery fails—no bounce, no error, just silence. Testing both protocols ensures your messages can reach any server, regardless of its IP stack preference.

Why both IPv4 and IPv6 matter for email delivery

Modern mail servers are increasingly dual-stack, supporting both IPv4 and IPv6. But not all are equally configured. Some domains operate solely on IPv6, others have dropped IPv4 entirely. If your sending infrastructure only probes one stack, you’ll miss delivery opportunities or get silent failures. This isn’t rare—it’s a known issue in email infrastructure, especially as IPv6 adoption grows across data centers and ISPs.

Let’s say you’re sending newsletters to a list hosted on a university server. If the server is IPv6-only and your mailer uses IPv4-only routing, the connection never forms. No SMTP error, no feedback loop—just the email vanishing into a black hole. This is a common cause of failed deliveries in high-volume campaigns.

Connectivity testing catches the invisible failures

Testing both IPv4 and IPv6 connectivity isn’t just about checking DNS records. It’s about simulating the actual path your email takes from sender to receiver. A valid MX record does nothing if the underlying network stack can’t reach the server.

Tools that verify both IP versions provide visibility into whether a server is reachable using either protocol. This includes checking for connection timeouts, firewall blocks, or routing issues that may only appear on one stack. The ability to test both is especially critical for senders managing large lists across global domains.

For context, the Internet Engineering Task Force (IETF) has documented the transition to IPv6 as a long-standing requirement, with IPv4 expected to remain in use for years—but not indefinitely. IETF standards emphasize dual-stack support as the default for new infrastructure, making it essential for senders to test both protocols.

If you're sending at scale, relying only on basic address validation misses half the picture. Tools that include full-stack connectivity checks—like testing MX records against both IPv4 and IPv6 addresses—catch issues before they impact deliverability.

While many tools stop at validating syntax and basic DNS, robust verification includes probing the actual network path. For teams that need to ensure their emails reach inboxes—regardless of the target’s IP configuration—this step is non-negotiable. You can use a service like bulk verification with real-time connectivity testing to spot not just invalid addresses, but unreachable servers, before sending.

Tools to test DNS MX records with IPv4 and IPv6 connectivity

You can test DNS MX records with IPv4 and IPv6 connectivity using command-line tools like dig or nslookup, or online services like MXToolbox.com. For full validation, query both A (IPv4) and AAAA (IPv6) records from the MX server, then confirm the mail server’s SMTP port (usually 25, 587, or 465) responds on both protocols. Real-time verification across both address versions is essential—modern email infrastructure requires dual-stack support to avoid delivery failures.

Verify MX records and resolve IP addresses reliably

Start with dig MX example.com to retrieve the mail server’s domain. Then run dig A mail.example.com and dig AAAA mail.example.com to check both IPv4 and IPv6 reachability. This separates DNS parsing from actual connectivity—just because a record exists doesn't mean it’s live. The SMTP RFC defines how mail servers must handle address resolution, so testing both A and AAAA records matches real-world behavior.

Next, verify that the mail server is actually accepting connections. Use telnet or nc to connect to port 25 or 587 from a machine with both IPv4 and IPv6 connectivity. If the connection fails, the server may be unreachable, blocked, or misconfigured. This step is often skipped in basic checks but is critical for deliverability—especially as IPv6 adoption grows. Major email providers now require IPv6 support, and delivery can fail silently if not tested.

Use real-time tools for modern deliverability validation

While command-line tools are precise, real-time tools that simulate end-user connection attempts offer deeper insight. Services like MXToolbox.com provide both DNS and connectivity checks across IPv4 and IPv6. They show if a server responds within acceptable timeframes and can catch issues like greylisting, rate limiting, or firewalls that block certain protocols. For teams managing large email lists, automating these tests ensures consistent inbox placement. You can integrate this process into your workflow via API or use a bulk verification tool that checks deliverability at scale.

Consider bulk verification if your list exceeds a few hundred addresses. It tests not only syntax and domain validity but also DNS and connectivity for both IPv4 and IPv6 in one streamlined operation. This reduces bounce rates and improves sender reputation—critical factors in inbox placement. Testing both protocols isn’t optional anymore. It’s a baseline requirement for reliable email delivery.

How Emaillistchecker.io helps verify MX and connectivity at scale

You can test DNS MX records with both IPv4 and IPv6 connectivity using Emaillistchecker.io, which checks your mail server’s full path—from DNS configuration to actual reachability—without relying on your local network. It validates MX, A, and AAAA records, then attempts to connect over both IPv4 and IPv6, giving you real-time insight into whether your emails can actually reach inboxes.

What’s verified behind the scenes

When you run a verification, the platform doesn’t just look up DNS records—it simulates a real email submission path. It confirms that the MX record points to a valid server, that the A record resolves to a publicly accessible IPv4 address, and that the AAAA record resolves to a reachable IPv6 host.

Most tools only check DNS. Emaillistchecker.io goes further: it attempts to establish a TCP connection to the mail server on port 25 or 587 from multiple geographically distributed points, testing both IPv4 and IPv6 routes. This means you catch issues like blocked outbound ports, IPv6 misconfiguration, or routing black holes that DNS-only checks miss.

Deliverability visibility, not just validation

The result isn’t just a “valid” or “invalid” label. The full verification report includes connectivity status, latency, and SMTP handshake outcomes—so you know not just if a domain can accept mail, but how reliably it does.

Even better, this data feeds directly into the inbox-placement test. You don’t run separate checks; you get real-world deliverability predictions by combining MX validation with actual SMTP trials. This matches industry standards seen in tools like MxToolbox or Spamhaus, which also stress that infrastructure readiness is a top factor in inbox placement.

For teams sending at scale, this eliminates guesswork. You’re not just validating syntax—you’re testing whether your emails can land in inboxes, regardless of your own network setup.

Learn how to test your list before sending at scale: run a bulk verification and see how your domains perform in real SMTP conditions.

Step-by-step: Testing MX records and connectivity with Emaillistchecker.io

You can test MX record resolution and SMTP connectivity for IPv4 and IPv6 using Emaillistchecker.io’s Inbox-Placement Testing feature. It checks your domain’s MX records, resolves both A and AAAA DNS entries, then initiates real SMTP connections on ports 25 and 587—testing both IP versions simultaneously—to confirm reachability, responsiveness, and configuration correctness.

How it works in practice

Go to the Emaillistchecker.io dashboard and select “Inbox-Placement Testing” from the menu. This tool is designed to simulate what sending mail through your server would actually encounter in real-world email infrastructure.
Enter the domain you want to test, like example.com, or upload a list of domains. The system processes each one independently, ensuring individual results aren’t masked by others.
MX records are retrieved and resolved. The tool fetches the domain’s MX records and resolves the associated mail server IPs via A (IPv4) and AAAA (IPv6) records—critical for confirming dual-stack readiness, as outlined in RFC 6531.
SMTP connection attempts are made on port 25 (standard mail submission) and port 587 (mail submission over TLS), with both IPv4 and IPv6 tested. This mimics how modern email clients and servers behave today, particularly in environments where IPv6 is active.
Results are returned in real time. You’ll see whether the MX server is reachable, responsive, and correctly configured—no false positives from outdated or cached DNS data.

Why this matters for deliverability

Many sending issues start long before the message is sent. Misconfigured MX records or blocked IPv4/IPv6 paths can lead to silent bounces or deliverability failures. By simulating the full SMTP handshake, Emaillistchecker.io surfaces real connectivity problems that DNS lookup tools alone can’t catch.

The 5 steps described in “How it works in practice”, in order.

For teams integrating verification into automated workflows, Emaillistchecker’s real-time API can be used to programmatically test MX records as part of onboarding or campaign setup.

Making sure your outbound email infrastructure handles both IP versions correctly isn’t optional anymore. IPv6 adoption continues to grow across major ISPs and mail providers—testing both versions proactively reduces the risk of unexpected delivery failures.

How MX validation fits into broader list hygiene and deliverability

Validating MX records is not a standalone fix—it’s one layer of email list hygiene that confirms a domain still receives mail. Combine it with checks for invalid, role-based, and disposable addresses to identify dead, automated, or non-personal inboxes. Together, these steps reduce bounces, protect sender reputation, and improve inbox placement, especially when sent at scale.

Why MX records matter beyond just connectivity

Every email sent to a domain without an MX record will fail or be deferred. You can’t deliver to a domain that doesn’t have a defined mail routing path. This is not hypothetical—many abandoned domains or outdated infrastructure still have email addresses listed, leading to hard bounces that degrade your sender reputation over time.

MX validation is a gatekeeper. It filters out domains that are effectively dead, often flagged by services like Spamhaus or MxToolbox for misuse. Even if an email address looks valid structurally, no MX means no delivery.

Building a complete hygiene stack

MX checks alone aren’t enough. A clean list needs multiple filters applied in sequence. Start with the basics—verify the format (syntax), then rule out role accounts (like admin@ or sales@) that rarely open emails. Then, eliminate disposable domains (like mailinator.com), which are used to sign up and discarded quickly.

Let’s be honest: a list built on guesswork or outdated contacts will hurt your deliverability. Every bounce, especially a hard bounce, signals to providers like Gmail or Outlook that you’re sending to inactive or non-existent users. That directly impacts your sender reputation, making future messages more likely to land in spam.

Tools like bulk email verification automate this process by scanning thousands of addresses at once, flagging invalid, catch-all, or risky entries. This isn’t about filtering out dead ends—it’s about preserving trust with email providers.

For active senders, combining MX validation with real-time inbox placement testing is the best practice. It shows you not just whether mail is delivered, but whether it lands in the inbox—providing confidence before you send to a full list.

It’s not about perfection. It’s about reducing risk. By validating MX records and layering in other checks, you’re doing more than cleaning a list—you’re building a foundation for consistent, reliable delivery across IPv4 and IPv6 environments.

Common pitfalls when testing MX records manually

Just because a domain resolves DNS doesn’t mean its MX records are correct. You might see a valid A record but no MX, or an outdated one. Testing only IPv4 connectivity misses issues when IPv6 is required. And early SMTP handshake delays from greylisting or throttling can be falsely interpreted as failures. These missteps lead to wasted sends and dropped deliverability.

What you’re missing when you skip deeper checks

Assuming a domain is valid just because it resolves DNS—MX records can be missing entirely, or point to a non-functional server.
Relying on IPv4-only connectivity tests, especially when your mail server or recipient infrastructure now requires IPv6 support. Some providers block IPv4-only attempts entirely.
Not accounting for SMTP-level throttling or greylisting during the initial handshake. A 5xx or 4xx response can mean "hold on" rather than "no good" — it’s a temporary signal, not a hard failure.
Using generic tools that don’t simulate real email delivery behavior. A successful MX lookup doesn’t mean inbox placement is possible.
Ignoring that some domains use catch-all setups, making it hard to distinguish between valid and invalid addresses without active verification.

How to avoid these traps

Manual MX testing isn’t foolproof. You need both DNS validation and real SMTP-like behavior simulation. Tools like inbox placement testing replicate how real mail servers respond, catching issues that pure DNS lookups miss. They test both IPv4 and IPv6 connectivity paths, and observe how your email is treated during the SMTP handshake. This avoids false positives from throttling or greylisting.

According to RFC 5321 (the standard for SMTP), servers may delay responses intentionally. A non-immediate reply isn’t a failure—until it’s confirmed as such. That’s why simulating a full delivery path is essential.

Consider using a tool that runs real connection attempts across both IPv4 and IPv6, while logging the actual SMTP responses. That’s how you uncover what a real inbox will actually experience.

Why SMTP connectivity testing is not the same as DNS validation

DNS validation confirms a domain has an MX record and where it points, but it doesn’t tell you if the mail server is online or accepting connections. SMTP testing goes further—it checks whether the server responds to real email commands, which is the only way to know if your message will actually be delivered. You need both: DNS tells you where to send mail; SMTP tells you if the server will take it.

DNS tells you where to send, but not if it’s ready

When you query a domain's DNS records, you’re checking for an MX (Mail Exchange) record. This tells you which server handles email for that domain. But it doesn’t confirm the server is active, reachable, or willing to accept messages. A domain can have a valid MX record pointing to a server that’s offline, behind a firewall, or misconfigured. Relying only on DNS is like sending a letter to a correctly listed address that no longer exists.

SMTP is the real test of inbox readiness

SMTP connectivity testing simulates an actual email transaction. It connects to the mail server, exchanges handshake commands, and checks for a response. If the server refuses the connection or drops it early, the address is effectively unreachable—even if DNS says otherwise. This is why tools that only check DNS are limited. Real deliverability depends on server responsiveness, not just record presence.

You can test both layers using reliable tools. For bulk validation, our bulk verification service checks DNS records and follows up with live SMTP connection tests to rule out invalid, unreachable, or temporary failures. It’s the standard practice used by teams managing large lists—because you can’t trust DNS alone.

For more granular control, the real-time verification API lets you validate addresses during sign-up or campaign prep with both DNS and SMTP checks. It’s a precise way to catch issues before they hurt your sender reputation. As the RFC 5321 standard makes clear, email delivery relies on successful SMTP handshakes, not just DNS configuration.

While tools like MxToolbox or Spamhaus offer basic MX checks, they don’t consistently test the full SMTP flow. That’s why standalone DNS validation falls short. You can’t deliver to an inbox unless the server says yes—twice, once in DNS, once in SMTP.

Integrating MX and connectivity checks into your workflow

You can automate DNS MX record validation and IPv4/IPv6 connectivity testing by embedding Emaillistchecker.io’s API into your send flow, syncing with platforms like Mailchimp or Klaviyo to catch invalid domains before they hit your campaign, and scheduling monthly checks on partner domains to protect sender reputation. This reduces hard bounces, keeps your IP warm, and improves inbox placement over time.

Automate domain checks at scale

Use Emaillistchecker.io’s real-time verification API to check MX records and network reachability (IPv4 and IPv6) for every new domain in your list before sending.
Embed the API in your onboarding or campaign setup process—validation runs in under 2 seconds per domain, catching issues before your email even leaves the server.
Filter out domains with misconfigured MX records, missing A/AAAA records, or unreachable mail servers early, avoiding wasted sends and protecting your sender reputation.

Synchronize checks with your marketing stack

Integrate directly with Mailchimp, SendGrid, or Klaviyo via Emaillistchecker.io’s native connections to validate domains during list syncs—no manual steps, no false positives.
Set up rules to block invalid domains from being imported, so only verified, deliverable addresses reach your campaign queue.
Even with auto-sync, run periodic bulk checks—your partners’ or suppliers’ mail servers can change without notice; automated verification stops issues before they hit your inbox rate.

Consistent domain validation helps maintain a stable sender reputation. According to DMARC.org, 80% of email delivery failures stem from basic DNS setup errors—many preventable with early validation.

Let’s be clear: you don’t need to wait for bounces to know your list is broken. You can run a full MX and connectivity report across your entire domain list monthly, using the bulk verification feature, and track changes over time. This isn’t about perfection—it’s about reducing risk. Every check you run is one fewer time you’ll get blocked by a major provider. You’re not chasing 100% deliverability. You’re avoiding the 5% of preventable errors that cause 90% of delivery setbacks.

Bottom line: You can’t trust deliverability without MX and connectivity proof

MX records and server connectivity are the foundation of email delivery. Skipping verification leaves you blind to failures that start long before the message reaches the inbox.

With IPv4 and IPv6 both in active use, testing both protocols is essential. Dual-stack environments mean ignoring one protocol guarantees failed delivery for a segment of your audience.

Tools like Emaillistchecker.io automate real-time MX validation and SMTP connectivity testing across both IPv4 and IPv6. This ensures your list is not only valid but deliverable at scale.

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 happens if an MX record is missing or invalid?

Email to that domain will fail to deliver, resulting in hard bounces and potential harm to sender reputation.

Can IPv6 cause email delivery failure even if IPv4 works?

Yes — if a recipient’s server only supports IPv6 and your system doesn’t route via AAAA records, delivery fails.

How does Emaillistchecker.io test IPv6 connectivity?

It resolves AAAA records from the MX server and attempts SMTP connection via IPv6, using a globally distributed network.

Is DNS lookup enough to ensure deliverability?

No — DNS confirmation only shows where mail should go. You must also verify that the server accepts mail.

Why do some MX tests fail during delivery but pass in testing?

Greylisting, IP blocking, or rate-limiting can cause timeouts or rejections during actual send, even if tests pass.

What’s the difference between MX validation and inbox placement testing?

MX validation checks DNS and server reachability; inbox placement tests simulate real delivery in multiple inboxes.

Can I test multiple domains at once with Emaillistchecker.io?

Yes — use the bulk list verification or inbox-placement testing features to process multiple domains simultaneously.

How often should I test MX records and connectivity?

Test new domains before sending, and review existing domains quarterly to catch configuration drift or outages.

Do all email verification tools test MX records?

Not all — many only validate syntax or format. Emaillistchecker.io includes full MX and connectivity checks.

What does 'IPv4/IPv6 connectivity' mean in deliverability?

It means confirming that mail servers can be reached via both protocol versions, which is required for modern delivery.

What happens if a server replies to a connection but blocks email?

It’s a grey or soft failure — the server is reachable but won’t accept mail under current conditions.

Can I automate MX and IP connectivity tests using Emaillistchecker.io API?

Yes — the real-time verification API supports domain and IP-level connectivity checks as part of bulk workflows.