共用方式為

Best Practices for Exchange Online Protection customers to align with DMARC

  • 發行項

Background

Spammers frequently forge the "From" address on email messages so the spam appears to come from a familiar sender such as your bank or social network, or more dangerously, from your own organization so that it looks like an internal sender. To help prevent this abuse, Exchange Online Protection (EOP) supports DMARC, a protocol that allows domain owners more control over how EOP treats spoofed emails containing their domain.

For example, if your organization is Contoso, with the domain contoso.com, a spammer may send a message like this:

From: “Contoso IT department” <IT@contoso.com>
Subject: Please reset your username and password

DMARC is designed to stop this sort of phishing to protect your users. To see how, check the end of this blog post for some examples.

However, while DMARC does stop phishing, it also means that some legitimate senders will need to update how they send email.

What should senders do?

* Sending outbound email through EOP

With few exceptions, all senders who relay outbound email through EOP (i.e., email originating from your own on-premise server or from your own mailbox hosted within EOP) should send email from domains you own and are provisioned as Accepted-Domains in the Exchange Admin Center, or explicitly listed in an inbound on-premise connector. It is not recommended that you send from domains that you have neither provisioned nor listed in an inbound connector.

*
Emails sent on your behalf by others
Emails sent on your behalf by others, such as a bulk email service provider, should be properly set up to authenticate using SPF, DKIM, and DMARC. Failure to set this up will cause email to appear unauthenticated and may generate false positives, especially if the mail is sent to your domain and your domain is protected by EOP.

* Sending email on behalf of others

If you are sending email messages on behalf of a domain that you do not own that publishes a DMARC record with policy p=reject (for example, @yahoo.com, @aol.com, @paypal.com), your messages will be marked as spam when sending to another EOP tenant or may even be rejected due to failed authentication, both when sending to EOP and when sending to 3rd party receivers.

There are common cases when this occurs:

  • EOP customers that send email on behalf of other companies
  • Services coordinating groups of people, like mailing lists, sports teams, online courses
  • Websites where visitors may share with their friends via email, like news and shopping sites
  • Other small business services, including business web portals and calendaring solutions, that send mail between customers and businesses
  • ISPs and other mailbox services that allow their customers to send mail with addresses outside the service’s control
  • Forwarding email into Office 365 and then subsequently redirecting it to another service

If you are sending on behalf of a business, what should you do?

Customers should send from domains that they control, therefore we recommend that you move to sending mail from their own domain.

From: “Example Sender” <example@contoso.com>
To: “Target Receiver” <recipient@fabrikam.com>
Subject: Test message

Another solution is to use the Reply-To field to direct replies to the address of the domain you do not control, but send from your own domain.

From: “Example Sender” <example-sender@contoso.com>
Reply-to: “Example Sender” <example-sender@outlook.com>
Subject: Sending on behalf of another

In the example above, your organization owns contoso.com but does not own outlook.com.

If you are a mailing list owner, what should you do?

For mailing lists, it is recommended to fill the From: line with the mailing list's address rather than the sender's and put the actual sender’s address into the Reply-To: line. This will change the reply behavior.
If your website provides the ability to share items in email, what should you do?

For website operators with 'share from email' functionality, use an email address from your own domain as the From: address and populate the Reply-To: line with the address of the person sharing.

For example:

From: “Example Sender” <noreply@sharing.example>
Reply-to: “Example Sender” <example-sender@outlook.com>


If you are an EOP customer and you get false positives due to DMARC, what should you do?

To determine if a message delivered to you is marked as spam due to DMARC, you will see the following in the message headers:

Authentication-results: protection.outlook.com; spf=pass
(sender IP is xx.xx.xx.xx) smtp.mailfrom=user@contoso.com
dkim=none (message not signed) header.d=none; dmarc=fail
action=quarantine header.from=contoso.com;

The action= will be either action=quarantine, action=oreject, or o.reject (the “o” means that the message failed DMARC with a policy of reject but EOP overrode the reject action and instead marked the message as spam). If you are receiving messages marked as spam because DMARC is failing, it is either because the message is sent by a spammer trying to impersonate a trusted brand, or it is sent from a legitimate sender but the domain in the header.from is not properly configured for DMARC.

To work around this:

  1. Individual end users can add a safe sender for the sender which will deliver the message to the inbox, however, this may result in phishing messages getting through in the event that a spammer sends to a user, spoofing an email address on the user’s safe sender list.

  2. Administrators can create an IP Allow for the sender which will deliver the message to the inbox. This may result in unwanted email getting delivered if the sending IP address also sends spam.

  3. If the messages are failing DMARC but shouldn’t be, open up a support ticket with Office 365 providing examples of messages that are failing DMARC.

    For regular business customers:
    https://support.office.com/en-us/article/Contact-Office-365-for-business-support-32a17ca7-6fa0-4870-8a8d-e25ba4ccfd4b?CorrelationId=c72141db-67a0-4417-a882-19a40408e252&ui=en-US&rs=en-US&ad=US

For Premier customers:
https://premier.microsoft.com/ or through your Technical Account Manager

The above guidance will help ensure that your domains are protected from spam and phishing, but at the same time ensure that you can receive email from the senders you want.

A quick set of DMARC examples

DMARC keeps phishing messages out of user’s inboxes by examining parts of a message and seeing if they are authenticated and aligned. If not, it checks the spoofed domain’s organizational policy for what action to take on the message. In other words, DMARC asks “What should I do with this message if it fails DMARC?”

DMARC does this by:

  1. Checking to see if the message passes SPF or DKIM.

  2. Checking to see if the message From: address (5322.From address) has a DMARC record.

  3. If so, checks to see if the domain that passed SPF or the domain in the d= field in the DKIM signature aligns with (is equal to or is a subdomain of) the domain in the 5322.From address. If so, the message passes DMARC. If not, the message fails DMARC.

Here’s an example of a message passing DMARC:

 Return-Path: <big_long_string>@bounces.amazon.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
  s=v52wzeq2nhi2ivaga2mkkcxigoeqeycs; d=amazon.com; t=1425394122;
  h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type;
  bh=<snip>
Authentication-Results: spf=pass (sender IP is 54.240.15.175)
 smtp.mailfrom=<big_long_string>@bounces.amazon.com;
 contoso.com; dkim=pass (signature was verified)
 header.d=amazonses.com;contoso.com; dmarc=pass action=none
 header.from=amazon.com;

 From: “Amazon Local” <LocalDeals @ amazon.com>
Subject: Adult Tennis Clinics | Online Game Design Training | and 3 more

In the above:

  • The message passed SPF with the 5321.MailFrom domain bounces.amazon.com.

  • The message passed DKIM with a d= domain of amazonses.com.

  • The domain in the 5322.from is amazon.com with the following DMARC record:

    _dmarc.amazon.com. 900 IN TXT "v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:dmarc-reports@bounces.amazon.com\; ruf=mailto:dmarc-reports@bounces.amazon.com"

  • Because bounces.amazon.com passed SPF, and bounces.amazon.com is a subdomain of amazon.com, this message passes DMARC. The DKIM domain amazonses.com would not be enough to pass DMARC because amazonses.com does not align with amazon.com.

By contrast, here’s an example failing DMARC. It is very similar to the above except it comes from a phisher:

 Return-Path: malicious@spamlink.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
  s=v52wzeq2nhi2ivaga2mkkcxigoeqeycs; d=amazon.spamlink.com; t=1425394122;
  h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type;
  bh=<snip>
Authentication-Results: spf=pass (sender IP is 54.240.15.175)
 smtp.mailfrom=<big_long_string>@spamlink.com;
 contoso.com; dkim=pass (signature was verified)
 header.d=amazon.spamlink.com;contoso.com; dmarc=fail action=quarantine
 header.from=amazon.com;

From: Amazon Local <LocalDeals @ amazon.com>

Subject: Password reset – please login to your account within 24 hours

In the above, the message looks it came from Amazon but DMARC detected that it didn’t:

  • The message passed SPF with the 5321.MailFrom domain spamlink.com.

  • The message passed DKIM with a d= domain of amazon.spamlink.com.

  • The domain in the 5322.from (header.from) is amazon.com with the following DMARC record:

    _dmarc.amazon.com. 900 IN TXT "v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:dmarc-reports@bounces.amazon.com\; ruf=mailto:dmarc-reports@bounces.amazon.com"

  • Even though spamlink.com passed SPF, and the domain in the d= signature spamlink.com passed DKIM, the message does not pass DMARC because amazon.com does not align with either of those domains.

This is good for users because it keeps phishing messages out of the inbox.

Comments

  • Anonymous
    March 03, 2015
    Great post with good examples! Any update on DKIM signing. Is it still on the roadmap for Q1 2015?

  • Anonymous
    March 03, 2015
    @Anders: Yes, DKIM signing is on the roadmap but not for Q1 2015.

  • Anonymous
    April 20, 2016
    The comment has been removed