Spoofing is a common challenge that enterprises face in today’s world, which can lead to increased spam and more intensified phishing campaigns. In order to reduce spoofing and provide a safer client experience, Office 365 now supports inbound validation of DomainKeys Identified Mail (DKIM) over IPv4, and Domain-based Messaging and Reporting Compliance (DMARC). Both of these technologies check for trusted authenticated senders and help identify untrusted ones that that fail authentication. Exchange Online Protection (EOP), which filters every single mailbox on Office 365, had previously supported Inbound DKIM for IPV6. With these added functionalities feature, Office 365 users can expect better brand protection and an even safer experience.
Let’s take a closer look at these new service features.
Domain-based Messaging and Reporting Compliance (DMARC)
DMARC is a technology designed to combat email spoofing and is useful to stop phishing. Specifically, it protects the case where a phisher has spoofed the 5322.From email address, which is the email address displayed in mail clients like Outlook and outlook.com. Whereas the Sender Policy Framework, (SPF) catches the case where the phisher spoofs the 5321.MailFrom, which is where bounce messages are directed, DMARC catches the case that is more deceptive.
DMARC protects users by evaluating both SPF and DKIM and then determines if either domains matches the domain in the 5322.From address. In the example above, the phisher has passed SPF for phishing.com, but because phishing.com does not equal woodgrovebank.com, it fails DMARC.
The results of a DMARC check are stamped in the Authentication-Results header:
Authentication–results: protection.outlook.com; spf=pass
(sender IP is xx.xx.xx.xx) email@example.com
dkim=none (message not signed) header.d=none; dmarc=fail
Office 365 then uses DMARC to mark the message as spam and provide better protection for its users. For more details, please see the blog post, Using DMARC in Office 365.
DomainKeys Identified Mail (DKIM)
DKIM permits the person, role or organization, who owns the signing domain, to claim some responsibility for a message by associating the domain with the message. Senders insert a digital signature into the message in the DKIM-Signature header, which receivers then verify. DKIM allows senders to build domain reputation, which is important to ensure email delivery and provides senders a non-spoofable way to identify themselves. It is a critical component of email protection. Office 365 previously supported DKIM when a message was sent over IPv6 and now supports it when it is sent over IPv4.
The results of a DKIM verification are written to the Authentication-Results header. For example, if the signing domain in the d= field in the DKIM-Signature header is d=example.com:
Authentication–Results: spf=pass (sender IP is 18.104.22.168)
firstname.lastname@example.org; contoso.com; dkim=pass (signature was verified) header.d=example.com;
If a message fails DKIM verification, the header will say dkim=fail with the reason for the failure in parentheses, for example invalid body hash, key query timeout, no key for signature, and so forth.
Office 365 verifies DKIM signatures when receiving the message. However, after the message has been scanned, (lands in a user inbox, or is relayed to an on-premises mail server, is bcc’ed via a policy rule and so forth), the existing DKIM-Signature may no longer verify if a downstream mail server tries to re-verify it. This is because Office 365 modifies some parts of the message. We will be changing this behaviors in a subsequent release of Exchange Online Protection.
These two features are currently being rolled about and will be fully deployed by the end of the first quarter of 2015.These features help improve the Office 365 experience by helping reduce both phishing and spam in the service and we look forward to more secure experiences as we continue to add new capabilities to Exchange Online Protection (EOP).