The fight against email spam is an on-going battle for mail administrators and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated and their practices have evolved over the years; fortunately, the technologies available to protect against such attempts have equally improved.
There are several technologies that can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year however it seems like these features get very little talk.
You’ve likely heard of SPF but what about DKIM and DMARC? Should you be implementing these?
Part 1 of this series will summarize these technologies and discuss how each builds on one another. Part 2 will get into the actual configuration in Exchange Online and some of the things you’ll want to watch for.
In the article below, I’ll provide an overview of what the three technologies are, how they provide different types of protection and how they can work together.
SPF (Sender Policy Framework)
SPF is pretty well known and commonly implemented. If you’re not familiar with SPF, it’s essentially a DNS record (TXT) that contains a list of approved senders by IP address, domain name or some other mechanism.
With Exchange Online, Microsoft provides you the information to properly configure your SPF record. However, if you have third-party services sending on your behalf, you may need to customize the provided value. There are some limitations on the number of DNS queries you can have in your SPF record and it’s not uncommon to see syntax errors so you should always validate your SPF record with one of the online validation tools.
If a message is received from a source not authorized in the SPF record, you as the receiving party can do what you choose with that information. You may decide to block the message, you might rank it higher as prospective spam or you could ignore it.
What Does It Protect?
SPF looks as the “Mail From” field within an email and compares the sending IP address to the published TXT record for that domain. Important to understand here is that the “Mail From” field can contain a different value than the “From” or “Reply To” fields. This is how some phishing emails can enter your organization as they will have a valid SPF published for the “Mail From” and then present the user with a different email in the “From” field.
DKIM (DomainKeys Identified Mail)
DKIM uses a public/private key to sign messages as opposed to the published TXT record. One advantage of DKIM over SPF is there is no limit to the number of partners you can authorize to send on your behalf (assuming they support DKIM). If you use a number of third-party senders, you likely have run into issues of when trying to include them in your SPF. Another way to address the SPF limitation is to have senders send their messages under a subdomain and publish a separate SPF for that subdomain.
What Does It Protect?
DKIM is also looking at the “Mail From” field and will show a “None”, “Pass” or “Fail” once the message has been evaluated. The same potential phishing issue exists with DKIM where the “Mail From” does not necessarily match the “From” field that the user sees.
What is… DMARC?
For DMARC, a DNS TXT record is created (_dmarc.company.com) and for mail systems that use DMARC, they will send success/failure reports to the addresses specified in the TXT record. A third-party tool or service can be used to aggregate these reports and analyze them.
DMARC, among other things, can be the answer to the above phishing issue. DMARC looks for a passed SPF or DKIM but also looks for “alignment” of the “Mail From” and “From” fields. Additionally, your configuration of DMARC allows you to tell recipient mail servers what to do with a message if DMARC fails.
Configuration
In Part 2 of this article, I’ll get into the configuration of SPF, DKIM and DMARC in Office 365 and cover some of the nuances you need to be aware.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
