On Monday I talked about how big IPv6 address space is, and how many IPv6 addresses will be available to end users. We’re mostly an email blog, though, so what’s the relevance to sending email?
If the recipient you’re sending to has an IPv6 mailserver you can send mail to them over IPv6, if you choose to. If they only have an IPv6 mailserver, with no IPv4 mailserver at all then you have to send over IPv6 to reach them.
For a long time I was pretty sure that IPv6-only mailservers were unlikely to be an issue any time soon – as IPv6 rolls out end users will get IPv6 addresses, and that will free up a huge number of IPv4 addresses that can then be used where they’re more valuable, for webservers and mailservers. As I’ve watched IPv4 addresses run out and the rise of a secondary market I’m begining to think that hoarding may make IPv4 addresses effectively unavailable or prohibitively expensive for small companies and individuals in some regions. If so, then a few IPv6-only mailservers will encourage others to support sending and receiving email over IPv6, which will in turn make IPv6-only servers more viable.
And you might want to use IPv6 even if the recipient has a dual-stack IPv4+IPv6 mailserver. As one example, Gmail accepts mail on IPv6 – and scuttlebutt is that right now their IPv6 servers are somewhat more forgiving for properly authenticated email, which is interesting. And if you’re running short of IPv4 addresses yourself, routing all your gmail recipients over IPv6 instead might free up some capacity and save you from having to go IPv4 address shopping.
But there are a few things to know before starting to send over IPv6.
IPv6 to IPv4 fallback
If you turn on IPv6 support on a mailserver it is likely to prefer IPv6 when sending mail to dual-stack recipients. That’s great if everything is set up perfectly, but if your IPv6 network configuration is flakey, or your authentication is not good enough for IPv6 mail, or the recipient has an IPv6-specific configuration problem then your delivery over IPv6 might fail. How to choose an MX for delivery – and how to fall back to an IPv4 MX – isn’t terribly well defined so there’s some risk of delivery of a message failing repeatedly. You should check how your smarthosts handle this sort of delivery failure.
There’s no legacy IPv6 to support
There are twenty year old servers sending email over IPv4, so attempts to enforce better authentication both of mailservers and messages have moved very slowly so as not to disrupt mail from those old servers.
IPv6 is a whole new world, though. Any mailserver set up to send via IPv6 has been set up relatively recently and it’s much more reasonable to expect it’s operators to follow best practices (PDF). If you want to send mail to Google over IPv6 you have to have “good” reverse DNS, and you have to authenticate the mail you send with at least one of SPF or DKIM. Google are much less tolerant of violations of those requirements for mail sent over IPv6, more likely to mark messages as spam or reject them altogether compared to delivery attempts over IPv4.
What does “good” reverse DNS mean? The IP address you’re sending from must have reverse DNS that resolves to a hostname, and that hostname must resolve back to the sending IP address. (You’ll sometimes see that described as “FCrDNS”.)
One customer, one /64
As I mentioned on Monday a consumer end user should be allocated no less than a /64 of IPv6 space. If you’re in the IPv4 mindset of addresses being scarce and valuable you might decide that you don’t need to do that with your customers, maybe assigning each of them a/124 to send their mail through. 16 IP addresses is plenty, right?
A large hosting company did that recently, assigning each of their customers a small range of IPv6 addresses out of a single /64 – and they discovered why it’s a terrible idea. They had no more than the usual level of email delivery problems on IPv4, but all of their IPv6 mail was blocked at a lot of destinations. Because a /64 is the smallest recommended range to assign to a user it’s also the smallest quantum that reputation services and blacklists will block by. Bad behaviour by one of their customers got the /64 that customer was sending from blocked – along with all the other customers sending from other parts of that /64.
So don’t do that.
- If you have a customer sending over a single dedicated IPv4 address, give them a single /64 of IPv6 space.
- If you have a customer with 8 or 16 dedicated IPv4 addresses (for reasons of load rather than traffic segregation), give them a single /64 of IPv6 space.
- If you need to segregate different sources of traffic give each of them a /64.
It’s not clear yet what might be a best practice for providing IPv6 service to small customers who are currently sending from a shared pool. Maybe the pool gets a /64 (perhaps with different customers using different addresses within that /64). Perhaps each customer gets their own /64. If anyone has any experience or ideas, share them in the comments.
(If you’re interested in receiving mail over IPv6, Franck Martin has a good article covering some of the issues at LinkedIn Engineering).
RSS - Posts
Steve,
Glad you’re writing about it.
You probably know more than anyone on the subject.
If Gmail is really a little more forgiving for properly authenticated email, would it make sense for ESPs to switch to IPv6 for just sending to Gmail?
I think there are good reasons for an ESP to be planning for support of IPv6 delivery – but it’s going to be a significant amount of work and time to deploy on most platforms.
If you were solely concerned about delivery rates at a single ISP there are almost certainly other changes you could make that would have a better ROI in a shorter time frame – but in the near term access to potentially less congested mail servers is one of the reasons to look at IPv6 support.
Great article, I’m exceedingly happy to see IPv6 is going to push FCrDNS, SPF, DKIM, DMARC!
@Brian
I work for a small ESP, and turning on IPv6 was a breeze if you already enforce the above on your IPv4 system.
Google brought me here – I’m just trying to send mail by ipv6 to yahoo, and it fails – apparently none of their MX servers have AAAA records. Is this known and permanent, or am I doing something wrong?
@Radu: IPv6 support for receiving email isn’t universal, or even particularly common. Yahoo don’t currently support it.
You can’t usefully run an IPv6-only smarthost at the moment – it needs an IPv4 address to send to mailbox providers who don’t support IPv6.
Thank you. I was just looking for alternative ways of delivering to yahoo. We’re an ESP in a yahoo-dominated country and the delivery problems last month were a bit unsettling.