Microsoft Exchange Online adding inbound IPv6 support
Do you host your domain's email service on Microsoft Exchange Online/Microsoft 365? If so, you should note that IPv6 support is coming, and that Microsoft is enabling that support automatically.
Starting on October 16th: "After [Microsoft] enables IPv6 for your Accepted Domains, when someone tries to send an email to one of your users and queries the MX record for the domain, they will receive both IPv4 and IPv6 addresses (AAAA records) in response to their MX record query."
Might you want to turn this off, restricting inbound mail connections to IPv4 only? If so, that is indeed doable. See Microsoft Message Center notification MC835648 (helpfully archived here and elsewhere) and you can find links to more information.
Should you be accepting inbound mail on IPv6? Generally speaking, broader IPv6 support provided by a very large service provider such as Microsoft is probably a good thing. But email is a tricky beast. If this were to affect me, I might want to disable it temporarily, and let others have that first experience with bugs and unexpected issues. (That's the same reason I don't install a new "dot zero" version of iOS on my iPhone on the first day of availability.)
On the one hand, I ought to be fair and start from the assumption that enabling support for inbound email over IPv6 should be relatively harmless. But on the other hand, I know from experience that sending email traffic over IPv6 is not as simple as I wish it was. The reputation equation is not the same.
Here's an example of one possible way I expect it could go wrong on day one.
A company has a random sending outbound MTA that supports IPv6 and IPv4. The admin mostly ignores IPv6, but it's enabled, because it shipped that way.
The admin probably already special cased sending of mail to *.google.com and *.gmail.com MXes over IPv4, unless they like pain.
When IPv6 support for sending to MS 365 domains goes live, the random MTA, by way of its config, or MX precedence response, might suddenly start trying to send mail to MS 365 domains over IPv6.
MS 365 is now seeing inbound mail from this random company over IPv6 IP addresses that have no sender reputation or history. Meaning, this mail is more likely to get spam filtered or rejected.
Random sending MTA is now sending from IPv6 IPs that perhaps don't often send mail. Are they included in the sending domain's SPF record?
Do the IPv6 IPs have proper matching forward and reverse DNS?
Will it for sure go wrong? No, of course not. Could it? Yeah, maybe. It's a change and change sometimes leads to unexpected results on occasion. Best for folks to be aware, watch logs, and watch for complaints about email not being delivered.
Google's inbound spam filtering feels a bit more sensitive on IPv6 versus IPv4. Will this also be true of Microsoft? So far, I could only guess.
If you use an email service provider (ESP) or marketing automation platform to send your mail, then you probably don't have much to worry about here. Most of these platforms lack IPv6 support, as the vast majority of email infrastructure in the world lives on IPv4. But it couldn't hurt to check with your platform and make sure that they don't have some latent IPv6 support that will spring into use when Microsoft starts serving up IPv6 as an option for inbound email traffic.
Do you host your domain's email service on Microsoft Exchange Online/Microsoft 365? If so, you should note that IPv6 support is coming, and that Microsoft is enabling that support automatically.
Starting on October 16th: "After [Microsoft] enables IPv6 for your Accepted Domains, when someone tries to send an email to one of your users and queries the MX record for the domain, they will receive both IPv4 and IPv6 addresses (AAAA records) in response to their MX record query."
Might you want to turn this off, restricting inbound mail connections to IPv4 only? If so, that is indeed doable. See Microsoft Message Center notification MC835648 (helpfully archived here and elsewhere) and you can find links to more information.
Should you be accepting inbound mail on IPv6? Generally speaking, broader IPv6 support provided by a very large service provider such as Microsoft is probably a good thing. But email is a tricky beast. If this were to affect me, I might want to disable it temporarily, and let others have that first experience with bugs and unexpected issues. (That's the same reason I don't install a new "dot zero" version of iOS on my iPhone on the first day of availability.)
On the one hand, I ought to be fair and start from the assumption that enabling support for inbound email over IPv6 should be relatively harmless. But on the other hand, I know from experience that sending email traffic over IPv6 is not as simple as I wish it was. The reputation equation is not the same.
Here's an example of one possible way I expect it could go wrong on day one.
- A company has a random sending outbound MTA that supports IPv6 and IPv4. The admin mostly ignores IPv6, but it's enabled, because it shipped that way.
- The admin probably already special cased sending of mail to *.google.com and *.gmail.com MXes over IPv4, unless they like pain.
- When IPv6 support for sending to MS 365 domains goes live, the random MTA, by way of its config, or MX precedence response, might suddenly start trying to send mail to MS 365 domains over IPv6.
- MS 365 is now seeing inbound mail from this random company over IPv6 IP addresses that have no sender reputation or history. Meaning, this mail is more likely to get spam filtered or rejected.
- Random sending MTA is now sending from IPv6 IPs that perhaps don't often send mail. Are they included in the sending domain's SPF record?
- Do the IPv6 IPs have proper matching forward and reverse DNS?
Will it for sure go wrong? No, of course not. Could it? Yeah, maybe. It's a change and change sometimes leads to unexpected results on occasion. Best for folks to be aware, watch logs, and watch for complaints about email not being delivered.Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.