While it is widely known that Microsoft has been working on the logic around email authentication, a recent roadmap update first reported on by Bleeping Computer explained that these changes are now imminent. It is anticipated that these new features in Office 365 will be able to apply the logic of a DMARC policy to all incoming email messages, irrespective of whether the sender has defined a DMARC policy or not. The net effect is that corporate clients using Office 365 mailboxes will be able to filter messages out of the inbox that do not have aligned authentication. This is part of an overall effort to improve Office 365’s default security, but it is another significant step towards the “No auth, no entry” standard that the email services industry is moving towards. Below, I’ll explain why this is true, what some of the major implications are, and what SocketLabs recommends.
Quick Refresher on DMARC
Here’s a quick refresher course on DMARC, but you can get a full explanation of DMARC and how to implement it by reading this SocketLabs white paper.
DMARC is normally a policy that a domain owner can set up, to coordinate the use of the email authentication protocols DKIM and SPF. As a domain owner you can publish a DMARC policy to accomplish two goals. First, you can define how you want your email to be handled if for some reason a message does not have aligned authentication. The options are reject, quarantine (put in spam), or none (which means take no action). Secondly, you can receive reports about what messages are being received at mailboxes with your domain in the From field. Reports are even available with a “none” policy (referred to by its technical setting of p=none) which is also known as the “reporting only policy”. While it doesn’t restrict the delivery of messages that fail aligned authentication checks, it does allow the domain owner to learn about the use of their domain in email messages.
The whole point of DMARC is that authentication has to be aligned. For example, when a customer first signs up to use SocketLabs for email delivery all messages will have passing SPF and DKIM, but by default it will not be “aligned”. Achieving authentication alignment is only possible when the customer defines a custom bounce domain (SPF), or custom DKIM. It is the customer’s task to complete this white-labeling by modifying their DNS settings. With aligned SPF or DKIM, receiving mailboxes can verify that the mail is really being sent by our customer’s domain.
As an email administrator, there is great value in being able to see reports, no matter the size of your organization. Setting DMARC to “p=none” has no impact on deliverability and lets you get reports from mailbox providers that tell you a) how many different messages they received that used your domain in the From address, and b) what the authentication results were for those messages. That’s really valuable information, as I explain in a video I shot about the 3 benefits of DMARC authentication, where reports ranked number 1. Here at SocketLabs we are happy customers of Dmarcian – an easy to use tool that will help you aggregate and make sense of DMARC reports.
DMARC reports allow companies to see what’s happening with their email “out in the wild.” Just consider how many third-party SaaS platforms that companies are using these days. The marketing teams are using a CRM as well as various other marcom tools, and the IT teams are using possibly dozens of different applications too. Many of these apps are sending email on behalf of the corporate domain. Finally, to be able to know if and when spoofing attacks occur where spammers are using your domain is such valuable data, and DMARC is the only way these reports can be collected.
Microsoft’s New Security Features
Essentially, Microsoft’s new security approach is noteworthy because all incoming mail may now be held to a higher standard regarding authentication. Microsoft is now performing what equates to a DMARC analysis, regardless of whether the sender has a published policy or not. In essence, they’re pretending that every email sending domain in the world has a DMARC policy of p=none. There is some irony to this change, as historically Microsoft has ignored the reject policy of many senders, opting rather to quarantine messages than actually reject them.
You can see this in action by reviewing the headers of email messages processed by Microsoft. Microsoft uses the Authentication-Results header entry to log result data. You will see data such as “dmarc=bestguesspass”, implying Microsoft is guessing at the results of a DMARC policy. You’ll also see “compauth=pass/fail reason=XXX”, which Microsoft describes as “Used to combine multiple types of authentication such as SPF, DKIM, DMARC, or any other part of the message to determine whether or not the message is authenticated. Uses the From: domain as the basis of evaluation.”.
This is groundbreaking in a way as it allows Microsoft to more easily change what it does at scale regarding mail that doesn’t authenticate, even if the domain owner isn’t being restrictive with their DMARC policy. Right now we believe that Microsoft is currently playing with some knobs and levers regarding these settings and just watching what happens. Some SocketLabs on-premise customers have reported all their non-aligned mail going to the spam folder at Office365. This would imply Microsoft is acting as if every domain in the world has a DMARC policy of p=quarantine. To date, the SocketLabs cloud platform has not seen this same pattern of filtering.
This all leads to an interesting question. Is aligned authentication going to be a requirement in the future for all senders to reach Office365 mailboxes? Microsoft is evaluating the impact of these changes to end users of their mailboxes. They are trying to understand the additional security benefits. Is the additional security beneficial enough to justify junking some legitimate mail? Will this push more domains to deploy aligned authentication, or DMARC?
How to Evolve Into a Strict DMARC Policy
So even for companies that don’t want to block messages that fail authentication, setting up a DMARC policy with p=none is wise. But reporting is not the only purpose of p=none policy. The primary reason it exists is to serve as a stepping stone to a p=reject policy. The “none” policy is for IT administrators to use for a short period of time to inventory all outbound email streams and identify instances where email authentication is not set up. Armed with this information, the administrator can take corrective action as needed. Once all adjustments have been made, and they’re confident that all traffic is being authenticated with DMARC, they can confidently switch their policy from p=none to p=quarantine, or p=reject.
For example, the administrator at a larger organization may look at reports from the last 60 days. They will identify all the vendors that are used to send mail from their domain (i.e. SocketLabs, Hubspot, Salesforce, Zendesk) and make sure authentication is working. Now they’re in a better position from a security perspective.
Contrast this with what would happen if you just set the DMARC policy to reject from the beginning. It would probably cause email to fail at a number of different vendors without knowing exactly who was being impacted. All those individual little nodes of sending that happen across the organization wouldn’t know that the domain policy had been changed. It could obviously be very disruptive. That’s why we advise clients to set the policy to “none” until they know what’s happening across their email ecosystem. It’s conceptually like warming up an IP address, except in this case it’s a warm-up process for authentication.
Conclusion: Pay Close Attention
Microsoft is not yet saying they will reject email that falls short of the DMARC standard. At this point, there’s just showing some early signs that they may be heading in this direction. What we know for sure is that Microsoft is checking every message that comes in and is looking at the SPF and DKIM settings, asking the question “would this have passed DMARC?”.
The concern for email senders is obvious. If Microsoft and other inbox providers ultimately decide to move to a strict policy, customers who have chosen not to set up authentication features will have severe difficulty reaching the inbox. That’s why we at SocketLabs have committed to pushing even harder to get our clients to do aligned email authentication.
The moral of this story is that requirements for authentication are only becoming tighter and this trend is here to stay.
