IPv6 and email deliverability: what actually changes

IPv6 itself is not penalised. A correctly configured IPv6 sender delivers fine. The problem is that receivers hold IPv6 to a stricter standard than IPv4 — and most servers that start sending over IPv6 were never configured for it. Half-configured IPv6 is the worst state your mail can be in.

The short answer

Sending over IPv6 does not hurt deliverability by itself. Gmail and Microsoft both accept IPv6 mail, and both publish requirements for it. What hurts is the gap between the two protocols: checks that are merely "good practice" on IPv4 are hard requirements on IPv6. Meet them and you deliver. Miss one and IPv6 mail fails harder and faster than IPv4 mail ever would.

What receivers require from IPv6 senders

• A PTR record, forward-confirmed. Your IPv6 address must reverse-resolve to a hostname, and that hostname must resolve back to the same IPv6 address (FCrDNS). A missing or generic PTR on IPv4 is sloppy; on IPv6, Gmail and Microsoft reject for it outright.
• SPF that actually covers the IPv6 address. Your record must include the sending IPv6 range via an ip6 term, or an include that covers it. Good news: ip6 terms cost zero DNS lookups, so they don't eat your 10-lookup budget.
• DKIM and DMARC, unchanged. Authentication is protocol-agnostic — the same signatures and alignment rules apply. But there is no slack: on IPv6, receivers expect SPF or DKIM passing with alignment, every time.
• A reputation you build yourself. IP reputation belongs to the exact address, not the server or the domain. Your IPv6 address starts with zero history no matter how good your IPv4 reputation is — it needs its own warmup.

Why IPv6 reputation is fragile

IPv6 space is enormous, so receivers can't track addresses the way they do in IPv4. Two consequences follow. First, unknown IPv6 addresses get extra suspicion by default, because there is no track record to trust. Second, many blocklists and filters operate on the /64 range rather than a single address. If your hosting provider assigns you an address inside a /64 that someone else abused, you can inherit their problem. A dedicated IPv6 address — ideally in your own clean /64 — is the safe setup.

Microsoft deserves a specific mention: its IPv6 acceptance has historically been the least reliable of the big receivers, with deferrals and connection-level rejections common even for configured senders. This is why many high-volume senders and ESPs deliberately route Outlook.com, Hotmail, and Live.com traffic over IPv4 while sending IPv6 elsewhere. Tools like PowerMTA support per-domain routing for exactly this reason.

The silent failure: dual-stack servers

The most common IPv6 deliverability problem is not a deliberate IPv6 rollout. It's a server upgrade. Dual-stack servers prefer IPv6 by default, so the day your host enables IPv6, your mail quietly starts leaving over the new addresses — while your SPF record, PTR setup, and reputation work were all built for IPv4. The symptoms are distinctive: sudden SPF failures or outright rejections at Gmail and Microsoft only, while IPv4 receivers keep accepting your mail. If delivery broke "for no reason" after a server or network change, check which protocol the mail actually left on before you touch anything else — the fix is in your headers, where the sending IP is recorded.

Should you send over IPv6?

1. IPv4-only today? Nothing to do. IPv4 sending is fully supported everywhere and will be for years.
2. Dual-stack or IPv6-capable server? You have exactly two safe options. Either configure IPv6 completely — dedicated address, forward-confirmed PTR, SPF ip6 coverage, slow warmup — or pin your mail server to send over IPv4 and disable IPv6 sending entirely.
3. Sending to a lot of Microsoft addresses? Route those domains over IPv4 even if the rest of your mail goes IPv6. It is what the big senders do, for good reason.

Whichever route you choose, verify the basics afterwards: run your domain through the free deliverability checker to confirm SPF, DKIM, and DMARC are all in place, and send test mail to Gmail and Outlook accounts to see which protocol it arrives on.