Email Authentication In 2020
Through the first quarter of 2020 there have been several developments in the email world that impact email authentication – and consequently email deliverability. These changes are placing increasing attention and pressure on how companies’ plan their email authentication strategies. While the increasing number of companies applying DMARC policies has been a hot topic in authentication over the past few years, it leads to the question of whether increased adoption of the ARC framework will accelerate the adoption of DMARC even further.
One of the most important developments this quarter was updates and improvements in Microsoft’s Office 365 platform. Announced in October 2019, and launched over the last few months, Microsoft began adding ARC headers to outgoing messages. They also added in-depth analysis of the authentication results to message headers and surfaced additional control to account administrators regarding options on how to handle mail that doesn’t pass authentication (see a discussion of this in our related blog on how Microsoft is changing email authentication). Collectively, these changes are evidence of the steady industry march towards a universal standard where messages that are not authenticated will not receive inbox placement. This future state is commonly referred to as “no auth, no entry.”
Why ARC Adoption Raises the Bar for Authentication
ARC (which stands for Authenticated Received Chain) is a relatively new authentication signature protocol which was officially published by the Internet Engineering Task Force (IETF) as RFC 8617 on July 9th, 2019. The purpose of ARC is to overcome one of the challenges that has restricted the growth of DMARC since its introduction in 2012 – specifically, that email authentication can “break” when a message travels to and between intermediaries (“hops”) on its way to the intended recipients’ mailboxes. Because intermediaries may make changes to the message and its transit path, any email authentication measures that were applied to the message when it first left the sender might now fail. Because of this issue, many email senders, especially large volume email domains like Gmail, have historically been reluctant to adopt the most strict type of DMARC policy, where the sender instructs mailbox providers to reject any messages that fail validation. This may also be leading to some organizations choosing to adopt a DMARC policy with a less restrictive policy that either quarantines failed messages (allowing them to be delivered as spam) or allows them to be inboxed regardless of the failed authentication.
How ARC Fills a Gap in DMARC
ARC is a protocol that has the potential to make having a DMARC p=reject policy less painful, as fewer messages should fail delivery after passing through forwarders and discussion lists. For example, let’s imagine that a small business owner buys a domain, and sets-up an email address for their new domain at Office365. This small business owner also uses PayPal for payment processing. Naturally, the person is going to receive email notifications everyday with a summary of their transactions. Since Paypal.com is protected with a strict DMARC policy, all of the authentication must work, or else Office365 could reject the message based on PayPal’s own DMARC policy. For our example, we’ll assume everything is in order; Office365 receives the email and places it in the inbox.
However, now let’s imagine that that same person doesn’t want to have different work and personal email accounts, so they forward all incoming messages for their business address over to their Gmail account. Even though the message passed DMARC when Office365 (Microsoft) received it, the process of forwarding the message to Gmail might cause DMARC authentication to fail. This can happen because Microsoft is now transmitting the message to Google; it’s not technically coming from PayPal anymore. In effect, the Office365 account is acting as an intermediary. From the Google perspective, the message says it is from PayPal, but now that they’re receiving it from Office365, SPF will not pass. Further, there are commonly changes to the body of the message and content due to the forwarding, which is what could cause DKIM to break as well.
So, the obvious question is how can Gmail trust this message enough to accept it and put it in the inbox? This is where ARC comes in to save the day.
Microsoft is now inserting ARC headers to outgoing messages. The ARC headers serve as a guarantee from Microsoft to Google that when the message was originally received by Microsoft that it had aligned DKIM, it had aligned SPF, and it passed DMARC. Microsoft is essentially telling Google that the message “was originally authenticated properly”. After verifying the ARC headers from Microsoft, Google reacts by asking the question “do we trust Microsoft?” If the answer is “yes,” then the ARC headers will be accepted as authentication and the message can be inboxed.
The ARC protocol will really help email intermediaries that receive lots of email. For example, anti-spam services who receive messages as an intermediary to evaluate incoming messages for a mailbox. They can now use an ARC signature to forward messages to the ultimate recipient’s mailbox provider and keep some level of trust in the chain of authentication.
The implementation of ARC by Microsoft is a big step forward for the email ecosystem because Microsoft has such a large market share of mailboxes. There is still a very large long tail of intermediary email servers on the internet that do not support ARC, but with support growing at the largest platforms, the question becomes when will the pain of going to DMARC p=reject for domains like Gmail.com be reduced to a point where it could be tolerated?
