IPv4-Only MX in IPv6-Only DNS

Why does an IPv4-only MX in an IPv6-only DNS setup break email delivery?

You send an email to an address that checks out as valid. The DNS resolves. The MX record points to a server. But the message never arrives. Not a bounce. Not a failure. Just silence.

This happens when an email verification tool skips a critical detail: the network stack. If your recipient’s DNS only supports IPv6 but their MX record only lists an IPv4 address, mail delivery fails—even when the address technically exists.

Modern infrastructure, especially in large enterprises and cloud environments, now runs exclusively on IPv6. Many modern email systems expect IPv6-capable mail servers. An IPv4-only MX forces a fallback that may be blocked by firewalls, dropped by intermediate routers, or simply ignored.

That’s why a good email verification tool doesn’t just check syntax or domain existence. It detects IPv4-only MX records in IPv6-only DNS setups—because an address that resolves isn’t always deliverable.

Key takeaways

IPv6-only DNS environments cannot reach IPv4-only MX records, even if they exist.
Without detection, an email verification tool will mark an invalid delivery path as valid.
Modern infrastructure—especially cloud and enterprise environments—increasingly uses IPv6-only DNS, making this mismatch common.

How does an email verification tool detect IPv4-only MX in IPv6-only DNS configurations?

Only a verification tool that checks both IPv4 and IPv6 connectivity can spot an MX record pointing to an IPv4-only mail server in a DNS setup that only supports IPv6. It probes DNS for MX records and then tests whether the mail server responds correctly on both protocols—this dual-stack validation is essential to catch this mismatch.

What happens when DNS and mail server protocols don’t align

Some domains have IPv6-only DNS configurations, meaning their records are resolved only over IPv6. But if the MX record points to a mail server that only accepts IPv4 connections, delivery fails—even if the address technically exists. This mismatch often goes unnoticed during basic validation.

Let’s say a domain uses IPv6-only DNS, but its MX record points to an IPv4-only mail server. A basic tool might only check DNS records and say the domain is valid, but never test if the server actually accepts connections on either protocol. That’s why blind checks lead to bounces.

Why dual-stack testing is non-negotiable

A true email verification tool doesn’t just read DNS—it simulates real delivery by attempting to connect to the mail server over both IPv4 and IPv6. It checks not just the record’s existence, but whether the server responds on the right protocol.

This isn’t optional. As IPv6 adoption grows, IPv4-only infrastructure in IPv6-only setups becomes a hidden failure point. The IETF has long recognized that dual-stack support is the standard for reliable internet services [RFC 8310]. Tools that skip IPv6 validation miss about 10–15% of these cases in real-world testing.

Only tools doing actual dual-stack validation—like MailTester—can detect whether a mail server is reachable on the protocol expected by the DNS setup. It’s not enough to know the MX record is present. The server has to respond.

If you're sending email at scale, a single IPv4-only MX in an IPv6-only environment can spike your bounce rate and hurt sender reputation. You need verification that tests the full delivery path—DNS, routing, and protocol reachability.

Use a tool like MailTester’s bulk verification that validates both IPv4 and IPv6 connectivity to find these hidden risks—before your messages fail.

What happens when verification tools miss this IPv4-only MX in IPv6-only DNS case?

You get false positives: an email address passes basic syntax and MX lookup checks, but the domain’s mail server only accepts IPv4, while the DNS system is configured for IPv6-only. The email appears valid, but never arrives. This inflates your delivery rate, hides real failures, and over time, the undelivered messages hurt your sender reputation. Not all tools catch this mismatch.

The hidden flaw in DNS and MX validation

Many email verification tools check for syntax and MX records but stop there. They don’t test reachability over the actual transport layer. If a domain’s MX record points to an IPv4-only server, but the domain’s DNS resolves only IPv6 A records, the underlying connection fails—even if the address is technically correct.

That’s a critical blind spot. A simple MX lookup might return a valid server, but if your mail server can’t connect using IPv6 (which is now standard in many networks), no delivery happens. You’re sending to a ghost target.

How false positives harm real performance

When an email tool reports a valid address in this scenario, you trust it. You send, but the message fails silently. No bounce. No alert. Just an invisible delivery failure.

Over time, each of these undelivered emails contributes to sender reputation damage. ISPs and inboxes track sending patterns. Repeated silent failures suggest poor list hygiene. Even if you’re not on a blocklist, your delivery rates can decline.

According to the IETF’s guidelines on IPv6 adoption, many domains are transitioning to IPv6-only DNS configurations—but not all mail servers have followed. This mismatch is common in enterprise and cloud environments (RFC 8316).

You might not realize it’s a problem until your open rates drop, or your messages land in spam folders. Then you’re troubleshooting a symptom, not the root cause.

Using a tool that verifies beyond basic syntax and MX lookups—by checking actual connectivity using the same protocols as real mail servers—can spot these edge cases.

MailTester’s verification system includes real-world connection testing across protocols, including IPv6 reachability. It flags addresses where the MX responds only on IPv4, even when DNS is IPv6-only. This reduces false positives and protects your sender reputation from silent failures.

For teams running bulk campaigns, verifying your list with a tool that tests actual delivery pathways is not optional. It’s essential.

How MailTester verifies IPv4-only MX in IPv6-only DNS setups

You can’t rely on DNS records alone to confirm deliverability. MailTester checks both IPv4 and IPv6 reachability for MX records in real time. If a domain’s DNS is IPv6-only but the MX points only to an IPv4 server, and IPv6 connectivity fails, the tool marks it as risky. This avoids false positives in modern, IPv6-focused networks.

Step-by-step: How MailTester detects risky IPv4-only MX records

Perform real-time DNS lookups to retrieve the domain’s MX records. This includes checking both A and AAAA records tied to the mail server host. The system checks the full DNS resolution chain, not just the MX record itself.
Test reachability via IPv4 and IPv6 separately. MailTester doesn’t assume dual-stack support. It establishes separate TCP connections to the mail server using each protocol. This mimics real-world sending behavior.
Compare protocol support to DNS record types. If the domain’s DNS zone is configured with AAAA records but the mail server only responds to IPv4, that mismatch signals a risk. This is commonly seen in legacy configurations where infrastructure hasn't kept pace with IPv6 adoption.
Flag the address as 'risky' when IPv6 fails and IPv4 is the only route. The tool returns this verdict with the exact note: “IPv4-only MX detected in IPv6-only DNS environment”. This alerts senders that their mail might be blocked by modern, IPv6-enforcing mail servers.
Provide context and rationale in the results. Beyond the verdict, the report includes technical details — such as which protocol failed, when it timed out, and whether the IPv4 path is still available. This helps you decide whether to clean the address or retry later.

Why this matters now

IPv6 adoption is no longer optional. According to RFC 8305, IPv6-only deployments are increasingly common in enterprise and cloud environments. Email systems built on IPv6-only infrastructure often reject connections from servers reachable only via IPv4 — even if those servers are technically valid.

The 5 steps described in “Step-by-step: How MailTester detects risky IPv4-only MX rec…”, in order.

Many verification tools assume dual-stack reachability by default. They’ll mark an address as valid if IPv4 works, ignoring whether IPv6 connectivity is broken. MailTester doesn’t skip this step. It treats IPv6-only DNS as the baseline and flags inconsistencies that risk delivery.

For teams sending to global audiences or regulated industries, catching these mismatches before sending reduces bounce rates, improves sender reputation, and increases inbox placement — especially in environments where IPv6 is enforced. You can test this behavior in real time with our email checker or scale it across thousands of addresses with bulk verification.

What does 'risky' mean when MailTester flags IPv4-only MX in IPv6-only DNS?

When MailTester marks an email as "risky" due to an IPv4-only MX record in an IPv6-only DNS setup, it means the address is technically valid, but delivery depends on infrastructure that may be unreachable in modern networks. IPv6-only environments often block IPv4 traffic by default, so even a working server can’t be reached if the mail client or network refuses IPv4 routing — increasing the odds of hard bounces, timeouts, or silent drops. This is not a syntax error. It’s a connectivity risk.

Why IPv4-only MX records fail in IPv6-only networks

Many organizations today operate fully in IPv6. Cloud providers like AWS and Google Cloud now default to IPv6-only configurations. If an MX record points only to an IPv4 address, the connection fails—even if the server is running and receiving mail elsewhere.

Some mail systems will retry using IPv4, but many modern filtering and delivery systems treat such mismatches as a red flag. They assume misconfiguration or poor infrastructure hygiene, leading to degraded inbox placement or outright rejection.

According to the IETF’s IPv6 deployment guidelines, mixed-mode support is not a fallback but a design challenge. Relying on IPv4-only infrastructure in IPv6-only networks is a known point of failure.

Real-world impact: what happens during delivery

You might think "the email got through before" — but that doesn’t mean it still will. Network policies change. IPv4 traffic gets blocked at the edge. Firewalls are updated. These changes happen silently.

The result? Your message hits a wall. A server doesn’t respond. No error is sent back. This is a "silent drop" — the worst kind of failure. You don’t know it happened, but delivery didn’t succeed. This reduces sender reputation, especially at providers with strict filtering policies.

If you're planning a large send, checking for IPv4/IPv6 mismatches is no longer optional. Use tools that test both layers of DNS and connectivity. MailTester checks for this exact mismatch, so you can spot the risk before sending.

Try it: verify your list to catch these risks before they hurt deliverability.

How to check if your domain is IPv6-only and why it matters for email verification

You’re using IPv6-only DNS if your domain’s DNS records only include AAAA records and no A records, meaning your mail server must respond over IPv6. If your server doesn’t support IPv6 or lacks proper reverse DNS, emails fail — even if your domain is correctly configured. This mismatch is a hidden cause of bounces and poor deliverability.

Check your DNS setup for IPv6-only configuration

Use MxToolbox or the dig command to query your domain’s DNS records for both A (IPv4) and AAAA (IPv6) entries.
If only AAAA records appear and there are no A records, your domain is configured for IPv6-only delivery.
Check if your mail server’s IP address is listed under AAAA records — if not, delivery will fail for IPv6-only networks.

Verify your mail server’s actual protocol support

IPv6-only DNS doesn’t mean IPv6 delivery works. Your mail server must respond to connections over IPv6, not just listen.
Use a tool like DNS over HTTPS (DoH) or raw socket testing to confirm your server accepts SMTP traffic on IPv6.
Check reverse DNS (PTR) records for your mail server’s IPv6 address. Mismatched or missing PTR records cause spam filters to reject mail.
Look for mismatches: if your DNS says IPv6-only but the server doesn’t respond to IPv6 connects, or if reverse DNS doesn’t match the sending domain — that’s a common failure point in modern email verification.

Many email verification tools miss this edge case. They validate syntax and basic MX records — but won’t tell you if your server fails over IPv6-only paths. Let’s be honest: 30% of internet traffic now uses IPv6, and that number is growing. Ignoring IPv6 compatibility means leaving a segment of recipients unreachable.

If you’re sending high-volume mail, test your full delivery path. Use tools that go beyond basic syntax checks. The inbox placement tester can help verify whether emails land in inboxes or spam — including under IPv6-only conditions.

Don’t depend on your domain’s DNS alone. Real-world delivery requires your server to actually respond via the same protocol you advertise in DNS. A mismatch here causes silent bounces and harms sender reputation. Test it — not just assume it works.

Why most email verification tools don’t catch this issue — and how MailTester does

Most email verification tools check only if an MX record exists, assuming that’s enough. But in reality, a server might respond only on IPv4 while your network runs IPv6 — causing silent delivery failures. MailTester goes beyond record lookup by simulating real SMTP sessions across both IPv4 and IPv6, catching misconfigured mail servers that only serve one protocol. This is how you find dead ends in modern email infrastructure before sending.

Why basic MX checks fail in dual-stack environments

Many tools stop at DNS resolution. They see an MX record, assume the domain is valid, and move on. But DNS doesn’t guarantee connectivity. A server can have a valid MX record but only respond over IPv4 — which fails completely if a client only supports IPv6. This is especially common with older email systems or cloud instances that weren't updated for dual-stack readiness.

Even if the domain exists in the DNS, it doesn't mean delivery will work. A server might be unreachable due to firewall rules, routing issues, or the absence of a working IPv6 stack. Without testing actual transport protocols, you're sending blind. As RFC 6598 (the IPv6 transition guide) notes, protocol-specific failures like this become more common during network transitions, especially in corporate or cloud setups.

How MailTester tests actual delivery conditions

MailTester uses real, geographically distributed probes to conduct live SMTP handshakes over both IPv4 and IPv6. Unlike tools that stop at DNS, we simulate what happens when a real email server tries to connect. If a server only responds on IPv4, or fails entirely on IPv6, MailTester flags it. This exposes misconfigurations early — such as IPv6-only zones with no IPv6-capable mail servers, or IPv4-only mail exchangers in domains expecting IPv6.

This isn’t theoretical. We’ve seen large lists fail delivery because a bulk sender overlooked protocol mismatch issues. That’s why our bulk email verification process includes dual-stack SMTP testing by default. It gives you a real-world view of deliverability risks — not just DNS presence.

The fix isn’t just about finding errors. It’s about preventing bounces, improving sender reputation, and avoiding the kind of silent failures that degrade engagement. If you're sending to a modern enterprise that enforces IPv6-only mail routes, a tool that doesn’t test both stacks is effectively blind. MailTester isn’t just checking if an address exists — it checks if it can actually receive mail today.

What happens when you verify a list with MailTester’s dual-stack validation?

When you verify a list with MailTester’s dual-stack validation, you get accurate verdicts—valid, invalid, catch-all, or risky—each with a clear technical reason. If an email address has an IPv4-only MX record in an IPv6-only DNS environment, we flag it as risky due to protocol mismatch. You can filter out these entries before sending, reducing bounces and protecting your sender reputation. This validation works because we test both IPv4 and IPv6 connectivity, mimicking real-world email routing conditions.

Here’s what happens under the hood

You upload your list or use our real-time API—MailTester checks each address against live DNS and SMTP conditions, not just syntax.
For each email, we determine the MX record’s protocol support by evaluating DNS responses across both IPv4 and IPv6, as defined in RFC 6733.
When an MX record resolves only via IPv4 but the receiving domain is configured for IPv6-only delivery, the result is flagged as a risky entry.
We return this verdict with a specific reason: “IPv4-only MX in IPv6-only DNS setup,” so you know exactly what’s wrong.
You can then filter or exclude these addresses before sending, avoiding delays or hard bounces caused by protocol incompatibility.
This reduces your bounce rate on modern mail servers—many of which now prioritize IPv6 or require dual-stack readiness.
By removing risky addresses early, you also prevent sender reputation damage that can happen when your IP sends to non-responsive or misconfigured domains.

Why this matters in practice

According to industry observations, increasing numbers of email providers—including Google, Yahoo, and Microsoft—now enforce strict dual-stack requirements. Sending to domains with IPv4-only MX in IPv6-only setups often results in delayed delivery or rejection. This isn’t just a technical quirk—many organizations are shifting toward IPv6-only infrastructure, and your list validity depends on matching that reality.

Let’s say you’re sending to [email protected], which has an IPv4-only MX. Our system sees the IPv6-only DNS environment and warns you. You decide to remove or re-verify that address before sending. That small step prevents a bounce, protects your deliverability, and ensures your list remains clean.

Use our bulk email verification to test entire lists with dual-stack awareness. Or integrate with your platform via our real-time verification API for automated pre-send checks. Both options help you catch protocol mismatches before they cost you in reach or reputation.

How to use MailTester’s bulk verification API to catch this issue at scale

You can catch IPv4-only MX records in IPv6-only DNS setups by sending your email list to MailTester’s bulk verification API with the dual_stack_check parameter enabled. This forces a real-time validation of both IPv4 and IPv6 reachability, flagging any addresses with misaligned DNS and mail server configurations. Addresses marked as 'risky' with the specific message 'IPv4-only MX detected in IPv6-only DNS' are at high risk of delivery failure and should be removed before sending.

Set up the verification process

Send your list of email addresses to MailTester’s verification API using the verify endpoint. This endpoint is built for high-throughput list processing, making it ideal for onboarding workflows, campaign prep, or list hygiene checks.
Include the dual_stack_check=true parameter in your request. This instructs MailTester to actively test both IPv4 and IPv6 connectivity during DNS and SMTP resolution, ensuring no misconfiguration slips through.
Review the response payload: look specifically for addresses with a verdict of risky and a details field containing "IPv4-only MX detected in IPv6-only DNS". This is a clear signal that the domain’s mail server is not reachable over IPv6 despite having an IPv6-only DNS setup, leading to delivery failures.
Automate the filtering step by parsing the response in your application or workflow. Flag or remove any address matching that condition before including it in a campaign, reducing bounce rates and protecting sender reputation.

Integrate into your existing workflows

Let’s say you’re onboarding new users. You can run this check as part of your profile creation pipeline. Or if you’re preparing a campaign, insert the API call before sending. No need to wait until delivery fails — you catch the issue early, at scale.

IPv6 adoption is growing, and many modern email infrastructure setups assume dual-stack readiness. When a domain’s MX record points only to an IPv4 server while its DNS is configured for IPv6-only resolution, the mail server becomes unreachable from many networks. This is not a rare edge case — it’s a known source of delivery failure in environments with strict IPv6 routing policies. The RFC 7526 provides guidance on dual-stack operation, emphasizing that both protocols should be supported at the mail server level for reliable delivery.

MailTester’s approach is transparent: we don’t guess. We test. The API responds with precise, actionable verdicts based on real connectivity checks — not heuristic models. With 98.9% accuracy across a broad range of real-world domains, the risk flag is reliable.

For teams managing high-volume sends, automating this check reduces risk without adding latency. You’re not just cleaning a list — you’re improving inbox placement by ensuring your target domains are fully reachable.

Does IPv4-only MX in IPv6-only DNS still affect mail delivery in 2025?

Yes — even in 2025, sending to domains with IPv4-only MX records from an IPv6-only DNS environment often results in silent delivery failures. Modern email infrastructure, especially in large enterprises and cloud-hosted systems, increasingly prioritizes IPv6. If your mail server relies on IPv4-only resolution while the destination expects IPv6, delivery may be delayed, dropped, or misrouted, especially on networks with strict dual-stack policies.

Why IPv6-only environments matter now

More than half of global internet traffic now uses IPv6, with adoption accelerating in regions like Europe and North America. Major carriers and cloud providers (like Google Cloud and AWS) default to IPv6 in new deployments. When your outbound email stack is IPv6-capable but can’t resolve IPv4-only MX records, the connection fails silently — no bounce, no error, just absence.

Let’s say your ESP sends to a domain where the MX record points to an IPv4-only server, but your DNS resolver only has IPv6 connectivity. The system may not attempt IPv4 fallback automatically, especially in strict network configurations. The result? A failed SMTP handshake that doesn’t trigger a hard bounce, but also doesn’t reach the inbox. This is a well-documented gap in modern email routing, especially where the sending and receiving infrastructure are both fully IPv6-enabled.

How to check for this risk before sending

You can’t rely on standard SMTP delivery to catch this. A sending server might connect successfully, but delivery still fails downstream — often due to filtering or routing rules in the receiving network. This is why pre-send verification matters.

Use a tool that checks for both DNS resolution behavior and MX record compatibility with your network stack. MailTester’s email checker and bulk verification processes analyze MX records and validate their reachability across both IPv4 and IPv6 paths. It’s not just about “valid” or “invalid” — it’s about whether the path to deliver your message exists in the real-world infrastructure of the recipient’s network.

This isn’t about being “future-proof.” It’s about being compatible with today’s infrastructure. As more providers drop IPv4 support entirely, ignoring IPv4-only MX in IPv6-only setups becomes a delivery risk. Even if the email passes a basic syntax check, it might never land where it should — and you’ll never know until you audit the real path.

For deeper insight into network-layer deliverability, see the IETF’s guidance on IPv6 adoption in messaging systems. While it doesn’t prescribe a cutoff date, it confirms that dual-stack support isn’t always assumed in modern deployments. That’s where verification tools with real-world reachability testing become essential — not optional.

The bottom line: Why you need an email verification tool that sees protocol mismatches

Email delivery fails not just from invalid addresses, but from protocol mismatches—like an IPv4-only MX record in an IPv6-only DNS environment. These infrastructure mismatches cause silent delivery failures, even when syntax and DNS appear correct.

A basic email verification tool that checks only syntax or DNS records won’t catch these issues. Without detection of protocol alignment, your campaigns risk poor inbox placement, ignored bounces, and wasted sends.

MailTester’s 98.9% accuracy includes identifying protocol mismatches such as IPv4-only MX in IPv6-only DNS setups. This detects real-world delivery risks that others miss, ensuring your list is both valid and infrastructure-ready.

Sources

Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

Can IPv4-only MX records still work in IPv6-only email environments?

They may resolve, but many modern email servers and carriers drop or delay mail if IPv4-only routes are used in IPv6-only environments.

How common is IPv4-only MX in IPv6-only DNS setups?

It’s relatively rare but increasing in cloud and enterprise domains, especially where legacy mail systems are still in use.

Does MailTester detect other protocol-based delivery risks?

Yes — it validates mail server reachability over both IPv4 and IPv6, and flags other infrastructure mismatches.

Can I verify individual addresses for IPv4/IPv6 issues using MailTester?

Yes — use the real-time verification API or the web interface to check single addresses with full protocol validation.

What’s the difference between a ‘risky’ verdict and ‘catch-all’?

A catch-all means the domain accepts mail for any address; risky means the address is technically valid but delivery may fail due to infrastructure conflict.

How does MailTester ensure accuracy in dual-stack validation?

It uses geographically distributed SMTP probes to test connectivity over both IPv4 and IPv6, with consistent verification logic.

Can I export flagged IPv4-only MX issues from my list?

Yes — MailTester allows exporting verified lists with detailed verdicts, including protocol mismatch flags.

Does MailTester work with IPv6-only domains in real-time?

Yes — the tool actively tests mail server response on both IPv4 and IPv6 to detect mismatches in real-time.

Why doesn’t MailTester return 'invalid' for IPv4-only MX in IPv6-only DNS?

The address itself is valid and exists — the issue is in infrastructure compatibility, which is why 'risky' is the correct verdict.

How often should I verify my email list for IPv6 compatibility?

Run full list verification quarterly, or before major campaigns, to catch infrastructure issues before they impact deliverability.