次の方法で共有

Support for anonymous inbound email over IPv6 in Office 365

  • [アーティクル]

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

Comments

  • Anonymous
    December 09, 2014
    Could you please explain how to open up a support ticket to get opted into the service? I've called Office 365 business support (support.office.com/.../Contact-Office-365-for-business-support-32a17ca7-6fa0-4870-8a8d-e25ba4ccfd4b) and no one knows how to enable this.

  • Anonymous
    January 19, 2015
    Your IPv6 email flow diagram shows DKIM being checked before SPF. Is this true, or a typo? The SPF check is computationally less expensive vs. the DKIM check, and would allow messages to be rejected sooner. Additionally, more senders have SPF enabled vs. DKIM.

  • Anonymous
    January 22, 2015
    The comment has been removed

  • Anonymous
    July 21, 2015
    The comment has been removed

  • Anonymous
    July 21, 2015
    @Baknu: Only a PTR record is required, and not FCrDNS.

  • Anonymous
    July 22, 2015
    Thanks. Could you also please explain why you consider inbound IPv6-mail sent over TLS more trustworthy than IPv6-mail without TLS (i.e. 'anonymous mail')? Why don't you require the SPF/DKIM/PTR-checks for IPv6-mail sent over TLS? Thanks in advance.

  • Anonymous
    July 23, 2015
    @Baknu: We do require the PTR/SPF/DKIM checks even if the message is sent over TLS.

  • Anonymous
    June 15, 2016
    Terry,Once again, I have tried opening up a ticket at MSFT to enable anonymous inbound email over IPv6 in Office 365 Exchange Online for a new domain. It's been five days, and no one knows how to do this. Can you please help?Thanks,Chris

  • Anonymous
    December 17, 2016
    IPv6 Interessante