I have recently seen a large number of cases where an organization’s own domain was spoofed to send that company phishing messages. This isn’t all that uncommon, but what was concerning for me was the method used in these cases to do the spoofing. In these cases, only the 5322.From header was spoofed, which cannot be detected by an SPF check.
Over the last couple of months we have published blog articles on DMARC. I’m not going to duplicate that content, but instead provide links to those articles where appropriate.
Note that this information applies to all inbound mail, whether the attacker has spoofed your own domains, or a partners.
Spoofing attempts that SPF cannot protect against
SPF is great for protecting against attacks where the 5321.MailFrom header is spoofed. Where SPF has problems is when the 5322.From header (the address that you see in Outlook).
This can be confusing so let’s look at an example. Consider the following SMTP communication which only comprises of what was sent to the recipient mail server.
S: Helo woodgrovebank.com
S: Mail from: email@example.com <– 5321.MailFrom
S: Rcpt to: firstname.lastname@example.org
S: To: "Andrew Stobes" <email@example.com>
S: From: "Woodgrove Bank Security" firstname.lastname@example.org <– 5322.From
S: Reply-To: "Woodgrove Bank Security" <email@example.com>
S: Subject: Woodgrove Bank – Action required
S: Greetings User,
S: We need to verify your banking details. Please click the following link to accomplish this.
S: Thank you,
S: Woodgrove Bank
Here is what the recipient will see in their Outlook inbox.
Notice that Outlook does not show the 5321.MailFrom header, which in this case is firstname.lastname@example.org. Looking at the message headers will show that this is the domain that the SPF check was performed against. Because this domain is controlled by the attacker, they can setup the SPF to ensure it passes the check. This is why SPF cannot detect this type of spoof.
More concerning, for this particular example, if the recipient replies to this message and isn’t paying attention, they may not realize they are actually mailing the attacker.
If the link was known to be malicious then EOP would detect this as spam, but if the link is brand new then this message may get past the spam filters.
What DMARC does that SPF cannot
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. DMARC requires that a message must pass alignment, along with passing either DKIM or SPF validation. Alignment refers to checking if the 5321.MailFrom domain matches the 5322.From domain.
In the above example, SPF passed, however the 5321.MailFrom domain did not match the 5322.From domain, and so DMARC would produce a FAIL result if woodgrovebank.com published a DMARC record in DNS.
DMARC in Office 365
Thinking about your tenant, how can you take advantage of this? DMARC is still rolling out to our customers and so it may not yet be available in your tenant yet. If it has been enabled, you will see the following in the authentication-results header on inbound messages.
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
Keep in mind that DMARC will not show a failure for this type of attack if no DMARC record is published for the spoofed domain. For a high level look at DKIM and DMARC in Office 365, see the blog post Enhanced email protection with DKIM and DMARC in Office 365.
For specifics of adding rules to your tenant to stop mail that fails DMARC, please see the blog post Using DMARC in Office 365. I would also HIGHLY recommend reading the first link in the resources section below which is about DMARC best practices for Exchange Online Protection customers.
A quick note on DKIM
EOP currently checks DKIM (and DMARC) for inbound messages, but does not currently support DKIM signing on outbound messages. For this reason, if you send outbound mail through EOP, you should not setup DKIM records on your domain until EOP supports DKIM signing on outbound messages. This is anticipated to come later this year. Also note that DMARC relies on either SPF and/or DKIM, so you can take advantage of DMARC today by publishing an SPF record and not a DKIM record.
The following list includes the two links in the above section.
Best practices for Exchange Online Protection customers to align with DMARC
How to align with SPF and DMARC for your domain if you use a lot of 3rd parties to send email as you
Enhanced email protection with DKIM and DMARC in Office 365
Using DMARC in Office 365
An update on DKIM-on-IPv4 and DMARC in Office 365
How to setup DMARC records if you are outsourcing some, or all, of your email
New email authentication protocol – DMARC