Why an IPv6-only mail server doesn't work — and what to do instead

You'd think in 2026 that running a mail server on IPv6 alone would be reasonable. It isn't. Mail is one of the few places where IPv6-only is still a deliverability disaster, and the failure modes are subtle enough that you might not notice for days. This article covers why, and the realistic options.

The core problem

Two SMTP-side issues compound:

1. Many mail servers don't have working IPv6 outbound. Their IPv6 may be misconfigured, missing PTR records, or absent entirely. When they try to deliver to your IPv6-only MX, the connection fails and they fall back to... no IPv4 fallback exists, so the message bounces.
2. Major mailbox providers treat IPv6 mail with suspicion. Google, Microsoft, Yahoo, etc. require IPv6 senders to publish PTR records, valid SPF, and DKIM — same as IPv4 — but the requirements are enforced more aggressively because IPv6 hosts are often part of compromised botnets. Misconfigured IPv6 sender → mail goes to spam at best, rejected at worst.

The result: an IPv6-only mail server can send mail to perhaps 70% of destinations and receive from perhaps 80%. The 20-30% that fails is silent — bounces don't always reach you, and "your mail didn't arrive" complaints take days to surface.

What the standards say vs what actually works

RFC 6186, RFC 8314, RFC 5321 all establish that IPv6 mail is fully supported. They're correct. The Internet as deployed doesn't honor them uniformly. As of 2026, dual-stack (IPv4 + IPv6) is the only safe configuration for a mail server.

What to do instead

Option 1: dual-stack (recommended)

Every LYLIX VPS gets one IPv4 and one IPv6 by default. Run your mail server bound to both, publish A and AAAA records for the MX, publish PTR records for both, SPF that includes both, DKIM-signed outbound.

# /etc/postfix/main.cf
inet_interfaces = all
inet_protocols = all

# DNS:
example.com.       IN MX 10 mail.example.com.
mail.example.com.  IN A    192.0.2.10
mail.example.com.  IN AAAA 2001:db8::10

# PTR (set in the LYLIX portal — IPv4 self-serve, IPv6 by ticket):
192.0.2.10        -> mail.example.com.
2001:db8::10 -> mail.example.com.

# SPF
example.com.       IN TXT "v=spf1 ip4:192.0.2.10 ip6:2001:db8::10 ~all"

Test outbound: swaks --to test@gmail.com --from you@example.com --server localhost. Headers on the received message should show your sender IP — verify the major providers accept from both.

Option 2: relay outbound through an IPv4-capable smarthost

If you really want to run the mail server IPv6-only for some reason (you're testing, you have one IP and want it on something else), route outbound through SendGrid / AWS SES / Postmark. They'll send from their established IPv4 reputation regardless of where you're sending from.

Inbound still needs to work — if your MX is IPv6-only, the same delivery-failure issue applies for incoming. The smarthost route only solves outbound.

Option 3: pair with a frontend MX that's dual-stack

Use a hosted incoming-mail service (Mailgun, Postmark) as your MX, configure it to forward to your IPv6-only backend. They handle the dual-stack frontend; you handle the delivery to mailboxes internally.

If you must run IPv6-only, what fails most

Even today, with full dual-stack support at most providers, IPv6-only mail typically sees:

• Mail TO older corporate email systems (legacy Exchange, on-prem servers behind misconfigured firewalls) — bounces or silent drops.
• Mail TO institutional addresses (universities, government) — same issue, plus more strict spam filters.
• Mail FROM IPv6 to mailbox providers — higher spam-folder placement rate even with everything set up correctly.
• SMTP TLS handshakes failing because intermediate IPv6 routes have MTU issues — fragmented packets get dropped, handshake times out, sender retries via... no fallback because there's no IPv4.

What the LYLIX position is

LYLIX VPSes ship with both an IPv4 and an IPv6 by default specifically because of this — running a service that depends on dual-stack reachability shouldn't require special configuration. Additional IPv4 addresses can be requested per the ordering additional IPs article (request is reviewed, justification required).

One legitimate IPv6-only case

If you're running an internal mail relay between your own systems (not exposed to the public Internet), IPv6-only is fine and often simpler. The cross-Internet delivery surface is what causes the trouble. Two VPSes in the same network using IPv6 link-local or your own ULA for internal mail relay don't face any of the issues above.