It’s been quite a while since I sat down to contribute to the community. A little over a year ago, I started a job as an O365/Exchange PFE for Microsoft. Since then it’s been a whirlwind of trying to keep the surface in sight. One thing I’ve found while helping customers is that there is still plenty of room for the improvement of email protection. The goal of this blog series will be to cover the options within Office 365 for protecting email.
The best protection for your email will involve several methods and not rely on just one. To begin our look into email protection I want to start with a technology that is available for everyone regardless of email service, sender authentication. This will include sender policy framework (SPF), Domain Key Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC). The main function of these technologies, and sender authentication as a whole, is spoof protection for your domain.
Sender Policy Framework
Sender Policy Framework (SPF) is the method most commonly used. At a very high level, it is a DNS TXT record that is specifically formatted for your domain and should list all the hosts that are authorized to send using your mail domain. Let’s look at the SPF record from my domain:
v=spf1 include:spf.protection.outlook.com -all
This record indicates that messages that come from any host listed in spf.protection.outlook.com are allowed to send an email using my ehloexchange.net domain. This record is a typical record if you are using Exchange Online Protection (EOP). Depending on your environment, you may have a simple record like mine, or you may have a detailed record needing to include additional hosts/IPs that should be allowed to send for your domain. In either case, I walk thorough the process of building an SPF record in a previous post.
SPF does have some down sides that you should be aware of. The first is that, by itself, it doesn’t protect from spoofed messages. There is no method to ensure that the Mail From: and Sender addresses/domains match (or align). Because of this, it’s possible for the spoofers to create an SPF record for their domain that will pass SPF. Here is an example email header that I set up to show this in actions. The domain leenu.net was used to send an email spoofing firstname.lastname@example.org and has a valid SPF record.
…Transport; Sun, 10 Nov 2019 05:42:56 +0000
Authentication-Results: spf=pass (sender IP is 6x.8x.17x.214)
smtp.mailfrom=leenu.net; ehloexchange.net; dkim=none (message not signed)
header.d=none;ehloexchange.net; compauth=fail reason=000
Received-SPF: Pass (protection.outlook.com: domain of leenu.net designates
6x.8x.17x.214 as permitted sender) receiver=protection.outlook.com;
Received: from leenu.net (6x.8x.17x.214) by
DM3NAM03FT014.mail.protection.outlook.com (10.152.82.81) with Microsoft SMTP
Server id 15.20.2430.20 via Frontend Transport; Sun, 10 Nov 2019 05:42:10
Subject: Phishing test
To: Undisclosed recipients:;
Date: Sun, 10 Nov 2019 05:42:10 +0000…
The highlighted sections show us that email@example.com sent a spoofed email that passed SPF. So, unless you dig in to the message headers and verify header alignment, its possible for spoofed messages to be accepted. And looking at message headers for every message isn’t a very practical solution.
Another shortcoming to SPF records is the lookup limit. There is a limit of 10 lookups for SPF records. And while that can end up being a large number of hosts, it’s still a finite number of entries that are available within an SPF record. It’s possible that, depending on your environment(s), you could quickly run out of “room” in you SPF record. Any lookups after the limit of 10 will result in an error.
Additionally, mail forwarding can potentially break SPF records as well. For example, if an SPF record indicates that host 188.8.131.52 is allowed to send as ehloexchange.net and the initial recipient forwards the message, the second recipient will see the message delivered from a different IP address breaking SPF.
Finally, SPF records have the ability to utilize a soft fail catchall method (~all). This allows legitimate senders to pass SPF, but illegitimate senders are still accepted as well. Basically rendering the SPF record useless. Worse yet, domains with these records are often specifically targeted for malicious purposes.
So as you can see, although a good start, SPF records by themselves don’t provide a full scope of protection for your email. Luckily, there are several more methods of protection included in sender authentication and Office 365 that I will cover moving forward in this series.