Office 365 will slightly modify its treatment of anonymous inbound email over IPv6

  • Article

Exchange Online Protection (EOP), aka Office 365, is going to be making a small change to its behavior for inbound anonymous (i.e., not sent over TLS) email sent over IPv6. Luckily, for customers with IPv6 enabled, no action is required.

Currently, we require the following for senders over IPv6:

  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:

    550 5.7.25 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:

    554 5.7.26 Service unavailable, message sent over IPv6 must pass either SPF or DKIM validation.

The change we are making is regarding #2. Starting April 24, 2015, if a message does not pass SPF or DKIM, the service will reject with the following temporary reject error:

450 4.7.26 Service unavailable, message sent over IPv6 must pass either SPF or DKIM validation.

In other words the 550 becomes 450, and 5.7.26 becomes 4.7.26. If a sender sends a message over IPv6 that doesn’t pass SPF or DKIM, rather than failing because of the 5xx reject, it should retry at the next available MX record which is IPv4. That is, for a customer like contoso.com who has enabled receiving email over IPv6, their MX record looks like the following:

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

Which resolves to:

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

A sending mail server that is dual stack (sends over IPv4 and IPv6) will try the AAAA-records first and will bounce the message if it doesn’t send with SPF or DKIM passing. When it receives the 4xx, it will retry (that is, it will if its RFC-compliant and is properly configured). When it next finds the A-record (IPv4), it will not be rejected since SPF or DKIM is not required for IPv4, although we encourage all senders to authenticate their email.

IPv6 still requires the same conditions above, however, the new implementation now allows for automatic failover at the sending MTA level instead of issuing a hard bounce and prompting the domain administrator to set up SPF or DKIM.

Related Articles