Configure DNS for IPv4 & IPv6 MX Records

Why MX record availability matters for email delivery in 2026

You send an email. It doesn’t arrive. No bounce, no error — just silence. You check your sender reputation, your content, your list hygiene. Everything looks fine. What’s missing? Your MX record might not be available on both IPv4 and IPv6.

MX records are the GPS for incoming mail. They tell the world which servers handle your inbox. If those records are unreachable on one protocol — especially during the ongoing IPv4-to-IPv6 transition — your messages get lost in the gap.

DNS misconfiguration is a top reason for delivery failures, especially for organizations with global recipients. Relying on only IPv4 is a risk. Relying on only IPv6 is a risk. You need both.

Key takeaways

MX records must resolve correctly on both IPv4 and IPv6 to ensure global inbox delivery in 2026.
IPv6 adoption is growing; ignoring it means losing mail during network transitions.
DNS misconfigurations often go unnoticed until send rates drop, making proactive validation essential.

How IPv4 and IPv4 and IPv6 coexist in email delivery infrastructure

Modern email delivery requires your infrastructure to support both IPv4 and IPv6 because more recipients are using IPv6-only networks. If your server only resolves IPv4, you’ll fail to connect to receivers that only support IPv6, causing delivery delays or outright drops. You must ensure your MX records resolve correctly for both protocols to avoid connection timeouts and maintain deliverability.

Why IPv6 is no longer optional in email delivery

IPv4 remains dominant in legacy systems, but major ISPs and cloud providers now run dual-stack networks with growing IPv6 adoption. According to the Internet Society’s 2023 report, over 40% of global internet traffic now uses IPv6, and that number grows monthly. This shift means email servers must be ready to route messages through either stack.

Let’s be clear: a server that only speaks IPv4 is increasingly out of sync with modern infrastructure. If your outbound mail server can’t reach IPv6-only receivers, those messages get dropped. This isn’t a theoretical risk—it’s a common cause of silent bounces and poor inbox placement.

When a receiving server only has IPv6 addresses, and your sending server lacks IPv6 connectivity or DNS resolution, the connection timeout happens before any SMTP handshake even begins. This is why you need to validate your DNS records for both A and AAAA records.

How to verify your MX record’s reachability across both stacks

Start by checking your MX record’s DNS resolution with tools like MXToolbox or DNSLeakTest. Run queries for both A (IPv4) and AAAA (IPv6) records. If one fails, your delivery isn’t complete.

Use a real-time email verification service to test how well your sending infrastructure handles dual-stack environments. The right tool checks MX records across both protocols and flags issues before you send to real users.

For example, bulk email list cleaning can validate your recipient list and highlight domains that resolve only via IPv6—helping you catch potential delivery blockers early. You can also use the real-time email verification API to check individual addresses during signup or campaign prep, including DNS-level reachability for both IPv4 and IPv6.

The role of DNS in enabling dual-stack email delivery

DNS enables dual-stack email delivery by resolving domain names to both IPv4 (via A records) and IPv6 (via AAAA records). For MX record availability, both A and AAAA records must exist and be synchronized—otherwise, mail delivery fails during IPv6-only attempts, even if IPv4 is operational. Let’s break down why this matters.

Why both A and AAAA records matter

Even if your mail server supports IPv6, it won’t reach recipients if their domain only has an A record. The same goes for IPv4-only networks if only AAAA records exist. Dual-stack systems rely on DNS to return both address types so the client can choose the best path.

According to RFC 6563, mail systems should prefer IPv6 when available—but only if both A and AAAA records are present. If one is missing, mail clients may time out or fall back to a less reliable path, increasing delivery risk.

Many senders assume that since IPv4 is still dominant, they can ignore AAAA records. But as more networks transition to IPv6—especially in mobile and cloud environments—this oversight leads to avoidable bounces and lower inbox placement.

How to ensure DNS consistency

Check your DNS zone for both A and AAAA records pointing to the same mail server IP addresses. Use a tool like MXToolbox to verify the full record set. If only one record type appears, update your DNS provider’s settings to include both.

Some providers (like Cloudflare or AWS Route 53) support dual-stack configuration directly in DNS management panels. Make sure the TTL (time to live) is aligned across both records to avoid inconsistent results.

For teams managing bulk sending, a single misconfigured MX record can mean thousands of failed deliveries. That’s why validating your entire email infrastructure—including DNS—is foundational. Clean your email list with real-time checks to catch invalid or misrouted addresses before sending.

How to verify that your MX record is available on both IPv4 and IPv6

You can verify MX record availability on both IPv4 and IPv6 by querying your DNS using tools like MxToolbox or the dig command. Check that your MX record resolves to at least one valid A record (IPv4) and one valid AAAA record (IPv6). Monitor propagation globally after any DNS change, as inconsistent results across networks can impact email delivery.

Use DNS tools to check both IPv4 and IPv6 resolution

Run dig MX example.com to fetch your MX record and note the mail server hostname.
Then query dig A mail.example.com to check IPv4 resolution and dig AAAA mail.example.com for IPv6.
If either returns no answer or a timeout, your delivery path is incomplete on that protocol.
Use MxToolbox to validate across multiple global points in real time — a trusted tool used by network operators for diagnosing delivery failures.

Confirm full IPv4 and IPv6 reachability after changes

DNS changes can take 24–48 hours to propagate fully, especially on large networks.
Check multiple locations using tools like IANA’s DNS root server status or public DNS health monitors.
If you only see A records but no AAAA, IPv6 support is missing — even if your mail server supports it.
Verify both records remain consistent across multiple resolvers. Inconsistencies indicate misconfiguration or incomplete propagation.
After a DNS update, test again in 24 hours and watch logs for unexpected drop-offs in delivery.

A missing AAAA record can silently degrade deliverability for recipients on IPv6-only networks. Even if only a small fraction of users are on IPv6, failing to support it increases the risk of bounces or misclassification. Ensuring dual-stack availability is a baseline requirement for reliable inbound and outbound email.

How to configure DNS to ensure MX record availability on IPv4 and IPv6

Set up your MX record to point to a mail server hostname, then ensure that hostname has both an A record (IPv4) and an AAAA record (IPv6) with correct IP addresses. Keep the TTL at 300 seconds or lower for fast updates. Use a DNS validator to confirm both records resolve. This dual-stack setup maintains mail delivery reliability across modern networks.

Step-by-step DNS configuration

Log in to your domain’s DNS provider — use Cloudflare, AWS Route 53, GoDaddy, or another provider. This is where you control your domain’s DNS entries.
Locate the MX record for your domain — it should point to the hostname of your mail server (e.g., mail.yourdomain.com). If it’s missing or incorrect, updating it is the first step to ensuring mail delivery.
Create or update the A record for the mail server hostname — link it to the IPv4 address of your mail server (e.g., 192.0.2.1). Without a valid A record, IPv4 mail delivery will fail.
Create or update the AAAA record for the same hostname — assign it the IPv6 address of your mail server (e.g., 2001:db8::1). This enables IPv6-capable clients to route mail correctly.
Set a reasonable TTL — use 300 seconds (5 minutes) to balance performance and update speed. A longer TTL slows propagation during changes; too short can increase DNS lookup load.
Verify all records with a DNS validator — tools like MxToolbox or DNS Survey let you check if both A and AAAA records resolve to the correct IPs. Use these to test from multiple global locations.

Why this matters for deliverability

Modern email infrastructure supports both IPv4 and IPv6. If only one is configured, you risk delivery failure for ISPs that prefer or require the other stack. The IETF’s RFC 6531 defines standards for internationalized email, which includes supporting dual-stack delivery. Skipping either record increases the chance of your mail being rejected silently.

If you're managing a large list of outbound emails, consider validating the addresses before sending. Email List Validation helps ensure your recipient list is accurate and deliverable. You can clean your list in bulk to remove invalid records, reduce bounces, and improve your sender reputation.

Common DNS misconfigurations that break IPv6 email delivery

IPv6 email delivery fails when your DNS lacks AAAA records for mail server hostnames, even if A records exist. You might have functional IPv4 mail, but without proper IPv6 records, 10–20% of modern mail servers (especially in Europe and Asia) will reject or delay your messages. This happens often because administrators assume "A records are enough," but IPv6 requires explicit AAAA records to route mail.

Missing AAAA records while A records exist

Just because your mail server has an A record doesn’t mean it’s reachable over IPv6. Many organizations configure A records but skip AAAA records altogether, especially during migration. This creates a blind spot in your delivery pipeline. If a recipient’s mail server supports IPv6 and your domain doesn’t, it may drop your email or mark it as suspicious. The fix is simple: verify that every mail server hostname in your MX records has a valid AAAA record pointing to its IPv6 address.

Check this using tools like MxToolbox or DNSSEC.net, which allow testing both A and AAAA resolution. If your domain resolves over IPv4 but not IPv6, you’ve got a misconfiguration. It’s not a theoretical risk—it’s a current, measurable delivery barrier.

Outdated MX records and TTL pitfalls

Outdated MX records pointing to obsolete or decommissioned servers cause delivery failures, especially during infrastructure changes. If you’re using a legacy server that no longer handles mail, even if it’s listed in your DNS, mail will be routed to an unreachable address—especially over IPv6, where fallback routes are less forgiving. This often happens during cloud migration when old DNS records aren’t removed.

High TTL values (e.g., 86,400 seconds) compound this problem. A single wrong change can take days to resolve, creating outages during server transitions. You’re not just breaking current delivery—you’re locking your infrastructure into legacy states. Reduce TTLs to 300–600 seconds before any migration, test the new configuration, then raise them back after confirmation.

Also, consider using multiple DNS providers with global reach. Relying on one provider—even a major one—can introduce IPv6 propagation delays or regional blackout issues. Some providers still have limited IPv6 support in edge locations, so resiliency isn’t guaranteed. Diversity in DNS infrastructure improves availability.

If you're building or maintaining a high-volume email system, validating your DNS setup through a service like bulk email list cleaning can help test delivery readiness across multiple protocols, including IPv6 routing.

What happens when MX records are not available on both IPv4 and IPv6

If your MX records only resolve on IPv4 and not IPv6, receiving servers that prioritize IPv6 may time out during connection attempts, resulting in soft bounces. This inconsistency forces systems to fall back to IPv4, increasing delivery delays and raising bounce rates. Over time, this behavior signals unreliable infrastructure to spam filters, hurting your sender reputation.

Connection timeouts and delivery delays

Modern mail servers are increasingly IPv6-capable. If your MX record isn’t reachable via IPv6, a receiving server may attempt a connection and wait up to 60 seconds before timing out—longer than many systems are willing to wait. This timeout triggers a soft bounce, which the recipient’s server may retry later. But if IPv6 is consistently unavailable, those retries fail, and delivery can be delayed by minutes or even hours. According to RFC 8314, IPv6 is now an accepted standard for email transport, and servers are expected to support it.

Reputation and spam filter implications

Spam filters increasingly analyze delivery behavior as part of sender reputation. Inconsistent MX record availability—especially failing on IPv6—suggests either misconfiguration or weak infrastructure. This pattern can raise red flags, particularly if other signals (like DNSBL entries or low engagement) are already weak. A single failed IPv6 connection doesn’t doom your email, but repeated failures can degrade your score over time. Receiving systems may begin rate-limiting your messages or routing them to folders, even if they’re technically valid.

Let’s be clear: this isn’t just about being "technically ready" for IPv6. It’s about ensuring reliability across all modern network paths. Many email-verification tools can check MX reachability across both protocols, but few validate the full path. If your list includes addresses with misconfigured or unresponsive MX records, your deliverability suffers—not just for new recipients, but for existing ones who may have recently switched to IPv6-only networks.

Using a service like bulk email list cleanup helps you identify and remove invalid or unstable records before sending, improving delivery consistency and lowering bounce rates. Ensuring both IPv4 and IPv6 reachability is a small step—but one that compounds your sender trust over time.

How to test real-world delivery performance across IPv4 and IPv6

Test real-world delivery by sending test emails from IPv4-only, IPv6-only, and dual-stack sources to monitor SMTP errors like 421 (service not available) or 451 (temporary failure). Use inbox placement tools to validate delivery outcomes across both protocols, then verify your provider supports both IPv4 and IPv6 endpoints for outbound mail. This reveals whether your DNS configuration truly enables reliable delivery in mixed environments.

Test from multiple IP types to validate connectivity

Use your email service provider’s dedicated test environments or third-party tools such as Spamhaus to send test messages from IPv4-only, IPv6-only, and dual-stack IPs.
Ensure your test setup includes real recipient inboxes (not just validation tools) to measure actual placement — not just SMTP receipt.
Log every SMTP response code during testing: 421 (service not available) indicates a transient or permanent failure in the receiving server’s ability to accept mail; 451 (temporary failure) often points to a temporary network or queue issue.
Correlate failures with your MX record availability: if IPv6-only sends fail consistently while IPv4 works, your IPv6 MX record may be missing, misconfigured, or unreachable.

Verify provider support and DNS reachability

Confirm your email provider offers both IPv4 and IPv6 endpoints for outbound delivery — some only support one or the other.
Use tools like MxToolbox to probe your MX records from both IPv4 and IPv6 locations; this helps detect if reachability varies by protocol.
Check DNS TTL settings — if record changes aren't propagating fast enough across both protocols, delivery may still fail even after fix.
Monitor logs for delayed or dropped messages during peak usage; this can expose hidden IPv6 routing or BGP issues not caught in basic checks.

Let’s be clear: having MX records for both IPv4 and IPv6 is only half the battle. You also need active, tested delivery paths. If your provider can’t route messages through both protocols, your reliability drops — even if your DNS looks perfect. Use inbox placement testing to uncover these blind spots before they impact real campaigns.

If you're validating your list before sending, you can use inbox placement testing to simulate delivery across real domains and protocols, helping you catch deliverability risks early — including those tied to outdated or incomplete DNS configurations.

How Email List Validation helps catch delivery issues before they happen

You can prevent delivery failures by validating DNS configurations—including MX records—before sending to real users. Email List Validation checks for missing, incorrect, or inconsistent MX records, and tests inbox placement across multiple email networks to ensure your messages reach inboxes. It also flags domains with outdated or dual-stack (IPv4/IPv6) issues, so you catch problems before they hit your sender reputation.

Pre-send DNS diagnostics catch real delivery risks

Before sending to a list, you need to know if the domain’s MX records are correctly configured and resolvable. An invalid or missing MX record means your email gets rejected at the first step. Email List Validation checks for this directly during bulk verification—no need to wait for bounces. It validates DNS resolution in real time, flagging domains with inconsistent records or expired configurations that could break delivery.

For example, if a domain’s email infrastructure relies on outdated DNS entries or only supports IPv4 while your infrastructure is dual-stack, delivery will fail on IPv6-capable networks. This is common with legacy setups. Email List Validation detects these issues by testing both IPv4 and IPv6 reachability, verifying that your sending infrastructure is fully compatible with modern email environments.

Inbox placement testing proves deliverability in real-world conditions

Knowing the MX record exists isn’t enough. You need to confirm the message actually lands in the inbox—not spam or a blocked folder. Email List Validation includes inbox-placement testing across major providers like Gmail, Yahoo, Microsoft, and ProtonMail. These tests simulate real sending conditions and reveal whether your domain, IP, or message content will pass filtering.

By doing this before you send, you avoid wasted sends and reputational harm. If your domain has a history of failed deliveries or inconsistent DNS, the tool will identify it early. This is especially important for high-volume senders or those using new IPs or domains. You can also compare results across different sending setups, which helps tune deliverability performance. For more on how it works, see the inbox-placement test details here.

For teams managing large lists, the real-time API or bulk verification tools let you validate entire databases in minutes. Clean your list in bulk before campaigns. This proactive checking is standard practice at scale—and it’s how top deliverability teams stay out of spam traps and blocklists.

Final checks: verifying your configuration is production-ready

You’re not done once you’ve set your MX records. Run a DNS scan from multiple geographic locations to confirm resolution works everywhere. Check that SPF, DKIM, and DMARC are also properly configured—these rely on DNS and can block delivery even if MX is correct. After any infrastructure change, revalidate MX availability. And make sure your email list only includes active, deliverable addresses using a service like Email List Validation.

Confirm global DNS resolution

Use a multi-location DNS checker like MXToolbox to test your MX record from servers across North America, Europe, and Asia.
Look for consistent results—no regional dead zones or timeouts. Latency above 150ms in any location can signal issues.
Repeat the test after every DNS change to catch propagation delays. It can take up to 72 hours for global propagation.

Validate authentication and deliverability

Double-check SPF: ensure it doesn’t exceed the 10-include limit, and that it only lists authorized sending IPs and domains.
Verify DKIM: keys must be correctly published in DNS with valid selectors; use RFC 6376 as reference for proper signature format.
Confirm DMARC policy is set to monitor (p=none) before enforcing. An incorrect policy may cause legitimate emails to be dropped.
Run a deliverability test using a platform like Email List Validation’s inbox placement tests to see how your messages perform across real inboxes.
Revalidate MX availability after upgrading mail servers, changing providers, or moving infrastructure.
Run your email list through a bulk verification tool such as bulk email list cleaning to remove invalid, dormant, or disposable addresses that harm your sender reputation.

Even perfect MX records won’t save delivery if SPF or DKIM fail. DNS is the foundation—get it wrong, and everything else crumbles.

Let’s be clear: no tool prevents every problem. But by testing globally, validating DNS alignment, and cleaning your list, you reduce risk significantly. You’re not just checking boxes—you’re building a durable delivery path. And yes, you can automate this with Email List Validation's real-time email verification API, so you’re always sending to addresses known to be active.

Maintaining MX record availability in a changing network environment

MX records must consistently resolve to valid mail servers to avoid delivery failures. Even small misconfigurations or outdated IP addresses can cause bounces, degrade sender reputation, and reduce inbox placement.

Key Maintenance Practices

Schedule DNS audits every 90 days to detect and correct misconfigurations before they impact delivery.
Monitor bounce rates and delivery success metrics closely. Correlate spikes with recent DNS or infrastructure changes.
Use automated tools like Email List Validation’s real-time API to verify domain validity and MX record reachability at scale.
Ensure your DNS provider reflects current IP configurations for both IPv4 and IPv6, especially after server migrations or infrastructure updates.

Consistency in DNS setup ensures reliable email delivery across evolving network environments. Proactive monitoring and verification are not optional — they’re foundational.

Keep reading

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

Frequently asked questions

Can I have an MX record with only IPv4 and still deliver emails?

Yes, but only if the receiving server supports IPv4. Many modern systems now require IPv6 connectivity, and partial availability can result in delayed or failed delivery.

What happens if my AAAA record is missing for an MX host?

Email sent to IPv6-only recipients may fail or time out. The system will fall back to IPv4, but this increases latency and can trigger delivery failures on strict filters.

How long does it take for DNS changes to propagate globally?

Typically 1 to 24 hours. High TTL values can extend this to days. Use a global DNS checker to verify propagation.

Do all email providers support IPv6 connections?

Most major providers (Gmail, Outlook, Yahoo) support IPv6, but not all have full dual-stack readiness. Delivery reliability depends on the entire chain.

What is the impact of missing AAAA records on sender reputation?

It can indirectly harm sender reputation by causing delivery inconsistencies. Reputational metrics account for delivery success, and repeated partial failures are flagged by filters.

Can Email List Validation check if a domain has working MX records?

Yes. It verifies MX record resolution and domain availability in real-time, flagging domains with missing or incorrect records.

Do I need both A and AAAA records for every mail server hostname?

Only if your server supports both IPv4 and IPv6. If supporting only one, only that record is required. For dual-stack readiness, both are essential.

What is the difference between an A record and an AAAA record?

An A record maps a hostname to an IPv4 address. An AAAA record maps a hostname to an IPv6 address. Both are needed for full network compatibility.

How can I test if my mail server accepts IPv6 connections?

Use a tool like https://ipv6-test.com to check server connectivity. Or send test emails through providers that enforce IPv6 delivery.

Is dual-stack DNS support required for sending transactional emails?

Yes, especially for global campaigns. Ignoring IPv6 increases the chance of delivery failure, particularly with newer or mobile-focused providers.

How does Email List Validation help prevent sending to domains with broken DNS?

It checks for valid MX records, DNS resolution, and server availability during bulk verification, reducing the risk of bounces and reputation damage.

Can a domain have multiple MX records with different IPs?

Yes, but they must be ranked by priority. If one fails, delivery falls back to the next. All referenced hostnames still need valid A and AAAA records.