Recently, I’ve noticed that sometimes customers in Office 365 will login to the Exchange Admin Center, go to Protection –> Spam Filter –> Advanced Options and enable the Advanced Spam Filtering (ASF) option for “SPF Hard Fail.”
The reason people do this is to stop messages from arriving into a customer’s organization that look like it’s an internal message, but really aren’t internal messages. Instead, they are phishing messages from an outside attacker that is spoofing the domain to make it look like a regular internal message.
For example:
The above resembles an internal message from one high-level employee to another, but it isn’t. It’s a phisher impersonating the sender.
Since SPF is a technology that can be used to block spoofing, people naturally assume that it is appropriate to use here. But when it comes to using the ASF rule for SPF Hard Fail and using it to block apparently-internal spoofing messages, my advice is this: Don’t. It doesn’t catch most of these types of messages and you’ll probably end up getting a lot of false positives from senders who have misconfigured SPF record.
Instead, use DMARC to stop these types of messages. You can do this by creating an Exchange Transport Rule and setting up a DMARC record, even with an action of p=none.
The following instructions are for a straightforward scenario – your MX record points to Office 365 and you don’t route mail out-and-back to the service. More advanced customers already know this stuff, but less advanced ones can appreciate this guidance.
First, publish a DNS record for your domain with a DMARC record that doesn’t reject any email.
For example, for the domain contoso.com:
_dmarc.contoso.com IN TXT "v=DMARC1; p=none; pct=100"
After you set this up, any email that sends as you – either in the SMTP MAIL FROM or the header.from (the one you see in your email client) that doesn’t authenticate will fail a DMARC check. However, because you haven’t set up a policy that says to take action, the spam filter within Office 365 takes no special action.
Second, create an Exchange Transport Rule (mail flow -> rules) that has the following syntax:
*Apply this rule if
A message header includes… "Authentication-Results" header includes "dmarc=fail action=none header.d=contoso.com"
AND
The sender is located… Outside the organization
*Do the following…
Set the spam confidence level (SCL) to 9
AND
Set the message header to this value… Set the message header "X-ETR" to the value "DMARC=fail and set the SCL to 9"
You will need to add each domain you have for the dmarc=fail action=none header.d=<your domain> part of the rule.
What happens now is that if a message with your domain enters your organization, unless it passes SPF or DKIM authentication, the message will be marked as spam and take the high confidence spam action (spam quarantine, junk folder, or whatever action you have specified).
This means that any malicious phisher that is attempting to fake out anyone in your domain will be stopped from getting it through. But, the flip side is also true. If anyone sends email into your organization legitimately (such as a marketing newsletter), it will be marked as spam unless you add it to your SPF record (recommended) or configure an Allow rule for it.
At this point, you can stop if you never send marketing email or care about who’s spoofing you, but instead you just want the spoofs to stop.
Third, if you have the ASF rule for SPF hard fail enabled, disable it.
You don’t need this rule enabled if you’re trying to stop spoofing of your own domain. The above works better.
Fourth, make sure you have enabled outbound DKIM signing in Office 365.
As of July 21, 2015, outbound DKIM is not yet released. However, as per our roadmap on https://roadmap.office.com, it is targeted by the end of Q3, 2015. When it is released, I’ll update this blog post.
Fifth, keep going to get to DMARC p=reject.
The above Exchange Transport Rule with the DMARC combination works for messages sent into your organization if it flows through Office 365 [1]. However, other phishers can still spoof your domain and send to people you communicate with. In that case, you need to ensure that your domain can’t be spoofed by using DMARC with p=reject.
That’s beyond the scope of this blog post, but I recommend working with a third party vendor to set up DMARC reporting and then working with them to analyze which IPs belong in your SPF record and which ones do not, and then eventually getting to publish a stricter DMARC policy.
Three from the industry are:
- Agari,http://agari.com/– Microsoft used Agari to improve its SPF authentication
- ReturnPath, http://www.returnpath.com/– provides good tools for senders and receivers
- DMARCIAN, https://dmarcian.com/– has some good tools for smaller domains
Each of these companies can help you extend the required DMARC reporting addresses in your DMARC record to inventory all of your senders so you can avoid false positives and eventually remove the ETR you set up above.
Sixth, we know this is a bit complicated but we are looking at ways to fix it.
Setting up DMARC records and corresponding ETRs is fine for a large organization that knows how to manage its Office 365 protection, and update its DNS records. However, smaller companies often have trouble doing either of these.
We understand this and are thinking of ways to simplify it.
* * * * * * * * * * * *
This article’s instructions should help cut down on the apparently-internal-spoofing problem that we see today. Let us know if it works for you, and if it doesn’t, what parts are lacking.
[1] Office 365 should be your primary email filter. This means that your MX record must point to Office 365 – not to a 3rd party filter, and not to an on-premise mail server. If you do either of those, you will generate lots of false positives.
Related articles:
- What is the best combination for your SPF record, DKIM record, and DMARC record?
http://blogs.msdn.com/b/tzink/archive/2015/07/12/what-is-the-best-combination-for-your-spf-record-dkim-record-and-dmarc-record.aspx - What is DMARC BestGuessPass in Office 365?
http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx - How to align SPF and DMARC for your domain if you use a lot of 3rd parties to send email as you
http://blogs.msdn.com/b/tzink/archive/2015/03/13/how-to-align-with-spf-and-dmarc-for-your-domain-if-you-use-a-lot-of-3rd-parties-to-send-email-as-you.aspx - Best practices for Exchange Online Protection customers to align with DMARC
http://blogs.msdn.com/b/tzink/archive/2015/03/03/best-practices-for-exchange-online-protection-customers-to-align-with-dmarc.aspx - How Office 365 does SPF checks for customer-to-customer email
http://blogs.msdn.com/b/tzink/archive/2015/02/26/how-office-365-does-spf-checks-for-customer-to-customer-mail.aspx - Using DMARC in Office 365
http://blogs.msdn.com/b/tzink/archive/2014/12/03/using-dmarc-in-office-365.aspx