Using DMARC to Prevent Spoofing


UPDATE: Exchange Online now suppports outbound DKIM signing.

 

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: phish@phishing.contoso.com  <-- 5321.MailFrom
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" security@woodgrovebank.com  <-- 5322.From
S: Reply-To: "Woodgrove Bank Security" <phish@phishing.contoso.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details. Please click the following link to accomplish this.
S:
S: http://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

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 phish@phishing.contoso.com. 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) smtp.mailfrom=phish@phishing.contoso.com
dkim=none (message not signed) header.d=none; dmarc=fail
action=quarantine header.from=woodgrovebank.com;

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.

 

Resources

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
DMARC.org

Comments (9)

  1. Chad Pearson says:

    Very informative and well written. Thanks!

  2. Esequiel Silveira says:

    Great article, easy to understeand, Thanks!

  3. lee says:

    Great explanation of both DMARC and SPF, thanks.

  4. Anonymous says:

    Welcome to the first episode in a new series called Support Hot Topics for Exchange Online Protection . This series will consist of short videos which will each cover a trending topic relating to Exchange Online Protection. These videos are designed to

  5. Drew-TX says:

    Makes me wonder why Outlook shows 5322.From verses 5321.MailFrom. Wouldn’t it be better to display the latter?

  6. Sakha says:

    Hello Andrew,
    If there are 3rd party vendors who are sending emails using our domain in the 5322.From header and the vendor's domain 5321.MailFrom header, then the SPF would pass for the Return-Path, however as the From address and Return-Path is different, the DMARC will
    fail. The transport rule suggested in the Terry Zink's blog is catching the emails that are coming from 3rd party vendors, which should not happen. Would adding the IP address in the exception work?

  7. Hi Sakha, if you have a list of IPs that your partner sends from, adding them to the exception list for your transport rule should prevent it from triggering on your partners emails. Messages sent from that IP will not be evaluated against that transport
    rule with the exception in place.

  8. Anonymous says:

    Looking to implement DKIM signing on mail that is outbound from Office 365? This can be enabled in Office 365 through a manual process. In this article we’ll talk about what this process looks like, and why you may want to consider using DKIM to protect

Skip to main content