Postfix IPv6 Preference

Why Does Postfix Choose IPv6 Over IPv4 for Outbound Mail?

Ever sent a message only to find it stuck in limbo—no bounce, no error, just silence? You’re not alone. When Postfix picks IPv6 over IPv4 for outbound mail, it’s not a choice—it’s a system default.

Postfix doesn't decide this on its own. It follows the operating system’s address selection logic, which, by default, prefers IPv6 when both protocols are available. The result? A perfectly valid email, sent from a well-configured server, fails—not due to mail configuration, but because the remote server doesn’t handle IPv6 properly or a firewall blocks it.

This behavior is invisible until it breaks. You might see timeouts, connection resets, or a lack of delivery feedback—only to realize the root cause was a misaligned network stack preference.

Key takeaways

Postfix uses the OS-level address selection preference, which defaults to IPv6 when both IPv4 and IPv6 are available.
Outbound delivery fails silently when the remote server lacks IPv6 support or has restrictive firewalls, even if IPv4 would work.
Adjusting the system's network stack preference (e.g., via /etc/gai.conf) or enforcing IPv4 in Postfix via smtp_address_preference can prevent these misfires.

How smtp_address_preference Controls Postfix's IPv6 Behavior

You can control whether Postfix prefers IPv4 or IPv6 when sending mail using the smtp_address_preference setting. When set to ipv4, Postfix sticks to IPv4 even if IPv6 is available. Set to ipv6, and it will choose IPv6 if possible—ideal in IPv6-native networks. The default, none, lets the OS decide, which often leads to unpredictable results. This is especially important when mail delivery depends on consistent routing behavior.

Why Default Behavior Can Cause Issues

With smtp_address_preference = none, Postfix defers to the underlying OS’s address selection logic. On systems with dual-stack support, this often means IPv6 is used first—unless the IPv6 path is broken or blocked. But if your ISP or recipient server has partial IPv6 support, this can result in failed deliveries or long timeouts. You might not notice it immediately: a 45-second delay on a single connection can quietly degrade your sending queue over time.

Setting Your Preferred Protocol

If you're in a dual-stack environment and want consistent behavior, explicitly define your preference. Set smtp_address_preference = ipv4 if you're still relying on IPv4-only infrastructure, or ipv6 if your network is fully IPv6-enabled. This is a simple config change in main.cf, but it has real consequences on delivery timing and success rates. Many organizations do this when they’ve seen inconsistent results from relying on default choices.

For a deeper look at how modern mail systems handle transport layer decisions, the Internet Engineering Task Force (IETF) provides clear guidance on address selection in RFC 6555, which outlines the "Happy Eyeballs" algorithm commonly used in modern stacks. While not directly part of Postfix, understanding this principle helps explain why default OS behavior varies across systems.

When diagnosing delivery issues, especially in high-volume or time-sensitive campaigns, validating the actual path mail takes—including the protocol used—is critical. If you're unsure whether your SMTP transactions are using the expected IP version, you can test actual delivery paths using a service that mimics real-world sending behavior. Try a real-time inbox placement test to validate how your mail behaves across major inboxes, including the underlying network path.

How to Set smtp_address_preference in Postfix for IPv6 Control

You can control Postfix’s IPv4 vs. IPv6 outbound behavior by setting smtp_address_preference = ipv4 in the main configuration file. This forces Postfix to prefer IPv4 when connecting to remote mail servers, which helps avoid issues with IPv6 misconfigurations or poor routing. Changes take effect after reloading Postfix, and you can verify the setting with postconf.

Configure Postfix for IPv4 Preference

Open your Postfix main configuration file using a text editor: sudo nano /etc/postfix/main.cf. This file controls how Postfix handles mail delivery, including network choices.
Add or modify the line smtp_address_preference = ipv4. This explicitly tells Postfix to prefer IPv4 addresses when resolving MX records and establishing outgoing SMTP connections. RFC 6560 notes that IPv6 adoption in email systems is still uneven, so falling back to IPv4 can improve reliability.
Save the file and reload Postfix to apply changes: sudo postfix reload. This restarts the configuration without stopping mail delivery, ensuring minimal disruption.
Verify the change is in effect: postconf | grep smtp_address_preference. The output should show smtp_address_preference = ipv4. If it doesn't, double-check spelling and syntax in the config file.

Why This Matters for Deliverability

While IPv6 is growing, many domains still have incomplete or inconsistent IPv6 setups. If your server tries to deliver to an IPv6-only endpoint that's unreachable, the connection may timeout or fail. Forcing IPv4 can reduce these issues, especially in environments with mixed-stack infrastructure. This small change improves reliability on the outbound path, which contributes to better sender reputation over time.

Even if you’re not directly managing mail infrastructure, understanding this setting helps you diagnose issues like delayed deliveries or timeouts. When working with mail verification tools, especially during inbox placement tests, consistent outbound behavior is key. You can use inbox testers to see how your messages land under real-world routing conditions—this includes assessing whether network-level choices like this affect delivery outcomes.

When to Disable IPv6 Outbound in Postfix

You should disable IPv6 outbound in Postfix when remote mail servers don’t support IPv6, when you’re hitting frequent connection timeouts or DNS issues with IPv6 addresses, when testing deliverability to ensure consistent routing, or when running legacy systems where IPv6 is unstable or misconfigured. These scenarios can introduce unpredictability in email delivery and undermine your sender reputation.

Identify problematic destinations

Check if remote mail servers you’re sending to advertise IPv6 in their MX records but don’t accept connections on IPv6 addresses. Use tools like MxToolbox to verify connectivity and DNS configurations.
Monitor your mail logs for Connection timed out or Address family not supported errors when connecting to IPv6 addresses — these indicate underlying transport issues.
If a high percentage of your outbound deliveries fail on IPv6 only, it's a signal to either disable IPv6 outbound or reconfigure your network path.

Use consistent testing for reliable results

When testing deliverability, ensure all tests use the same protocol path. If you rely on IPv6 in one location and IPv4 in another, your results won’t be comparable.
Use inbox placement testing to verify that email delivery behavior matches your expectations on both IPv4 and IPv6 paths. If results diverge, disable IPv6 outbound to stabilize the baseline.
If you're debugging email delivery issues across multiple networks (e.g., internal test vs. public cloud), ensure both environments use the same IP version to isolate the variable.

IPv6 is not universally reliable at scale. Many large ISPs and enterprise networks still route IPv6 traffic through suboptimal or poorly monitored paths. Let’s be honest: not all systems are ready. If your mail server is behind a firewall that drops or delays IPv6 packets, or if the remote MTA simply doesn’t respond on IPv6, forcing it only increases delivery failures and harms your sender reputation.

Disabling IPv6 outbound won’t break your system. It will just make it predictable. You can still use IPv6 internally or for incoming mail — but for outbound, locking to IPv4 often delivers more stable results, especially when working with older or non-compliant infrastructure. This is especially true in hybrid environments where some servers are IPv6-ready and others aren’t, creating inconsistent delivery paths.

The Impact of IPv6 Preference on Email Deliverability

Setting smtp_address_preference to IPv4 can reduce email delivery failures when IPv6 endpoints are unreachable or misconfigured, especially in networks with poor IPv6 routing. Forcing IPv4 ensures more consistent connection attempts, lowering bounce rates caused by temporary or failed IPv6 handshakes. However, ignoring IPv6 entirely may risk future compatibility in environments where IPv6 is the default.

Why IPv4-Only Routing Can Improve Reliability

If your mail server prefers IPv6 but encounters broken AAAA records or misrouted paths, delivery can stall. Some MTAs never retry when IPv6 fails—especially if they don’t fall back to IPv4. Let’s be clear: IPv6 support is growing, but not uniformly. For organizations still grappling with incomplete IPv6 deployment across the internet, enforcing IPv4 via smtp_address_preference = ipv4 often results in fewer undeliverable messages.

This is particularly relevant for legacy infrastructure or networks with incomplete DNS propagation. When an MX record returns only an AAAA record and no A record, and IPv6 routes are flaky, email simply fails. Testing with tools like MxToolbox or RFC 3587 shows that AAAA-only records are still common—but not all destinations are equipped to handle them reliably.

When You Might Be Future-Proofing the Wrong Way

If your internal network runs on full IPv6 and all downstream infrastructure supports it, forcing IPv4 may be unnecessarily restrictive. You could miss delivery opportunities with domains that only announce IPv6 endpoints. Ignoring IPv6 doesn't protect your deliverability—it just limits your reach.

That’s why measuring bounce rates before and after adjusting smtp_address_preference is critical. If you see a drop in bounces after switching to IPv4, it signals IPv6 was the bottleneck. If not, you’re likely not benefiting from the change, and continuing to support IPv6 is safer for long-term compliance.

Before you make infrastructure changes, verify the health of your outbound lists. Use a real-time email checker like MailTester’s email checker to validate addresses and detect common delivery blockers—like malformed DNS or role accounts—before they affect delivery. For larger campaigns, bulk verification helps isolate problematic domains early.

Testing Postfix’s Connection Behavior with Real Addresses

You can test how Postfix chooses between IPv4 and IPv6 when sending mail by sending messages to real domains like gmail.com or outlook.com and checking the connection trace in the delivery logs. Use real-world testing via MailTester’s inbox-placement feature to see whether your server connects over IPv4 or IPv6 in practice, and compare results before and after adjusting smtp_address_preference.

Verify Real-World Behavior with Live Test Messages

Let’s send a test message to a known good domain—say, [email protected]—and check the SMTP connection trace. Look at the remote IP address in the logs; it will show whether Postfix used IPv4 or IPv6. This is critical because even if DNS resolves both A and AAAA records, the actual path chosen depends on your server’s configuration and network stack.

Use MailTester’s inbox-placement tester to simulate this process at scale. It sends real messages to major inboxes and returns detailed connection reports, including the source and destination IP versions. It’s one of the most reliable ways to validate whether your Postfix setup is favoring IPv6 when intended, or falling back to IPv4 unexpectedly.

Compare Results Before and After Configuration Changes

Before adjusting smtp_address_preference, run a series of tests and record how often Postfix connects via IPv4 versus IPv6. Then, set smtp_address_preference = ipv6 and repeat the same tests. Any shift in behavior should be visible in the connection logs.

Watch for signs that IPv6 connections fail more often—especially timeouts, 5xx errors, or DNS resolution issues. These can signal that a remote server doesn’t fully support IPv6 or that intermediate routing is misconfigured. According to RFC 8310, IPv6 adoption is growing, but not all mail servers have fully converged on dual-stack support. This isn’t a bug—it’s a reality.

If you see more connection timeouts or temporary failures after enabling IPv6 preference, consider whether your infrastructure routes IPv6 correctly. It may be safer to leave smtp_address_preference at its default (which favors IPv4) unless you’re certain your peers support IPv6 end-to-end. You can always test this with tools like MxToolbox or via email verification services that track delivery paths.

How to Verify SMTP Behavior Against Real Recipients

You can confirm whether Postfix is using IPv6 as intended by sending a test email to a verified address, then inspecting the actual connection via tcpdump or tshark. Cross-reference the observed IP with DNS A and AAAA records to verify alignment. This approach reveals if SMTP_ADDRESS_PREFERENCE is working as expected, avoiding assumptions from logs alone.

Test the Send Path with Real Traffic

Send a test message using Postfix’s sendmail or ssmtp to a known good email address with predictable DNS behavior. This ensures the queue reflects actual outgoing attempts, not just local delivery decisions.
Use tcpdump -i any port 25 -n or tshark -i any port 25 in the background during the send. This captures the raw TCP connection handshake and reveals the remote peer IP used, independent of Postfix’s internal routing decisions.
Immediately after the connection is established, note the destination IP address displayed in the packet capture. This is the actual endpoint your server reached, whether IPv4 or IPv6.
Use dig A domain.com and dig AAAA domain.com to query public DNS. Check if the domain advertises IPv6 (AAAA) records. If it does, but your server connected via IPv4, the smtp_address_preference setting may not be applying correctly.
Compare the DNS results with the capture. If the destination supports IPv6 but the connection used IPv4, the post-queue routing is likely favoring v4 despite the configuration. This can happen due to network policy, missing IPv6 connectivity, or incorrect local route precedence.

Validate Configuration Behavior in Practice

Postfix’s smtp_address_preference defaults to ipv6 if available, but behavior can vary based on the underlying system, routing table, and network stack. You can verify that Postfix is respecting this by testing a domain that only has AAAA records. If it still connects via IPv4, the system is not respecting the preference — likely due to system-level IPv6 issues.

The 5 steps described in “Test the Send Path with Real Traffic”, in order.

For context, the RFC 6531 (SMTP-AUTH and Internationalized Email) and modern SMTP implementations define how address preferences should be managed, but real-world behavior depends on operational setup. The behavior should be tested against real recipients, not just configuration files.

“Configuration parameters matter, but only when they’re reflected in actual network behavior.” — Real-world deliverability testing

Use a tool like MailTester’s inbox placement tester to validate not just delivery, but whether the connection chain aligns with intended routing. This ensures the outbound path matches both your config and your recipient’s DNS records.

Best Practices for IPv6 and SMTP Delivery in Production

You must test both IPv4 and IPv6 routes to major providers like Gmail and Outlook using real email verification tools, monitor SMTP return codes like 554 or 421 to isolate delivery failures, and use your email verification tool to catch invalid, catch-all, or role account issues before sending. Set smtp_address_preference to 'ipv4' if IPv6 connection attempts fail more frequently. Integrate with platforms like SendGrid or Mailchimp for better routing and fallbacks, and validate addresses in real time before sending.

Verify Connectivity and Behavior in Production

Use MailTester’s inbox placement testing to simulate real delivery to Gmail, Yahoo, and Outlook from both IPv4 and IPv6 endpoints.
Check for consistent delivery issues by examining bounce logs and tracking SMTP codes—554 (rejected) or 421 (service not available) often point to protocol-level problems.
Don’t assume IPv6 is always faster or more reliable. Test actual delivery paths, as some ISPs still have incomplete or unstable IPv6 implementations.

Optimize Configuration and Delivery Flow

If IPv6 connections fail more often than IPv4, set smtp_address_preference to ipv4 in your Postfix configuration to ensure reliable outbound delivery.
Validate every email address before sending with MailTester’s real-time API, which detects catch-all domains, role accounts (like admin@), and invalid formats.
For high-volume sending, integrate your workflow with SendGrid or Mailchimp to leverage their established delivery paths, IP reputation, and fallback mechanisms.
Use tools like RFC 6561 and IANA’s IPv6 address allocation to understand how IPv6 routing and assignment affect delivery.
Monitor your sender reputation and DMARC alignment across both protocols—some providers treat IPv6-only senders differently in spam filtering.

Even when IPv6 is enabled, relying solely on it can hurt deliverability if the target server doesn’t resolve it correctly. Prefer proven paths over theoretical ones.

Understanding MailTester’s Role in Preventing SMTP Failures

You can avoid SMTP failures caused by invalid, role-based, or catch-all emails by using MailTester to scrub your list before sending. It flags domains with weak IPv6 reachability and reduces false positives with a 98.9% accuracy rate. With 100 free credits, you can test large lists risk-free and integrate verification into your workflow without upfront cost.

Preventing Failures Before They Happen

SMTP delivery fails when you send to addresses that don’t exist, are role-based (like admin@ or sales@), or belong to catch-all domains. These are common sources of bounce loops, blocked IPs, and blacklisting. MailTester detects them early—before you even hit the SMTP server—so you don’t waste send capacity or risk reputation.

Let’s say you’re sending to a list with 20% invalid or role-based addresses. Without verification, those attempts generate hard bounces, which hurt your sender reputation. MailTester identifies these in real time with a 98.9% accuracy rate, a benchmark that aligns with industry-standard practices for email validation tools. It’s not perfect, but it’s consistently better than random guesswork or basic regex checks.

Testing at Scale Without Risk

Many teams skip list hygiene because they fear cost or complexity. But MailTester offers 100 free verifications to start—no obligation, no expiry. This lets you test your verification logic, benchmark performance across domains, or validate the quality of a new list without spending a cent.

Some domains perform poorly over IPv6, which can cause outbound SMTP delays or timeouts. MailTester’s bulk list verification flags domains with weak IPv6 reachability, giving you a chance to filter or adjust delivery routes. While IPv6 is increasingly standard—adopted by 40% of the top 1 million websites (per netmarketshare.com)—not all providers route it efficiently. This can manifest as delayed delivery, even with working DNS records.

Whether you're using a tool like Postfix with smtp_address_preference to prefer IPv6, or relying on default routing, you need to know if the target address is even reachable. That’s where verification helps. For single-verify checks, use the email checker. For automated workflows, integrate via the verification API. If you’re assessing real-world inbox placement, test delivery through the inbox tester and see how your messages land across providers. All are available within the same platform.

By verifying your list in advance, you reduce SMTP failure rates, protect sender reputation, and ensure your messages reach the inbox—not the quarantine. It's proactive hygiene, not reactive cleanup.

Why Outbound Address Preference Matters for Deliverability

When your mail server defaults to IPv6 for outbound connections, misconfigured DNS, firewall rules, or broken IPv6 routing can cause SMTP handshake failures. These failures result in hard bounces or timeouts, both of which hurt sender reputation and reduce inbox placement. Consistent IPv4 routing minimizes that risk, especially on networks where IPv6 is still unreliable. Using tools like MailTester to verify email lists helps catch domains with unstable IPv6 endpoints before they cause issues. Clean lists with low bounce rates directly support better deliverability.

SMTP Failures and the Real Cost of Outbound Routing

A failed SMTP connection isn't just a delay—it's a signal to inbox providers. Each timeout or connection refusal adds to a sender’s reputation score degradation. Even if the email ultimately delivers, a failed attempt often counts as a failure in aggregate metrics used by filtering systems. This is especially true when IPv6 endpoints are unreachable due to incomplete dual-stack support, leading to a disproportionate number of delivery drops.

Many ISPs and hosting providers have well-documented IPv6 misconfigurations. While IPv6 adoption is increasing, it's still patchy. A server that prioritizes IPv6 may fail silently when encountering a poorly maintained zone, while falling back to IPv4 maintains consistent delivery. This consistency reduces the number of false negatives and prevents reputation damage from unexplained failures.

Proactive List Health with Email Verification

Before sending to any list, you should verify the infrastructure behind each domain. Domains with unreliable IPv6 endpoints—especially those with missing DNS records or misconfigured reverse lookups—are more likely to bounce or be flagged. Tools like MailTester’s bulk verification service check entire lists for these red flags, including issues tied to address preference and network stability.

This isn’t just about email syntax. It’s about infrastructure health. A catch-all email that accepts any address isn’t automatically valid—it could be a sign of poor server configuration. Similarly, domains that consistently resolve to unreachable IPv6 records should be flagged. MailTester’s 98.9% accuracy rate means you’re not just filtering invalid syntax—you’re also catching domains prone to delivery failure due to routing quirks.

When you maintain a clean list, you reduce both hard bounces and time-to-delivery variance. ISPs track these signals closely. Low bounce rates correlate with better sender reputation and higher likelihood of landing in the inbox. You can’t control every network’s IPv6 setup, but you can stop sending to domains with known weaknesses. This is where email verification becomes not a technical nicety, but a deliverability necessity. For real-time checks, use the MailTester API to catch issues before they impact your email stream. And if you're sending in volume, integrate with tools like Mailchimp or Klaviyo for automated list hygiene. Consistent routing, reliable infrastructure, and clean data—these are the quiet foundations of inbox placement.

Conclusion: Tune Postfix IPv6 Preference for Reliable Delivery

smtp_address_preference is a subtle but effective lever for improving delivery consistency, especially in environments where IPv6 connectivity is inconsistent or misconfigured.

Setting it to 'ipv4' ensures outbound mail uses IPv4 by default, reducing the chance of delivery delays or rejections caused by IPv6 routing issues. This is particularly valuable for servers with mixed or unstable network stacks.

Always validate changes with real-world testing. Tools like MailTester allow you to test delivery in actual inbox conditions, confirming your configuration improvements translate to better inbox placement.

Combine proper configuration with clean email lists and regular inbox placement testing. These practices together deliver the most reliable outbound email performance.

Sources

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

What does smtp_address_preference do in Postfix?

It determines whether Postfix prefers IPv4 or IPv6 when establishing outbound SMTP connections. Default is 'none', meaning the OS decides.

Should I disable IPv6 outbound in Postfix?

Only if you consistently face SMTP connection failures and confirm that IPv6 is the root cause. Disable it only after testing with real recipients.

How do I test if Postfix is using IPv6 for outbound mail?

Use tcpdump to capture network traffic while sending mail and check the remote IP address used. Verify with DNS lookup tools if the address is AAAA or A.

Can IPv6 cause email delivery failures?

Yes. Misconfigured IPv6 routes, unreachable endpoints, or firewall rules can block connections even if the domain resolves correctly.

Does Postfix automatically prefer IPv6?

No. By default, Postfix follows the OS’s address selection policy, which often favors IPv6 when available. This can lead to undetected delivery issues.

How does MailTester help with IPv6 delivery issues?

It verifies email validity before sending, reducing the chance of sending to unreliable domains. High accuracy helps catch problematic addresses early.

Can MailTester detect if a domain has IPv6 issues?

Not directly, but by identifying high failure rates on certain domains, it can flag them for further investigation into routing or DNS issues.

What is the impact of forcing IPv4 in Postfix?

It reduces delivery failures due to unstable or misconfigured IPv6 paths, improving consistency and reliability for outbound mail.

How do I set smtp_address_preference to ipv4?

Add smtp_address_preference = ipv4 to your main.cf file and run 'postfix reload' to apply the change.

Do I need IPv6 support for modern email delivery?

Not strictly. IPv4 remains sufficient for most deliverability needs. IPv6 is beneficial only when both ends support it reliably.

What’s the difference between Postfix IPv6 preference and DNS resolution?

DNS resolution (A vs AAAA records) determines available addresses. Preference controls which one Postfix tries first during SMTP connection attempts.

How often should I audit my Postfix IPv6 settings?

After network changes or when delivery problems arise. Use real verification and monitoring tools to assess impact.