Sending email over IPv6 (and to Gmail)

IPv6 is where a lot of deliverability surprises hide. Done right, it can earn better acceptance at providers that prefer it; done wrong — usually a missing reverse DNS record — it gets your mail rejected before it's even filtered. Here's what IPv6 sending actually requires — and why the same configuration that sails through on IPv4 can fail badly the moment you turn on dual-stack.

Why IPv6 matters now

Major receivers, Google chief among them, accept and often prefer IPv6. But they also apply stricter rules to it: the authentication and reverse-DNS expectations that are merely recommended on IPv4 become hard requirements on IPv6. So IPv6 is an opportunity and a tripwire at the same time.

The reason for the stricter treatment is the address space itself. IPv6 is so vast and so cheap to obtain that the per-IP reputation model that works on scarce IPv4 addresses doesn’t scale — a spammer can hop across fresh IPv6 addresses faster than any blocklist can track them. Receivers respond by leaning harder on the things that can’t be faked cheaply: a correct, stable reverse-DNS identity and passing authentication. On IPv6 those stop being reputation inputs and become entry tickets — fail them and you don’t get filtered, you get refused at the door. That single shift explains almost every IPv6 sending surprise.

What IPv6 sending requires

• A valid PTR (reverse DNS) for the sending IPv6 address — non-negotiable for Gmail.
• SPF that includes your IPv6 ranges as well as IPv4.
• DKIM signing and DMARC alignment that pass over the IPv6 path.
• Forward-confirmed reverse DNS (FCrDNS) — the PTR resolves back to a matching A/AAAA.

The requirements, in detail

The non-negotiable pair is reverse DNS and authentication. FCrDNS — forward-confirmed reverse DNS — means more than “has a PTR”: the sending IPv6 address must have a PTR pointing to a hostname, and that hostname must have an AAAA record pointing back to the same address. The loop has to close in both directions. For authentication, every sender must pass SPF or DKIM, and bulk senders (5,000+ a day to Gmail) must use DKIM and publish DMARC. Crucially, your SPF has to authorise the IPv6 address explicitly with an ip6: mechanism — an IPv4-only SPF record silently fails the moment you send over IPv6:

# confirm the PTR resolves (and then that the name has a matching AAAA)
dig -x 2001:db8:1234::25 +short      # → mail.example.com
dig AAAA mail.example.com +short     # → 2001:db8:1234::25  (FCrDNS closes)

# SPF must authorise the IPv6 range as well as IPv4
example.com TXT "v=spf1 ip4:203.0.113.0/24 ip6:2001:db8:1234::/64 ~all"

Miss any one of these on IPv6 and Gmail in particular returns a hard rejection with a specific error code rather than quietly spam-foldering, which is why an IPv4 setup that “mostly works” can collapse on dual-stack: the same gaps that cost you a few points on IPv4 cost you the whole delivery on IPv6.

The privacy-extensions trap

This one is unique to IPv6 and catches people who did everything else right. Modern operating systems, by default, use IPv6 privacy (temporary) extensions — they generate rotating, short-lived addresses for outbound connections to protect user privacy. That’s sensible for a laptop browsing the web and disastrous for a mail server: if your MTA sends from a temporary address that changes, no PTR can match it, FCrDNS fails, and the mail is rejected — intermittently and maddeningly, since it depends which address the OS picked.

The fix is to disable privacy/temporary addressing on the sending host and bind the MTA to a single, static IPv6 address — the one that has your PTR and is authorised in SPF. A mail server needs a fixed, known identity, which is the opposite of what privacy extensions provide. Pin the address, publish its PTR, set the matching AAAA, authorise it in SPF, and the intermittent failures disappear.

IPv6 reputation is its own thing

Receivers score your IPv6 addresses separately from your IPv4 ones, so a well-warmed IPv4 IP gives a fresh IPv6 address no head start. Warm IPv6 on its own schedule with engaged, opt-in recipients — the same discipline covered in dedicated vs shared IP applies to each protocol independently.

Two IPv6-specific habits matter here. Keep your sending to a small, stable set of IPv6 addresses rather than scattering across a range — a handful of warm, consistent addresses build reputation; a rotating spread of fresh ones never does, and on IPv6 fresh-and-anonymous is exactly the profile receivers distrust. And monitor IPv6-specific blocklists alongside the usual IPv4 ones, since an address can be listed on an IPv6 DNSBL while your IPv4 reputation looks fine. The reputation you build over IPv6 is a separate asset you tend separately.

Dual-stack is the approach that holds up

Rather than choosing one protocol, run both and route intelligently: send to providers that reward IPv6 (like Google) over IPv6, and keep IPv4 as the fallback for everyone else and for failover. That's how a well-built PowerMTA configuration behaves — dual virtual MTAs across both protocols, authentication correct on each, and per-provider routing. The Auto PMTA Configurator sets this up automatically, including the IPv6 PTRs and the Gmail-over-IPv6 routing that are easy to get wrong by hand.

The key framing: IPv6 is not a substitute for IPv4 reputation, it’s an addition. Plenty of receivers still expect or prefer IPv4, and a strong IPv4 footing remains foundational, so dual-stack means keeping IPv4 healthy and doing IPv6 correctly — not migrating from one to the other. Route each provider over the protocol it rewards, fail over to the other path if one has trouble, and you get the upside of IPv6 at Google without betting deliverability on a protocol some destinations still treat cautiously.

When to enable IPv6 — and when to wait

Because the penalty for getting IPv6 wrong is outright rejection rather than a soft hit, there’s a simple rule: do not enable IPv6 sending until you can do reverse DNS and authentication properly for it. If your host can’t give you a stable IPv6 address with a PTR you control, or you can’t set the matching AAAA and SPF, you are better off staying IPv4-only than sending broken IPv6 — broken IPv6 actively loses you mail that IPv4-only would have delivered.

When you can do it properly — stable address, correct PTR and FCrDNS, SPF authorising the range, DKIM and DMARC passing, privacy extensions off — enabling IPv6 to the providers that reward it is worth doing, and doing as dual-stack with IPv4 retained. The decision isn’t “IPv6 or not” in the abstract; it’s “am I set up to meet IPv6’s stricter bar, yes or no.” If yes, turn it on carefully; if not, fix the prerequisites first.

How the engine binds IPv6

On a self-hosted PowerMTA or KumoMTA, IPv6 sending is expressed through the same mechanism as IPv4: a virtual MTA bound to a specific source address. You define a vMTA that sends from your static IPv6 address — the one with the PTR and SPF entry — and another for IPv4, then route traffic to each through pools and pattern lists. The engine binds the outbound connection to that exact address, which is what makes the “pin a single static IPv6” requirement practical rather than theoretical: the vMTA is the pin.

This is also where the privacy-extensions problem gets solved cleanly. Because the vMTA binds an explicit source address, the OS never gets to pick a rotating temporary one for mail — provided you’ve also disabled privacy addressing at the host level so nothing else interferes. The result is a deterministic mapping from vMTA to address to PTR to SPF entry, which is exactly the stable identity IPv6 receivers demand.

Dual-stack routing in practice

Running both protocols is only useful if you route deliberately. The common pattern is to send to providers that reward IPv6 — Google and Google Workspace domains chief among them — over your IPv6 vMTA, while everything else and any failover goes over IPv4. You express this with per-domain routing rules: match the recipient’s mail provider, direct it down the appropriate vMTA, and define a fallback so that if the preferred path defers or fails, the other protocol picks up rather than the mail stalling.

The point of the routing is control, not spreading risk thin: each provider gets the protocol it treats best, and neither path is a dumping ground. Done well, you capture the acceptance benefit at IPv6-friendly providers while keeping the dependable IPv4 reputation as the safety net — and because both paths carry correct authentication and reverse DNS, a message delivers cleanly whichever one it takes.

Common IPv6 sending mistakes

Nearly every IPv6 delivery failure traces back to a short list. Keep them in view:

• No PTR on the IPv6 address — the single most common cause; Gmail rejects outright.
• Broken FCrDNS — a PTR with no matching AAAA pointing back, so the loop doesn’t close.
• IPv4-only SPF — no ip6: entry, so SPF fails the moment you send over IPv6.
• Privacy extensions left on — a rotating source address that no PTR or SPF entry can match.
• Treating IPv6 as warm — sending at volume on a fresh IPv6 address with no warm-up.
• Assuming IPv4 reputation carries over — it doesn’t; IPv6 is scored separately.

None is hard to avoid, but each alone is enough to turn IPv6 from an advantage into lost mail — which is why the careful setup is the whole point rather than an afterthought.

IPv6 sits on top of the 2026 baseline

It’s worth being explicit that IPv6’s requirements are in addition to, not instead of, the sender rules every mailbox provider now enforces. Since the 2024 Gmail and Yahoo changes — tightened further through 2025 and 2026 — all senders need SPF or DKIM, valid forward and reverse DNS, and TLS; bulk senders (5,000+ a day to Gmail) additionally need DMARC with alignment, one-click unsubscribe on marketing mail, and a spam-complaint rate kept under 0.1% and never reaching 0.3%. Those apply on any protocol.

What IPv6 changes is the enforcement posture. The reverse-DNS and authentication items that a lenient receiver might let slide on IPv4 are checked rigidly on IPv6, and failures convert to rejections rather than spam-foldering. So the right mental model isn’t “IPv6 has its own separate rulebook”; it’s “IPv6 enforces the existing rulebook strictly, and adds the FCrDNS and stable-address requirements on top.” Get the 2026 baseline right — authentication, DMARC, TLS, complaint discipline — and the additional IPv6 work is the reverse-DNS and addressing layer rather than a whole second project.

That ordering is also the practical sequence: get your IPv4 sending fully compliant with the baseline first, prove it’s clean, and only then extend to IPv6 with the extra reverse-DNS and stable-address pieces in place. Doing it in that order means IPv6 is a controlled extension of a working setup, not a simultaneous scramble to satisfy two things at once.

How to verify before you send

Because IPv6 failures are unforgiving, verify the setup before the first real send rather than discovering gaps from bounces. Confirm the reverse path closes in both directions — the PTR resolves to a hostname, and that hostname’s AAAA points back to the same address — then confirm SPF authorises the IPv6 range and that a test message is DKIM-signed and DMARC-aligned over the IPv6 path specifically, rather than only over IPv4. Verifying on the protocol you will actually send over is the step people skip, and the one that matters most here.

Then send a seed message from the IPv6 vMTA to a Gmail address and inspect the received headers: they’ll show whether the connection came in over IPv6, whether SPF and DKIM passed, and whether the PTR was accepted. Gmail’s Postmaster Tools will confirm the IPv6 address is recognised and authenticating cleanly as volume builds. A few minutes of verification here replaces hours of chasing intermittent rejections later — and on IPv6, where the failure mode is a hard reject, that verification is the difference between mail that delivers and mail that silently doesn’t.

Once it checks out, ramp gently as you would any new address, watch the headers and Postmaster signals through the warm-up, and keep the PTR, AAAA and SPF entries in sync if anything about the address ever changes — a renumber that updates the address but not its reverse DNS will reintroduce exactly the failure you just eliminated. The same goes for adding a second IPv6 address later: each new sending address needs its own PTR, its own AAAA, and its own SPF authorisation before it carries a single message, or it lands you right back at the hard-reject behaviour that makes IPv6 unforgiving in the first place.

The bottom line

Sending over IPv6 can earn better acceptance at the providers that prefer it, Google most of all, but it raises the bar from “recommended” to “required.” The sending address needs a stable PTR and forward-confirmed reverse DNS, SPF must authorise the IPv6 range and DKIM/DMARC must pass, and privacy extensions must be off so the address never changes underneath you. Miss any of these and strict receivers reject the mail outright rather than filtering it.

Treat IPv6 reputation as a separate asset you warm and monitor on its own, keep IPv4 healthy alongside it, and run dual-stack with per-provider routing rather than choosing one protocol. Do that and IPv6 is an advantage; rush it without the reverse DNS and authentication in place and it’s a liability. If you’d rather not hand-assemble the AAAA records, IPv6 PTRs, ip6: SPF entries and dual VMTAs, the Auto PMTA Configurator builds the dual-stack setup — including Gmail-over-IPv6 routing with IPv4 fallback — for legitimate, opt-in sending.