IPv6 and Email

If you received this message and you are NOT running an email server yourself, the explanations below are probably not for you.

If you are an end user just trying to send email, you probably do not have your email client configured correctly. Please check your settings, or contact your ISP or email provider

If you ARE operating an email server, and you see this error message trying to deliver MTA->MTA traffic, it is probably because the admin of the server you have chosen to send to has explicitly chosen not to accept IPv6 traffic, or is not yet ready to do so.

And there are many reasons for system administrators to decide to do this, as there are many interconnected systems that all have to be tested and ready, including spam protection systems, filters, firewalls, network layers, DNS cache, database tables, and even operating system caches.

And some operators have reported that now with trillions of fresh addresses, spammers have attempted to jump into this new space, to get around traditional filters.

While we commend those legitimate operators who have bravely leaped into the IPv6 world, and try to send first using IPv6, it is important to remember that you need to be able to fall back to using IPv4 if you can’t deliver via IPv6.

We expect that MTU->MTA traffic will be the first to see wide spread adoption, while MTA->MTA will be the primary choice for some time to come, and some system administrators are also of that belief, and prefer to wait until they are sure they are ready to handle the new challenges that IPv6 server to server communications brings.

There is an interesting article regarding the challenges:

https://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6

Now, if you reached the server and received this message, there are some things you should check:

• Is the MX Record for this domain have the IPv6 address at all?
• Is the MX Record for this domain listing IPv6 as the lowest priority?

If they are, you might like to notify the recipient’s mail admin, they probably didn’t notice.

But if there is NO IPv6 address for the name in the MX record, please do not send via IPv6. Period. Easy to say, but in the real world..

Many MTA’s don’t make that easy, and often the network layers themselves take up that role, eg finding how to route the traffic, and not all admin’s can understand all this.

As pointed out in the article linked above, IPv6 RFC6724 indicates that if a machine is dual-stacked (where both IPV4 and IPV6 protocols run on the same network infrastructure), a connection to IPv6 should be attempted first.

And if technically the internet is now ‘dual-stacked’, does this apply? (PS, RFC’s are not LAW, but they should be followed when possible)

So, how do we make this easier?

If you get this message, and you are dual stacked, tell your system to ONLY use IPv4 for the recipient domain, if possible.

https://tools.ietf.org/html/draft-martin-smtp-ipv6-to-ipv4-fallback-01

This gives another clue.

If the ‘highest priority’ has ONLY an IPv4 address, this SHOULD be enough for your MTA to understand. If they try the lower priority first, as it has both IPv6 and IPv4, if the server rejects on connection with a 451 error, your server will retry the next higher priority MX record. If it only has an IPv4 address, your MTA SHOULD use IPv4 on the retry.

This allows receiving system admins to slowly roll out IPv6 in stages, eg to trusted partners first, and then to the rest of the world.

Just because you received this error, it doesn’t mean you are bad, just that the admin is not ready and prepared yet for the implications of IPv6 traffic from unknown locations, which might include yours.

And as a work around, (if the admin is advertising IPv6 in the MX records, but still rejecting your traffic) you can always configure a local record in your HOSTS file to only indicate an IPv4 address for a given MX record host name.