Office365/EOP IPv6 changes starting today

Terry Zink at Microsoft posted earlier this week that Office365/Exchange Online Protection will have a significant change this week. Office365 uses Exchange Online Protection (EOP) for spam filtering and email protection. One of the requirements to send to EOP over IPv6 is to have the email authenticated with either SPF or DKIM.  If the mail sent to Office365/EOP over IPv6 is not authenticated with SPF or DKIM, EOP would reject the message with a 554 hard bounce message.  Most mail servers accept the 554 status code and would not retry the message.  After multiple 5xx hard bounces to an email address, many mail servers would unsubscribe the user from future email campaigns.  The update starting today April 24, will change the error status code for unauthenticated mail to EOP from a 554 hard bounce to a 450 soft bounce and a RFC-compliant and properly configured mail server would then retry the message.
Prior to April 24, 2015, EOP responds to unauthenticated mail with a status code of: “554 5.7.26 Service Unavailable, message sent over IPv6 must pass either SPF or DKIM validation”.

Starting April 24, 2015, EOP will respond with “450 4.7.26 Service unavailable, message sent over IPv6 must pass either SPF or DKIM validation”.

This means the sending mail server should retry the message to another MX server and if the sending mail server is dual stacked (sending on IPv6 and IPv4) it will try sending to the IPv6 MX server first then attempt to send the retry to a IPv4 MX server.
If you are sending over IPv6, Office 365/EOP also requires that the sending mail server IP address have a PTR record and if the sending mail server does not, EOP will reply with a hard bounce message of “550 5.7.25 Service unavailable, sending IPv6 address [$SenderIPAddress] must have a reverse DNS record”. There will be no change to PTR requirement for EOP, however all sending mail servers should have a PTR record.

Related Posts

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More

Office365 checking DMARC on the inbound

According to a recent blog post, Office365 is starting to evaluate incoming messages for DMARC. I talked a little bit about DMARC in April when Yahoo started publishing a p=reject message.

Read More

Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

Read More