To stop it, you will need to add a Transport Rule that catches them via a matching message header. However, since SPF is only one of the authentication methods for email security. There are also DKIM and DMARC to consider as well.

Exchange Online runs authentication tests and puts the results in a header called “Authentication-Results“, in the form of something like this:

Authentication-Results: spf=pass; dkim=pass; dmarc=pass; compauth=pass

The field compauth is a very interesting one. According to Anti-spam message headers in Microsoft 365, it’s used by Microsoft 365 to combine multiple types of authentication or any other part of the message to determine whether or not the message is authenticated.

It would be perfect for my case. If any message’s Authentication-Results header contains compauth=fail, I am happy to drop it. However, the Transport Rule doesn’t take that part and for whatever reason, it just wouldn’t match. What a bummer.

So, naturally, my next bet would be to use DMARC. Here is how it goes.

Head over to the Exchange Admin dashboard, go to Mail flow > Rules, and click Add a rule.

Give a name, and add a condition that

If the message header Authentication-Results includes dmarc=faile

Do the following actions, such as redirect to quarantine, or reject it back to the sender with or without an explanation.

Since we are using DMARC, I believe we should respect its action setting too. So an exception might be necessary.

Except if the message header Authentication-Results includes 'dmarc=fail action=none'

To wrap it up, a rule like this should get the job done.

Sign into Microsoft 365 Portal and go to Exchange Admin Center.

Click Mail Flow on the left-side pane, and click the little + icon to add a new rule.

Name the Rule, select the following rule as the condition,

Any attachment's file extension matches...'html' or 'htm'

Pick on the following actions as it fits your goal.

• Forward the message for approval
• Redirect the message to
• Block the message
• ect.

If you only want to apply the rule to incoming messages, you can add an exception to allow outgoing emails with the same attachment.

Here is one example of the rule I set in place.

If you are using the Approval approach, you will get emails containing any HTML files for you to approve, like below.

As you can tell, it’s already caught one.

SPF, Sender Policy Framework, allows the receiver to check that an email claiming from a specific domain comes from an IP address authorized by that domain’s admin. A typical SPF record is a TXT DNS entry similar to this:

 "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all" 

it simply tells that emails from the specific domain are sent either from 192.0.2.0/24 or 198.51.100.123 or should be rejected if came from anywhere else.

Tool to check SPF record: https://mxtoolbox.com/spf.aspx

DKIM, DomainKeys Identified Mail, allows the receiver to check that an email claiming from a specific domain was indeed authorized by the owner of that domain. It requires a digital signature linked to a domain name for each outgoing email message. At the receiver end, the email can be verified by looking up the sender’s public key in DNS. To achieve this, you will need a public key entry in the domain’s DNS as well as a digital certificate on the mail server.

You don’t need to implement both SPF and DKIM. Utilizing either one of them should be good enough.

/Update on May 7, 2019/

Thanks to Dave for pointing out that you do need both SPF and DKIM. Yes, SPF and DKIM accomplish the same goal with a different approach. Implementing both would be ideal. I should have pointed out that most of the mail providers like Office 365 and G Suite have default DKIM in place for those who don’t have it implemented. It’s always recommended to use your own DKIM key on all outgoing messages.

Tool to verify DKIM setup: https://mxtoolbox.com/DKIM.aspx

To set up and enable DKIM in Office 365, follow this documentation.

DMARC, Domain-based Message Authentication, Reporting, and Conformance extends both SPF and DKIM and gives the domain owners a way to protect their domain from unauthorized use, a.k.a email spoofing. A TXT entry was added in DNS as a policy to specify which mechanism (SPF or DKIM) is employed when sending emails from that domain and how to check From field presented to end-users.

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

it simply translates that DMARC version 1 will be used with none in Policy, Quarantine in the subdomain, percentage of “bad” emails to apply the policy, and an email address to receive aggregate reports.

Note that _dmarc needs to be in the Host field when adding the TXT record. You will need to set up either SPF or DKIM first before setting up DMARC. A message that doesn’t pass SPF or DKIM checks triggers the DMARC policy.

Once it’s published, the mailbox specified in the entry will be getting reports in XML format once per day.

It’s recommended to set the policy to none when first implemented so no impact will be made to your email setup. Once you have collected enough data and analyzed it, you can then change the policy to either reject or quarantine.

Tool to verify DMARC record:

• https://mxtoolbox.com/DMARC.aspx
• https://www.learndmarc.com/ – a visual breakdown of how email servers communicate, giving you a better understanding of SPF, DKIM and DMARC and how they work together.

Resource

• SPF Wiki – https://en.wikipedia.org/wiki/Sender_Policy_Framework
• DKIM Wiki – https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
• DMARC Wiki – https://en.wikipedia.org/wiki/DMARC
• DMARC – https://dmarc.org/overview/
• Email Authenticity 101 – https://www.alexblackie.com/articles/email-authenticity-dkim-spf-dmarc/