Generally speaking there is nothing
Found at: gopher.blog.benjojo.co.uk:70/email-delivery-stuck-on-ipv4
Email delivery is stuck on IPv4
Generally speaking there is nothing that people want to
talk about less than email delivery and for good reason, Email
is continuously seen as one of those archaic protocols that
everyone wants to improve but unfortunately has reached the point of
critical mass where it is "unchangeable"
It was only recently when Google started putting nasty
icons on emails when they were delivered to Gmail accounts
unencrypted do people actually adopt TLS in a serious fashion.
One of those things that I've always wondered was that now
that we have IPv6 in the world would it be possible to run an
email server only on IPv6. Given that most service providers have
IPv6 now surely they would be able to deliver email on v6?
To test this theory I figured it would be easy to write
a script that would go through my inbox to see what
percentage of the emails inside were delivered over IPv6. I originally
set to writing a google appscript to do this function,
unfortunately I realised that the limits on that system are pretty
google app script limits
Fortunately the incredibly named "Google data Liberation
Front" provides a tool called Google takeout that is capable of
exporting your inbox into a single mbox file, With that I exported
my traditional Gmail account and then my gsuite account emails
waiting for google takeout
For the others wanted to do this it's worth knowing that
the Google takeout tool does in fact take some serious time.
My experience with the tool showed that it's exporting emails
at less than one email per second. Something that is fine for
small inboxes but if you have a large inbox then you may be
spending a long time waiting for your zip file.
Then using the fantastic standard library of Google Go
(mainly speaking, net/mail), I made a small program that read the
mbox and put out some basic CSV files with some basic
As you can see IPv6 has always been very low and
depending on your inbox diversity it has been getting lower, I
Included the extra non google series in the graph above because on
another Gmail account there was lots of emails from Google itself
and it was inflating the IPv6 numbers quite significantly.
But there is hope! Surely if we managed to force email
providers/senders to adopt TLS then we can get email providers to support
Unfortunately not quite. TLS has been in use for much
longer than IPv6 has, and in the case of at least my inbox
emails that I am getting have been delivered by infrastructure as
a service providers (IaaS) are going up, and these providers
do not support IPv6 and don't seem like they are making any
efforts to support IPv6 delivery.
If just 4 IaaS email delivery providers were to support
IPv6 then in the case of my inbox the IPv6 delivery count
would go up by 28%
But this isn't the whole story. This is only looking at
the inbox emails that are coming in, what if I was to run a
email server that was only IPv6 and try to use it in the real
As I went down all the list of services it became
immediately clear that almost none of them apart from Google services
are actually able to send a confirmation email to a domain
that only has an IPv6 mail server:
google sheet screenshot
I don't hold high hopes at any of this will be fixed in
the near future, given the most of these sites themselves do
not have IPv6 on their HTTP/HTTPS traffic then they have higher
priorities than email delivery.
This is why I think that the responsibility shifts to
these IaaS providers to support IPv6 Mail delivery. If 3 of
these providers (Sendgrid, Mandrill, Amazon SES) were to support
v6 they would lead the way for more systems to accept v6
mail delivery, giving that it would actually be in use.
Until then, I guess it’s just another waiting game.
As always, if you want to see the raw numbers, you can
find them here: Link
Or if you want to run the code yourself, you can find
the program used here: github