Sending Email Over IPv6 to Gmail and Outlook: PTR, SPF/DKIM and the Errors You'll See

To send over IPv6, the sending address needs a PTR record that resolves to a hostname, that hostname needs an AAAA record pointing back, and your domain needs SPF or DKIM passing. Spamhaus also wants the address inside a /64 or larger allocation. If any of that is missing, Gmail and Microsoft refuse the message, and the quick fix is to send over IPv4 until it's in place.

This mostly affects people running their own servers: Postfix, Exim or PowerMTA on a VPS or dedicated hardware, where the host offers IPv6 by default. Many servers prefer IPv6 when the receiving MX has an AAAA record, so mail can start going out over an address you never set up. If you send through Google Workspace, Microsoft 365 or an ESP, they handle this.

What each receiver asks for

Receiver	IPv6 requirement	Source
Gmail	PTR on the sending IP, forward record (AAAA) resolving to the same IP, SPF and DKIM as for all senders	Google sender guidelines
Microsoft 365	Tenant must accept IPv6; PTR on the sending address; SPF or DKIM must pass	Microsoft Learn: mail flow
Spamhaus	/64 or larger allocation with valid reverse DNS	Spamhaus sender guidelines

Spamhaus's wording (read 3 November 2026): "If sending over IPv6, the sending address must fall within an allocation of /64 or larger and that space must have valid reverse DNS", because "IPv6 ranges without reverse DNS or with allocations smaller than /64 are often misused by spammers." It suggests dig -x on an address in the allocation to confirm the reverse DNS is there.

The errors and what they mean

Error	From	Meaning	Fix
550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication	Gmail	No IPv6 PTR, or authentication failing	Set the PTR; check SPF/DKIM
450 4.7.25 Service unavailable, sending IPv6 address [...] must have reverse DNS record	Microsoft 365	No PTR on the IPv6 address	Set the PTR or send over IPv4
450 4.7.26 Service unavailable, message sent over IPv6 [...] must pass either SPF or DKIM validation	Microsoft 365	Neither SPF nor DKIM passed	Add the IPv6 address to SPF, or sign with DKIM
550 5.2.1 Service unavailable, [domain] does not accept email over IPv6	Microsoft 365	That organisation hasn't opted in	Send to it over IPv4

The Microsoft 450 errors are temporary, so your server will retry until the message expires. That can look like slow delivery rather than an error until you read the logs. Our post on Gmail 550 5.7.1 variants covers the other 5.7.1 messages Gmail sends.

Fix it in four checks

1. Find the IPv6 address you send from. Send a test to an outside inbox and read the Received header; an IPv6 sender appears in square brackets like [2001:db8::25]. Or check your MTA's logs for the outbound connection.
2. PTR. Look up the address in the reverse DNS lookup. It should return a hostname on your domain, such as mail.example.com. If it's empty or a generic provider name, ask your host to set it; you can't set it in your own DNS zone.
3. AAAA. The PTR hostname needs an AAAA record pointing back to the same IPv6 address. Check it with the DNS lookup.
4. SPF. If your SPF record lists only IPv4 addresses, add the IPv6 one (ip6:2001:db8::25) or the prefix. The SPF checker shows what the record allows. DKIM signing covers you for Microsoft's "SPF or DKIM" rule either way.

The HELO name matters too: it should resolve to the sending address over the protocol you use. Our HELO fix guide covers that, and PTR records for email covers the reverse DNS side in more depth.

Or send over IPv4

If your host can't set an IPv6 PTR, or you'd rather not build reputation on a second address, send over IPv4 only:

• Postfix: inet_protocols = ipv4 in main.cf stops IPv6 entirely, or smtp_address_preference = ipv4 makes the SMTP client prefer IPv4 when both are available (Postfix docs).
• PowerMTA and Exim: bind outbound delivery to your IPv4 source address in the virtual MTA or transport settings. Check your version's documentation for the exact directive.

Then confirm from a fresh Received header that the connection went out over IPv4.

Reputation still applies

An IPv6 address with a perfect PTR and passing SPF is still a new sender if it has no history. Spread volume over days the way you would for a new IPv4, and check the address against blocklists with the IP blacklist check. Bounces from stale addresses hurt a new address faster than an established one, so verify the list before the first campaign.

Where SimpleVerifier fits

The DNS tools linked above are free. SimpleVerifier's paid part is list verification, which keeps bounces down while a new sending address builds history; it doesn't configure your server or set PTR records. The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.