Support for anonymous inbound email over IPv6 in Office 365

  • Article

Office 365 now supports anonymous inbound email over IPv6. In this case, “anonymous” means:

  1. The sending IPv6 address originates outside the service and is not in any customer’s settings (that is, not in any customer-specified connector)
  2. The sending IPv6 address has not been previously allow-listed by the service
  3. The sending connection is not sent over TLS (it can be sent over TLS but it is not required)

While Office 365 already permitted customers to create connectors upon which to relay inbound email (that is, email from the Internet to an on-premise mail server), now it also allows those messages to come from the outside into the service, from anyone. image

In the above diagram, the part in red is new.

 

1. Customers must opt-in to receive email over IPv6

Office 365 does not allow any inbound connection over IPv6 to connect to the service by default.

First, customers must request to be opted into the service by opening up a support ticket. The engineering team will then manually configure the service to permit, on a per-domain basis, receiving email over IPv6. This means that if a customer has multiple domains, they can pick-and-choose which ones to enable. Turnaround time for enabling IPv6 is between 24-48 hours.

Once a domain is enabled for IPv6, its MX-record will resolve AAAA records. For example, for contoso.com:

contoso.com.          3599    IN      MX      5 contoso-com.mail.protection.outlook.com

contoso-com.mail.protection.outlook.com. 10 IN A 207.46.163.247
contoso-com.mail.protection.outlook.com. 10 IN A 207.46.163.215
contoso-com.mail.protection.outlook.com. 10 IN A 207.46.163.138
contoso-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f400:7c10::10
contoso-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f400:7c0c::11
contoso-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f400:7c09::11

Domains that are not enabled for IPv6 do not resolve AAAA requests for their MX records.

Office 365 publishes IPv4 and IPv6 MX-records at the same MX-priority, and therefore it is up to the sender to decide whether to send email over IPv4 or IPv6. Sending mail servers are supposed to prefer IPv6 over IPv4 but some may choose to send all email over IPv4.

If a sender tries to manually connect to the service over IPv6 to a customer, for example contoso.com, but contoso.com has not opted in to receive over IPv6 then the service will reject the message with the permanent reject error:

550 5.2.1 contoso.com does not accept email over IPv6

Office 365 already sends outbound email over IPv6 if the receiver publishes AAAA records in its MX-record.

In addition, Office 365 already supports customers with an on-premise email server that are IPv6 end-points (that is, inbound email from the Internet over IPv4, and customer on-premise mail server is IPv6). This part has not changed.

Also, some receivers who want anonymous IPv6 but receive email from a lot of unauthenticated senders will want to read the following blog post, otherwise they will probably enable IPv6 and then roll it back a couple of days later:

2. Requirements for senders over IPv6

Second, Office 365 conforms with the Messaging, Mobile and Malware Working Group’s (M3AAWG) recommendations for receivers over IPv6: https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf.

Senders over IPv6 must pass two conditions:

  1. The sending IPv6 address must have a PTR record. If it does not, the service will reject the message with the permanent reject error:450 5.7.1 Service unavailable, sending IPv6 address [$SenderIPAddress] must have reverse DNS record.
  2. The sending email must pass SPF or DKIM verification. If it does not, the service will reject the message with the permanent reject error:450 5.7.1 Service unavailable, message sent over IPv6 must pass either SPF or DKIM validation.

Representatives from Microsoft worked with other participants in the M3AAWG working group to define and agree to these requirements.

Office 365 stamps the results of the SPF check into the Authentication-Results header, for example:

Authentication-Results: spf=pass (sender IP is 2207:eab0:3001:a01::123) smtp.mailfrom=user@example.com; contoso.com; dkim=pass (signature was verified) header.d=example.com;

Some customers may find these conditions overly stringent and therefore may choose to not enable IPv6 for their domains until they are confident that either the majority of their traffic over IPv6 passes SPF or DKIM, and has a PTR record; or, the senders who do not pass those requirements transmit exclusively over IPv4.

There is no way to override either of these requirements.

Sending mail servers may decide to retry over IPv4, at which point their email would not be subjected to these requirements, but it is up to the sender. image

 

3. Service wide throttling limits for IPv6

Third, Office 365 has implemented some service-wide throttling mechanisms. Because IPv6 makes minimal use of IP reputation lists, a large spam attack over IPv6 could cause service degradation because performing SPF and DKIM verification consumes more computational resources than a simple IP blocklist check. To protect against spam attacks, or simply misconfiguration of a sending IPv6 host, Office 365 implements throttling of IPv6 ranges.

  1. If a particular IPv6 sender has exceeded its sending limits, its connections will be rejected with the permanent reject error:550 5.3.2 Access Denied, [$SenderIPAddress] has exceeded permitted limits within $range range.

     

  2. If the service-wide network capacity allocated to IPv6 has been exceeded, any connection over IPv6 will be rejected with the temporary reject error:

    421 4.3.2 Local IPv6 capacity exceeded, please try again later.

As the network capacity returns to normal, IPv6 connections will be permitted. image

4. Customer Settings

Currently, customers can create IP Allow and Block lists for IPv4 but the Exchange Admin Center currently prevents adding IPv6 address. This will still be the case even if you opt in to receive email over IPv6.

Instead, the preferred mechanism to allow messages over IPv6 is to create Exchange Transport Rules (ETRs) that allow a domain and simultaneously require an SPF pass or DKIM pass by looking for the corresponding result in the Authentication-Results header; or to alternately block a domain (there is no need to look for Authentication-Results).

Preventing IPv6 Allow Lists and Block Lists, and requiring ETRs, has the following advantages:

  1. Because the sender domain has been authenticated with SPF or DKIM, there is a much lower risk of a spammer spoofing a faked message from a domain that has been allowed, and thereby having spam delivered to the inbox.
  2. It is easier to manage domains that are good or bad than it is to manage IPv6 addresses because the IPv6 address blocks can be so large, but domains are much fewer in number.

5. Conclusion

Permitting anonymous inbound email over IPv6 is a major step forward in Office 365. It is still very new even in the rest of the email industry, but the requirements that have been set in place should allow for the transition of email into a more trustworthy and reliable world.

 

Related Articles