Authentication of emails is the first step to protect users and organizations against Business Email Compromise (BEC) attacks and improve the deliverability of emails. Over time, multiple authentication mechanisms like SPF, DKIM and DMARC were adopted by industry to tackle email verification issues and prevent tampering with emails in transit to recipients. However, some legitimate intermediate services also have the potential to make changes to the email or its route. This can cause these emails to fail authentication.
Microsoft introduced Enhanced Filtering for Connectors, which preserves the original IP across hops and allows Office 365 to perform accurate Sender Policy Framework (SPF) checks. This was followed by support for Sender Rewriting Scheme (SRS) which improved this capability even further. Meanwhile, there was a rise in the adoption of Domain Keys Identified Mail (DKIM) for the purpose of verifying emails were not tampered with en route and to aid authentication.
DKIM is more resilient in simple relay cases, but is designed to isolate when an intermediate relay hop is introduced and that hop modifies the message. Typical examples that violate DKIM includes some legitimate processes, like when an email gateway might be configured to add a footer/disclaimer or re-write URLs. When this is a known and legitimate intervention used by a business in the flow of their email, it’s important to leverage Authenticated Received Chain (ARC). ARC helps preserve authentication results across intermediaries.
ARC is a relatively new email authentication mechanism introduced in 2016. It was adopted by Microsoft in 2019 for Microsoft-sealed ARC signatures. Microsoft is introducing a new way for admins to create a list of known and trusted ARC sealers. Trusted ARC sealers have valid and trustworthy ARC signatures they provide during their hop, and this is added to the chain of email authentication.
Without ARC Seal:
With Trusted ARC Sealer:
Introducing Trusted ARC Sealer gives admins additional flexibility when using an intermediate service. Whether performing a staged migration to Microsoft Defender for Office 365, or keeping complex routing in place to provide layered defense, ARC support allows admins to preserve even more original authentication results. With better authentication results, the effectiveness of the Microsoft protection stack improves, and allows admins to enable more of our protection stack, even when the MX record does not point to Microsoft Office 365.
ARC consists of 3 parts:
Let’s walk through a scenario to understand how ARC works.
Scenario: Bob works at a banking firm—Contoso—and due to the sensitivity of the emails Bob handles, every email sent to Bob’s organization routes through an intermediary called Fabrikam in order to add sensitivity disclaimers to the email body.
From: firstname.lastname@example.org > Intermediary: disclaimer service fabrikam.com > To: email@example.com
The email originates from Microsoft servers, and at the first hop, Fabrikam (the intermediary), receives the email and does the authentication checks of SPF, DKIM and DMARC. Fabrikam adds the results of the checks to ARC header along with the ARC signature. Next, Fabrikam adds a disclaimer to the email body, and an additional ARC seal. Then Fabrikam sends the email to the recipient firstname.lastname@example.org.
When Contoso servers receive the email, along with the SPF, DKIM, DMARC checks, ARC checks are done against trusted intermediaries to authenticate the emails. In this scenario, even though the DKIM fails due to content modification, the email will pass authentication because the ARC sealer Fabrikam.com being a trusted intermediary helping ensure correct delivery.
ARC is still in its early stages of adoption with approximately 4000 ARC sealers stamping ARC headers. To provide impetus, and push industry boundaries towards a more secure mail, Microsoft has taken steps towards allowing tenants to add Trusted ARC sealers to validate and honor ARC signatures and improve the email authentication experience.
If you’re working with a third-party intermediary for routing your emails to Office 365, take these steps to add an intermediary to the trusted list:
To identify spoofing attempts, email standards like SPF, DKIM, and DMARC are evaluated on every incoming message. Office 365 honors these standards for domains that have properly configured these settings. Emails that fail DMARC checks are handled based on the spoofing policy action defined by the admin. You can learn more about email authentication in Office 365, and its implications on spoofing in the email validation and authentication documentation.
To setup DMARC for your domain, follow the steps in the use DMARC to validate email documentation. It is also recommended to enable DKIM for all email sending domains. DKIM signing for all outbound mail can easily be setup in Office 365 by following the use DKIM to validate outbound email documentation.
For customers where the MX record for the email domain hosted in Office 365 does not specify Office 365 as the delivery end point, it is recommended that you review and implement Enhanced Filtering for Connectors to ensure SPF validation is implemented correctly for inbound email. This will help ensure email authentication is accurate.
Do you have questions or feedback about Microsoft Defender for Office 365? Engage with the community and Microsoft experts in the Defender for Office 365 forum.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.