Or, you can listen to it below by streaming it in your browser as I’ve now integrated it with Podbean! It took me forever to figure this out, but here we are.

Enjoy.

One of the problems that the email filtering community still hasn’t solved with regards to DMARC is how to deal with the problem of mailing lists.

You know, mailing lists. Those are those things that you subscribe to about a certain topic that contains a bunch of other people. When you email the list, your message is relayed to all the other participants on the list. When they reply, they reply to you and to all of the other list participants which makes it a public discussion. Or, they can choose to email you directly, off-list, making it a private discussion.

Suppose I have a hobby such as magic and I live in the state of Washington. I might decide to join the Washington Magician’s discussion group, WashingtonMagicians@mailingList.org. MailingList.org runs a lot of discussion lists and WashingtonMagicians is just one of them.

The setup for MailingList.org isn’t that complicated; they keep track of all their recipients and only relay messages from people on the list. If you’re not on the list, you can’t get your email through. The mailing list will bounce it back to you.

Suppose I sign up to the mailing list and go through the vetting process and eventually get added. Let’s also suppose that I send the list an email:

I’ve set up SPF for my domain, you can see it’s signing with a DKIM signature, and I’ve even set up a DMARC record of p=reject because I don’t want anyone spoofing my domain.

myPersonalDomain.com IN TXT "v=spf1 ip4:xx.xx.xx.xx –all"

s2048._domainkey.myPersonalDomain.com IN TXT "v=DKIM1; k=rsa; p=<public DKIM key>"

_dmarc.myPersonalDomain.com IN TXT "v=DMARC1; p=reject; pct=100"

It doesn’t get any more secure than this. Heck, I’ve even set up TLS for my domain.

When the message is received at mailingList.org, it scans the message and verifies it. If it stamps the Authentication-Results header (which most mailing lists do not but instead keep in memory), it would stamp it thus way:

Hey, I’m new to the area and I like to perform for free. Are there any good places to go, like Pike Place Market, that don’t require a permit from the city?

Me, being the good email netizen that I am, has properly authenticated my domain with SPF and DKIM and set up DMARC to prevent any of it from being spoofed. MailingList.org knows this and my mail is not marked as spam.

Yet MailingList.org needs to make some modifications to my message. For one thing, it adds a footer to the bottom of the message to indicate a privacy policy. It also adds a few headers to the message to indicate that the message is from a mailing list. Finally, it modifies the subject to make it visible that it’s from a mailing list. It also resigns it with a new DKIM signature.

Our new message looks like the following:

Hey, I’m new to the area and I like to perform for free. Are there any good places to go, like Pike Place Market, that don’t require a permit from the city?
_______________________________________________
Washington Magicians Mailing List
washingtonmagicians@mailinglist.org
http://washingtonmagicians.mailinglist.org

The message is then replayed to all of the mailing list participants.

But here’s where a bad thing happens – the message cannot pass DMARC. Why? Well, at the recipient:

1. The message passes SPF because the SMTP MAIL FROM domain is mailinglist.com and the IP it sends from is in its SPF record. This checks out.
   
   
2. The message’s first DKIM signature fails – the one originally attached by myPersonalDomain.com – because the subject line of the message has been changed by the mailing list, and so has the body to append a footer.
   
   However, the second DKIM signature – the one attached by the mailing list – passes with d=mailinglist.org. So far, so good. MailingList broke the original DKIM signature but affixed one of its own.
   
   
3. The From: address domain is myPersonalDomain.com. Even though SPF passes for mailinglist.com, and DKIM passes for mailinglist.com, neither of those two domains align with the organizational domain of myPersonalDomain.com. Because myPersonalDomain.com publishes a DMARC record, the message therefore fails DMARC.
   
   Because I’ve published a p=reject in my DMARC record, the message is rejected by all receivers who enforce DMARC.
   
   Authentication-Results: spf=pass (sender IP is yy.yy.yy.yy) 
     smtp.mailfrom=mailingList.org;
     dkim=pass (signature was verified) 
       header.d=mailingList.org;
     dmarc=fail action=reject header.from=myPersonalDomain.com
   
   That is, if there’s anyone from Gmail, Hotmail, Yahoo, and so forth, on the mailing list, they won’t see replies from anyone who sends email to the list from a domain protected by a DMARC reject record.

It gets worse; not only can I – someone who is locking down my domain – not send email to these discussion lists because third parties will reject it, the mail is bounced in SMTP. The bounces do not go to me, but instead go to MailingList. MailingList says “Hey, I’m relaying messages for this person but they keep bouncing and can’t get delivered. I’m going to automatically unsubscribe this sender.” So, not only can I not send email to this list, I can’t receive it, either.

This means that you can’t simultaneously lock down your email domain with DMARC and participate in email discussion lists. Even though discussion lists aren’t a large source of traffic, they are an important source. They facilitate better communication with a wide range of people.

Indeed, why shouldn’t domains that publish p=reject in their DMARC records be able to participate in mailing lists? That should be the goal, to get all domains to be protected with DMARC. Seems like a pretty big problem to solve.

Aren’t there any solutions? How can this be fixed?

Related articles in this series:

• Solving the problem of DMARC’s incompatibility with mailing lists – Part 1
• Three options for solving the problem of DMARC’s incompatibility with mailing lists – Part 2
• A fourth option for solving the problem of DMARC’s incompatibility with mailing lists – Part 3

How can we solve the problem of mailing lists breaking DMARC?

1. Don’t let anyone with a DMARC record of p=reject join the mailing list

One solution is to moderate who joins the mailing list. Domains that you think will fail DMARC cannot sign up.

This is the worst solution.

First, it excludes a large set of the population from joining a discussion list as both yahoo.com and aol.com publish DMARC reject records. It also excludes people from their corporate domains (i.e., using their work email address) from joining a list. I don’t know about you, but I wouldn’t mind having someone from twitter.com or linkedin.com on a discussion list, it makes their presence seem kind of official as a representative of their company. Also, the overwhelming majority of people with @yahoo.com or @aol.com email addresses don’t know what DMARC is, they only know what email is. Why force them to get a second account?

Second, it’s philosophically wrong. We should be encouraging people to protect their domains with DMARC p=reject, not hack around it when inconvenient. What we’d be left with is domains with weak authentication on mailing lists. If one-to-one email can be secure, so should mailing list traffic. It’s not the fault of the domain owners they publish DMARC, DMARC the standard should figure out a way to allow it.

2. Email filters shouldn’t enforce DMARC for mailing lists

A second idea is for email filters to keep track of reputation. If it knows that mailing lists generally send good email to its recipients (to its domain, e.g., if Hotmail/Outlook.com knows that @mailingList.org sends good email to @hotmail.com or @outlook.com), or it knows its users have @mailingList.org in its safe senders or contacts, or an implied relationship by analyzing sending patterns, suppress DMARC enforcement.

The idea here is that the email filter knows that DMARC will fail but reputation of the sending mail server, or established communication patterns, trump authentication failures.

The problem is that it’s a lot of secret sauce and mostly works for large senders like Gmail, Hotmail, Yahoo, etc. They can (and do) spend a lot of time keeping track of reputation and it’s a bit different at each provider. And just because it works at one provider, or even most providers, a subscriber can still get bounced from the list if even one provider is still rejecting the message because of DMARC.

This solution kind of works, and is kind of enforced today at some email receivers, but still suffers from a lack of uniformity across all email receivers.

Then at the destination, keep it identical except for adding headers – no adding footers or modifying subject lines:

SMTP MAIL FROM: washingtonmagicians@mailinglist.com
DKIM-Signature: v=1; a=rsa-sha2; c=relaxed/relaxed; s=s2048; d=myPersonalDomain.com
  h=From:To:Subject:MIME-Version;
  bh=<body hash #1>
  b=<signature #1>
From: Terry Zink <tzink@myPersonalDomain.com>
To: Washington Magicians <washingtonMagicians@mailingList.org>
Subject: Hi, I’m new here. Any good places to perform?
List-Subscribe: http://washingtonmagicians.mailinglist.org
List-Post: mailto:washingtonmagicians@mailinglist.org
List-ID: Washington Magicians

Hey, I’m new to the area and I like to perform for free. Are there any good places to go, like Pike Place Market, that don’t require a permit from the city?

The message will fail SPF, but it will pass DKIM since the body of the message hasn’t changed, nor have any of the headers. Since the d= domain is myPersonalDomain.com aligns with the header.from domain myPersonalDomain.com, DMARC passes.

The mailing list is now operating as a pure forwarder (almost). The only thing that has changed is the SMTP MAIL FROM. Indeed, there are some mailing lists that operate this way, even today.

The problem is that modifying the subject line and adding footers is useful. If it weren’t, mailing lists wouldn’t do it. It’s done to give users a visual indicator that the message comes from a list and many people create rules in their local email clients to sort messages. The footers help people sign up and get more information about the list.

While operating as a pure forwarder gets around the problem, it loses some of the most useful parts of mailing lists – letting the recipient know they are getting a message from a mailing list.

No, this solution isn’t a great option. It works in some cases, but not in many others.

=================

So, what else is there?

Related articles in this series:

• Solving the problem of DMARC’s incompatibility with mailing lists – Part 1
• Three options for solving the problem of DMARC’s incompatibility with mailing lists – Part 2
• A fourth option for solving the problem of DMARC’s incompatibility with mailing lists – Part 3

We’ve looked at three options for solving the problem of mailing lists who have problems delivering email for domains that publish p=reject. None of the solutions are great. What else is there?

4. Play around with the From: address, or maybe even the Sender: and Reply-To: fields, to make it not fail DMARC

Another way to avoid failing DMARC is to fiddle around with the original message so that when it is relayed, it doesn’t fail DMARC.

One way is for the mailing list to set the Reply-To header with the original From address, and replace the original From address with the mailing lists’s address:

SMTP MAIL FROM: tzink@myPersonalDomain.com
DKIM-Signature: v=1; a=rsa-sha2; c=relaxed/relaxed; s=s2048; 
  d=myPersonalDomain.com
  h=From:To:Subject:MIME-Version;
  bh=<body hash #1>
  b=<signature #1>
From: Terry Zink <tzink@myPersonalDomain.com>
To: Washington Magicians <washingtonMagicians@mailingList.org>
Subject: Hi, I’m new here. Any good places to perform?

And relay it like this:

SMTP MAIL FROM: washingtonmagicians@mailinglist.com
DKIM-Signature: v=1; a=rsa-sha2; c=relaxed/relaxed; s=mailer;
  d=mailinglist.org
  h=From:To:Subject:MIME-Version;
  bh=<body hash #2>
  b=<signature #2>
From:Washington Magicians <washingtonMagicians@mailingList.org>
To: Washington Magicians <washingtonMagicians@mailingList.org>
Reply-To: Terry Zink <tzink@myPersonalDomain.com>
Subject: [Washington Magicians] Hi, I’m new here. Any good places to perform?
List-Subscribe: http://washingtonmagicians.mailinglist.org
List-Post: mailto:washingtonmagicians@mailinglist.org
List-ID: Washington Magicians

The advantage of doing it this way is that the mailing list can modify the content to its heart’s content. In this example, it added headers (which is always fine), modified the Subject and appended a footer and DKIM signs the entire message. Because the DMARC check is done on the new From: address, and the new From: address aligns with the domain that passed SPF and DKIM, DMARC passes.

But the new From: address is the mailing list, not the original sender. When anyone else replies to the list, the reply goes to the Reply-To field and not the From address. Or does it? It depends on what email client you are using. Microsoft Outlook may do it differently than the native iOS mail client which may do it different than Outlook for Mac.

This can be annoying. Another participant wants to reply to the list and instead of replying to everyone on the list, they reply to (get it?) the original sender directly instead of the original sender and the rest of the list. If you hit Reply All, you’ll expect to everyone (original From + the To which is the mailing list). But, your mail client may just include the Reply-To in which case you have to add the list manually.

But at least it passes DMARC.

Another way is to fiddle with the Sender: header. This is pretty much the same as the above except that instead of putting the original sender in the Reply-To, they are put into the Sender field:

SMTP MAIL FROM: washingtonmagicians@mailinglist.com
DKIM-Signature: v=1; a=rsa-sha2; c=relaxed/relaxed; s=mailer; 
  d=mailinglist.org
  h=From:To:Subject:MIME-Version;
  bh=<body hash #2>
  b=<signature #2>
From: Washington Magicians <washingtonMagicians@mailingList.org>
To: Washington Magicians <washingtonMagicians@mailingList.org>
Sender: Terry Zink <tzink@myPersonalDomain.com>
Subject: [Washington Magicians] Hi, I’m new here. Any good places to perform?
List-Subscribe: http://washingtonmagicians.mailinglist.org
List-Post: mailto:washingtonmagicians@mailinglist.org
List-ID: Washington Magicians

Once again, DMARC passes. And unlike the Reply-To trick, the reply does go to the From: address which is the entire mailing list. So that’s not bad. But most email clients other than Microsoft’s Outlook desktop client don’t even show you the Sender. For the above message, here’s how it looks:

This suffers from a lack of clarity when the user reads it. In the case of Hotmail/outlook.com or Gmail, it tricks the user into think it was “Washington Magicians" that sent the message, but it’s not; it’s me (Terry Zink). This isn’t shown anywhere in the list view or the reading pane in two common web mail providers. It looks like the message is From the discussion list (which is correct) but doesn’t show the true author of the message (which is me).

For Outlook desktop, it does show the true author of the message but it has it backwards – it says me on behalf of Washington Magicians. That’s wrong, it’s actually Washington Magicians who are relaying the message on my behalf. If I sent the message, then I should be in the From: address. The intermediary is Sender:, not the From:.

Some mailing lists even do the following:

From: “'Terry Zink’ via Washington-Magicians” <washingtonMagicians@mailingList.org>
X-Original-From: Terry Zink <tzink@myPersonalDomain.com>

This is yet another way of playing around with the From: address. It shows who the original sender by displaying the Friendly From and that it was sent via the name of the mailing list, and pushes the original from address into the aptly named X-Original-From.

The problem with this solution is that most mail clients could care less about the X-Original-From, and the formatting of the From address – at least in Outlook desktop – is incorrect. It shows only the name of the mailing list <washingtonMagicians@mailingList.org> in the Reading Pane (but the list view is correct). In other words, it confuses email clients. Sometimes it works, sometimes it doesn’t.

So, while playing around with the From address works (i.e., gets around DMARC p=reject), the way the email is displayed to the end user is not all that clear. Either the reply-to-email experience is “off”, or the way the message is shown to the end user is off.

Furthermore, everyone in the mailing list gets the same From: email address. Is that really what we want? Email clients aren’t all going to update do show the correct thing, Apple does something different than Microsoft who does something different in Mozilla Thunderbird who does something different than Google (in Gmail and the native Android email app). Are we going to get all of these email client providers to update their software and get users to update their versions?

Almost definitely not.

Finally, there are some people that are philosophically opposed to rewriting the From: address in any way (you know who you are). The message that was sent should have the same From: address that is relayed to the rest of the group. If you fall into that camp, then all of this From: tweaking won't work for you.

From my point of view, From: rewriting is probably good enough in some cases but does suffer from the email rendering shortfalls.

=======================

So, what else is there?

Related articles in this series:

• Solving the problem of DMARC’s incompatibility with mailing lists – Part 1
• Three options for solving the problem of DMARC’s incompatibility with mailing lists – Part 2
• A fourth option for solving the problem of DMARC’s incompatibility with mailing lists – Part 3

I don’t talk about upcoming conferences that much on this blog, but this one I am doing by special request of one of my readers: The 5th Annual Cybersecurity for Government Summit 2015 behind held in the city of Sepang Utara in Malaysia from July 29-31, 2015.

I understand the threat landscape in North America reasonably well, I understand what US corporations need to do in order to stop cyber threats, and I also understand what steps many of them are taking (to summarize: about 1/3 are doing a lot, and 2/3 are doing a little).

But my view into Asia isn’t clear. The culture is different and the threats are different. But they need advanced threat protection as much as any US corporation. The security industry is either heavily geared around the English speaking world or I have such a cognitive bias that it just seems that way. In any case, conferences in Asia are good to attend in order to get insights into the rest of the world.

The biggest trend in cyber security in the past two years is how to deal with advanced persistent threats. The next biggest trend is how companies can deal with BYOD (Bring your own device). While it’s handy to have employees use their own Android and iPhones for work, how does a company ensure that the point-of-entry remains secure?

Governments, too, across Asia are struggling to keep up with the growing volume and severity of cyber-threats. What makes it even more challenging is that the types of threats affecting each country are different from each other. In order to determine which factors are driving Asia’s cybersecurity spending decisions, we need to look at some of the developments taking place in countries across the region.

And a conference is a good way to learn about it.

So what’s on the agenda for this conference?

• Stuff like big data and security
  
  If you’re collecting it, how can you use it to gain insight into your networks? I think a good follow up topic would be how to protect that data once you’ve collected it, because “big data” means collecting and storing a lot of data about other people who aren’t aware you’re collecting it (agreeing to the Terms of Service doesn’t count as being aware).
  
  
  
  
• Stuff like safeguarding critical infrastructure against modern APTs
  
  How do we safeguard critical infrastructure against modern APTs? Three years ago, Saudi Aramco was hit with a major cyber attack that wiped out the hard drives of nearly 30,000 computers and took two weeks to recover. What happens if a water company, or government energy company, or the telephone network, is similarly hit by a cyber attack?
  
  These types of things interest me because I have no idea whether or not we’re prepared for it, that is, do the companies themselves have a plan? Are they investing in protection against it? Do they have a plan to recovery? Worse yet, if it does go down, does the government have a plan to calm me down when I’m whining why I can’t turn on my lights because the power is down? Or worse yet, can’t watch the newest episodes of Orange is the New Black because the Internet is down?
  
  
  
  
• Stuff like brainstorming how to prevent future security breaches
  
  At conferences I often like panel discussions that give perspectives from multiple people in industry. They can each give their view and the result is a more holistic oversight about what you – the listener – can take away from it.
  
  There are other sessions on the latest security solutions from industry, too. Security is a fast moving business and it’s hard to keep up. I frequently find that the best way to learn about new technologies is to hear the experts talk about them.
  
  

For more details, you can check out the conference agenda for day 1, day 2, and day 3.

So if you’re in the area, maybe check it out. And since you’re there, why not eat some local phad thai?

What’s that, you say? That’s Thai and not Malaysian? Very well. Check out some chai tow kway.

Sometimes [1] people ask me what the best combination of SPF record is if they publish a DMARC record and DKIM record? How should we best present spoofing using authentication records that we publish in DNS?

Here’s what I think.

First, a domain should publish an SPF Hard Fail in its SPF record if they don’t have anything else (no DKIM, no DMARC).

This tells others to mark a message as spam – or give it a heavy weight – if a message comes from an IP that is not in the domain’s SPF record.

contoso.com IN TXT “v=spf1 include:spf.protection.outlook.com 192.168.0.0/24 –all”

This means that a message cannot be forwarded to another recipient at a different email receiver and subsequently pass SPF authentication, but better to forward and set up a skip filtering rule at the forwarded location than have weak authentication and accept spoofs into an organization.

Second, a domain should sign all of its email with DKIM.

Office 365 will support DKIM signing later this year (2015) so you’ll be all set if you use us for filtering.

selector._domainkey.contoso.com IN TXT “v=DKIM1; k=rsa; p=<public key>; n=<notes>”

When the DKIM feature is released, we’ll have more documentation about the syntax.

Third, a domain should publish a DMARC record with p=none as the policy.

Once an organization is confident they have all the IPs in its SPF record and signs all of its email with DKIM – both originating out of Office 365 and at any outsourced bulk mailers like SalesForce, SendGrid, or ExactTarget, they should move to publish p=quarantine and then p=reject (with an optional experimentation with the pct=xx field in the DMARC record to quarantine/reject only parts of the mail stream).

But, when an organization publishes p=reject, they should simultaneously change their SPF hard fail to SPF soft fail.

Huh?

This expands on what Microsoft has published in its official documentation for Office 365, but it goes back to my first point. A message that passes SPF and is forwarded will fail SPF. If a message hard fails SPF it will probably be marked as spam but if it soft fails, it will most likely still be accepted by the recipient. This forwarding failure possibility is why most organizations publish a soft fail record.

But, if a message is protected by DMARC p=reject, a message can fail SPF but pass DKIM (so long as the content isn’t modified), and still pass DMARC.

Thus, the idea is this:

1. If a message comes from a spammer and soft fails SPF, and fails DKIM, and therefore fails DMARC, it will be rejected by the recipient.
   
   
2. If a message comes from a good sender and passes SPF and DKIM, and therefore passes DMARC, it will be accepted by the recipient (if it is rejected, it’s not because of DMARC).
   
   
3. If that message is subsequently forwarded by the recipient to another receiver (e.g., mail going to Office 365 and then forwarded to an outlook.com account), it will fail SPF but pass DKIM, and therefore pass DMARC. It will be accepted by the recipient. Since the message soft fails SPF, it will most likely not be marked as spam.
   
   However, if the forwarded message hard fails SPF, even though it still passed DMARC, it may still very well be marked as spam. A receiving spam filter may not understand “hard fail SPF should be negated by passing DMARC” and instead assign a heavy spam weight to the message, and cause a false positive or even reject the message back to the forwarder leading to mail queuing.
   
   So, the SPF soft fail / DMARC p=reject provides spoofing protection, and lowers the chances of false positives when it is forwarded. It prevents spoofing at the recipient and allows for forwarding which the sender cannot know might happen to its message.
   

Before going to a DMARC p=reject or p=quarantine, you really should have DKIM signing for your domain because of the chances of forwarding.

But if you don’t have DKIM signing, you should probably publish an SPF hard fail and DMARC record of p=none. It means that your email cannot be forwarded, but the flip side is that if you don’t do it, others can spoof your domain.

And that’s how I think SPF, DKIM, and DMARC records should optimally be set up. But I wouldn’t be upset if you stuck with an SPF hard fail, either.

[1] No one has ever asked me this, but let’s pretend for the sake of this blog post that they do.

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.

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
  

A couple of months ago, Office 365 released Advanced Threat Protection (ATP) for Exchange Online Protection. You can read more about that here:

Exchange Online Advanced Threat Protection is now available
https://blogs.office.com/2015/06/01/exchange-online-advanced-threat-protection-is-now-available/

You can read more about how to use it here:

Getting started with Office 365 Advanced Threat Protection
http://www.c7solutions.com/2015/06/getting-started-with-office-365-advanced-threat-protection

I was the Program Manager heading up the Safe Links feature, which rewrites URLs such that anyone behind the Safe Links service has the URL rewritten to first proxy through our web server where we reanalyze the message. If it’s safe, we direct the user back to the original web page. If it is malicious, we redirect the user to a warning page.

I’m not going to describe how the feature works, you can do that by reading the links above. Instead, I’m going to talk about the front end design of the feature – how you, as a user, interact with it. I’m doing this because this is the first feature where I had to really think through how to phrase things and I am pleased with the result (unless people say it’s confusing, in which case I will say it was an experiment).

Here’s a screenshot of how you set up a new policy. For brevity, I have omitted the part at the bottom where you can scope it to a set of users, domains, or groups of users.

Nothing selected to begin with

The first thing you’ll notice about the above is that it is clean, that is, everything is empty. In other words, all options are off by default. That’s how I wanted it, my goal was that a user should be able to get up and running with as few clicks as possible. In the above screenshot, the first thing you can modify is to turn the feature on. We wanted it such that as soon as you buy Advanced Threat Protection, it is not enabled by default. Everyone wants to experiment first, so we had to ensure that the UX reflected this. The “Off” is selected by default.

But, if you click “On”, it’s on for everyone in your organization. The default scope is to apply to everyone (not pictured above). So, with a single click, you can protect everyone in your company with safe links. That’s how we envision most people using it.

The pre-selected options are that way on purpose

Next, notice the next three configurable settings:

1. Do not track user clicks 
   
   This setting is unselected, meaning that the default status is to track when a user clicks on a rewritten link. This is important because in the event that someone does click on a malicious link, we want the administrator to be able to go back and find out who else clicked on it. If it’s not the default state, then an admin is only protected in the future, rather than from the start.
   
   
2. Do not allow users to click through to the original URL
   
   When a user clicks on a link and we think it’s malicious, they can click through to the original page. This is useful in the case of false positives. Without it, a user can’t get to where they were intending to browse in the even the service misclassifies a valid URL. As accurate as we strive to be, unless we are 100% right on every link we don’t want to prevent the user from doing what they need to do. And it should be this way from the start.
   
   
3. Do not rewrite the following URLs
   
   If you have a set of URLs you don’t want us to rewrite, enter them into the box. For example, you may always trust amazon.com; or, your company may have its own private URLs. We left this field blank because everyone is different, and our filtering is smart enough to make the right decision most of the time (we have other heuristics when we decide not to rewrite a URL).

So, from the get-go, we have the options defaulted to what we think is the optimal administrator and user experience, but give the admin a way to override them.

But notice something, everything is Off by default – the Safe Links rewriting is Off, the “Do not track” is unselected (i.e., it’s Off), the “Do not allow click through” is unselected (Off), and the “Do not rewrite these URLs” box is empty (which is subtly saying Off). Everything is Off by default.

We (that is, I pushed for it) did it this way so that you would not have to open up the set of options and see a mix/match of settings. That is, it does not go Off, On, On, Off. This would mean you’d have read each one and mentally hold them in short term memory to make sense of it. Instead, everything is off. It’s like walking into a house and all the lights are off (which is what we were going for), rather than walking into a house and some lights are on and some are off and you have to figure out which light switch applies to what set of lights.

No, instead it’s all minimal. It either had to be consistently On or consistently Off. Not both.

The language is intentional

And because it all had to be all On or all Off, look at how the last three options are phrased: Do not track, Do not allow click through, Do not rewrite. They are all phrased in the negative.

Why?

It’s for consistency.

I didn’t want it to be “Track user clicks” followed by “Allow click through” followed by “Exclude the following URLs from being rewritten.” That’s three different verbs (track, allow, exclude) instead of one verb (do not track) repeated three times. Three different verbs is inconsistent, one verb three times is consistent.

Besides which, if we would have gone with the above options, then it would have been Track user clicks [Selected], Allow click through [Selected], Exclude the following URLs [Empty/Unselected]. That breaks the default consistency of everything Off and flips it to Off, On, On, Off.

I didn’t want that. It broke with my theme of unity and minimization.

Because I wanted consistency, it made some design easier. The term “Do not track” is reasonably well known in the internet browser space. It refers to telling your browser to not allow cookies so websites can’t track your behavior. We borrowed the same concept to not allow administrators to track user clicks. “Do not track” in Safe Links means more or less the same thing it does in the Internet browser space.

And if we were going to start with “Do not track user clicks” and wanted consistency, then it made sense to make every option – where possible – start with the words “Do not.”

And I had to push to get that phrasing as the standard phrasing for the feature in the UX. It’s not intuitive at first but you can see the logic. It’s framed that way on purpose.

But you may say “But Terry! It’s phrased in the negative! That’s confusing to a user!”

To which I say “Not so. People are perfectly capable of interpreting phrases voiced in the negative.” Allow me to quote from Stephen Pinker’s The Sense of Style, a guide for writing in the 21st century (emphasis mine):

How long could you go a day without using the words no or not? The sarcastic question “What part of ‘NO’ don’t you understand?” reminds us that negation is perfectly easy for people to handle in everyday speech. Why should it be so hard in writing?

The answer is that negation is easy to understand when the proposition being negated is plausible or tempting. Compare the negations in these two columns:

A whale is not a fish.	A herring is not a mammal.
Barack Obama is not a Muslim.	Hillary Clinton is not a Muslim.
Vladimir Nabokov never won a Nobel Prize.	Vladimir Nabokov never won an Oscar.

The sentences in the left-hand column all deny a proposition that it would be reasonable for readers to entertain. A whale looks like a fish; Obama has been the subject of rumors about his religion; Nabokov was denied the Nobel Prize in Literature that many critics thought he deserved. Experiments have shown that statements like the ones in the left column, which deny a plausible belief, are easier to understand than statements in the right column, which deny an implausible belief.

The first reaction to reading a sentence on the right is “Who would have ever thought it was?” (Or she was? Or he did?) Negative sentences are easy when the reader has an affirmative in mind or can create one on short notice; all he has to do is pin a “false” tag onto it. But concocting a statement that you have trouble believing in the first place (such as “A herring is a mammal”), and then negating it, requires two bouts of cognitive heavy lifting rather than one.
Or, to put it more positively, when a writer wants to negate an unfamiliar proposition, she should unveil the negotiation in two stages:

1. You might think…
2. But no.

So you see, it’s easy to say “Do not track user clicks” because you could easily assume all rewritten links are tracked. After all, web servers record clicks. “Do not rewrite the following URLs” is easy to conceptualize because we are already in the business of rewriting URLs. The only one that is moderately difficult to conceptualize is “Do not allow users to click through to the original URL.” It’s not as straightforward as allow click through, but it’s not hard either. And, we’re trying to have consistent language with a clean look of everything unselected (Off) by default.

And wrapping all this together, we ended up with the above UX for Safe Links – with as little clutter as possible with as much unifying consistency as possible.

Conclusion

I hope you enjoyed this look behind-the-scenes of the Safe Links UX and what we were thinking (technically, what I was thinking because people didn’t entirely understand why I pushed so hard for what you might think are trivial elements).

For this case, I’m proud of the attention to detail, and I hope you can now appreciate it, too.

Three years ago, I wrote a blog post entitled Combating Phishing talking about what Exchange Online Protection (EOP) does to stop phishing messages [1].

Last year, I wrote one of my most popular blog posts entitled Why does spam and phishing get through Office 365, and what can be done about it?

Recently, I wrote another blog post about how to block phishing when the From: address is the same as the To: address, making it look like an internal message in (Not) Using the Additional Spam Filtering option for SPF hard fail to block apparently internal email spoofing. This blog post recommends customers set up DMARC records of p=none and an Exchange Transport Rule to mark messages as spam if they fail DMARC.

The last item (setting up a DMARC record) is the best way to stop spoofing of your domain. If you add all of your IPs to your SPF record – including any inbound connectors, or permitted 3rd parties who send email as you – everything will work fine. Some of our customers set up the DMARC record but don’t include all 3rd parties in their SPF record, but instead add these 3rd party IPs to IP Allow lists (or to Exchange Transport Rules that operate on the connecting IPs) to skip filtering. This second method is a way of blocking all mail from the outside world as your domain but secretly punching holes for your friends. While I recommend using SPF records to keep track of your friends, the IP Allow route works, too.

However, here’s the problem (it is a problem that is not unique to our customers, it is one that exists everywhere in the industry): not enough people do this. Some set up DMARC records, and some keep track of their 3rd party senders, but many do not. And, spammers keep phishing their domains where the sender (domain in the header.from) looks like an internal message but really is coming from the outside. Without the action of setting up the required DMARC records, there isn’t enough protection. There is a gap between recommendation and implementation.

So how do we fix it?

Here’s how.

You may have noticed a change recently and it can be summarized like this:

If a message arrives from the Internet “from” your domain and destined to your domain, you will notice that unless it authenticates, it will be marked as spam.

Whether or not you publish SPF, DKIM, or DMARC records, any external message that is sent to you as you that doesn’t pass authentication will be marked as spam with the following exceptions:

1. We try really, really hard to authenticate the sender.
   
   SPF, DKIM, and DMARC are ways that domains can explicitly permit 3rd parties to send email as them. However, what we see lots of evidence for is senders setting up mail servers and transmitting email to themselves from IPs outside of their SPF record.
   
   This happens a lot.
   
   We do some extra DNS lookups of the sender and receiver to determine if we can do what I call “extended authentication.” If a message passes extended authentication, we suppress the spoofing failure.
   
   
2. We consider sender reputation as part of our spoofing detection logic.
   
   There are many 3rd party services that send email as the recipient. Sometimes these services authenticate, sometimes they do not. For example, we ask all of our customers to add “include:spf.protection.outlook.com” to their SPF records. Most of our customers do, but some don’t. If email comes from our IP range, since we know how we route email we can factor that into our antispoofing check.
   
   There are a lot of sender reputation variables that we use, but the bottom line is that sender reputation may sometimes override a spoofing failure.
   
   
3. We use the recipient’s own traffic statistics when determining how to apply the antispoofing logic.
   
   Sender reputation is one thing, and authentication is another, but recipient reputation is yet another factor. Are they a large customer that gets lots of spoofed messages? Or a small receiver with few? If they get a lot of spoofed messages, how often do they authenticate? Lots or a little? From which senders?
   
   These factors, plus others, play into the variables that we use to enforce antispoofing logic.

This post contains instructions on how to manually enable signing DKIM on Office 365. Eventually, all the contents of this blog post will move to a TechNet article that has details about how to do it using the UX or with Powershell. That functionality is not yet deployed as of Oct 8, 2015.

However, I get many requests about enabling DKIM signing in Office 365 and a number of our customers have done it. So, rather than having to keep typing it up in email responses, I’m typing up this blog post.

Here’s how to enable DKIM signing for your domain if it is hosted in Office 365 (Exchange Online Protection).

First, for each domain that needs to DKIM sign, you will need to publish two CNAMEs in DNS:

The <domainGUID> is the same as the <domainGUID> in the customized MX record for yourdomain that appears before mail.protection.outlook.com. For example, for a domain contoso.com:

contoso.com.    3600  IN  MX   5 contoso-com.mail.protection.outlook.com.

The <domainGUID> is contoso-com.

The <initialDomain> is the same one that you signed up with for Office 365. For example, contoso.com may have signed up with contoso.onmicrosoft.com. Therefore, the two CNAMEs that contoso.com would publish are the following:

You need to do this for each domain that you use to send email. DKIM signing does not inherit DKIM settings for other domains that you have provisioned for your organization.

For example, if your initial domain is contoso.onmicrosoft.com and you have provisioned contoso.com and fabrikam.com, you will need to provision 4 CNAMEs (two for each domain). The two CNAMEs are so that we can perform automatic DKIM key rotation for you.

Second, let us know when done and we will enable on the backend, you can request this by opening up a support ticket telling us which domains you want DKIM-signing for. We will then create the 1024-bit DKIM public keys and the associated private keys which we store internally.

When done, a DKIM-signed message will look like the following:

From: Example User example@contoso.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
    s=selector1; d=contoso.com; t=1429912795;
    h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
    bh=<body hash>;
    b=<signed field>;

The DKIM-signed messages will align with DMARC (the d= domain will align with the 5322.From domain). This is even true for SMTP bounces where the MAIL FROM is <>.

You don’t need to set the size of the DKIM keys, nor rotate the keys (we do that for you). Once you set it, you can forget it.

And that’s it. As I say at the top of this post, this is only a short term solution and eventually it will all be self serve (that is, asking us to enable it for you will no longer be required, you still need to set up the CNAMEs).

Happy DKIM signing!

As you can see from one of my other posts, Office 365 now lets you sign your outbound email with DKIM signatures.

One of the key differences between how we do it and how almost every other service does it is that instead of requiring the customer to publish the public key in DNS (and we sign with the private key), we require the customer to publish a CNAME to the public key in DNS which delegates their namespace to Office 365. Furthermore, we require customers to publish not one, but two CNAMEs.

For example, here is Microsoft’s set of keys:

selector1._domainkey.microsoft.com. 3600 IN CNAME selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com. (Microsoft publishes this in DNS)

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com. 3600 IN TXT "v=DKIM1\; k=rsa\; p=<public key#1 >n=1024,1435867504,1" (Office 365 publishes this in its DNS)

selector2._domainkey.microsoft.com. 3600 IN CNAME selector2-microsoft-com._domainkey.microsoft.onmicrosoft.com. (Microsoft publishes this in DNS)

selector2-microsoft-com._domainkey.microsoft.onmicrosoft.com. 3600 IN TXT "v=DKIM1\; k=rsa\; p=<public key #2> n=1024,1435867505,1" (Office 365 publishes this in its DNS)

Why do we require a CNAME? And why two of them?

The reason for the CNAME is:

1. It makes it more difficult for anyone to mess it up when copy/pasting the public key. With a standardized CNAME, we can mechanically predict exactly what will work and what will not. We know that when we publish the public key, it will be correct 100% of the time. When a customer sets up the public key, it will be correct less than 100% of the time.
   
   Setting up DKIM can be tricky. When copy/pasting or creating a public key, there are many ways to mess it up – missing semi-colons; missing a single character in the key; missing the v=DKIM1 which is option but SHOULD be in the record, and so forth.
   
   By doing the CNAME, we skip all of this.
   
   
2. With a CNAME, we can rotate the keys whenever we need to. Because we control the public key and private key, when we need to rotate we simply update the private key on the backend and the public key in our DNS servers. The CNAME in the customer’s DNS record still points to us, but what it points to is a new key.
   
   The customer never has to take action. And let’s face it – if you’re an Office 365 customer and we asked you to rotate your DKIM key, you probably wouldn’t do it. With our service, we’ve built key rotation into it.

But why two CNAMEs?

The reason is for seamless DKIM key rotation.

Suppose that we want to rotate DKIM keys on Jan 21, 2016, 10 am Pacific. At that time, we rotate the keys.

However, messages sent from our service at 9:59 am will still be signed with the old key, and if they arrive at their destination at 10:22 am, they can’t be validated because the new key is not in DNS.

Or, DNS may take time to update and replicate worldwide.

Or, because key distribution within our service is not instantaneous, there may be conditions when some messages are signed with the old key and some with the new key.

The end result is the same – during rotation some messages cannot be DKIM-validated for a period of time.

Enter two CNAMEs to the rescue.

1. On Jan 14, 2016, 10 am, publish (if it’s not already there) public key #2 at CNAME #2.
   
   
2. On Jan 21, 2016, 10 am, we start signing with public key #2. There will still be messages in transit that are signed with key #1. Because email is a store-and-forward system, this state of affairs could continue for a while.
   
   
3. On Jan 28, 2016, 10 am, we assume that all messages signed with public key #1 are out of the system and everyone else’s system, too. After all, we’ve been signing all mail with public key #2 for a week. We then update public key #1. Messages sent more than a week ago cannot be verified anymore. But it doesn’t matter because a message doesn’t need to be reverified. And if it does… it’s too late.
   
   
4. The next time we want to update, say Jan 21, 2017, we repeat the process. We flip back to key #1 (which contains a rotated key) and then update public key #2 a week later. By this time, all the old messages are out of the system and hopefully everyone else’s system.

In this manner, we’ve enabled customers to automatically rotate their DKIM keys without doing anything, and it’s all automatic. Furthermore, it fails over seamlessly without downtime during key rotation. It takes DNS a couple of days to replicate everywhere, and it takes our own system a few minutes to up to a couple of hours (in the worst case) to update everywhere. But it doesn’t matter because we’ve built replication delay into the system. Our rotation happens outside of those windows.

In the picture below, DKIM key #1 is in red and DKIM key #2 is in blue. The horizontal lines indicate messages signed with the corresponding DKIM key.

From Nov 1, 2015 to Jan 21, 2016, all messages are red.

After Jan 21, 2016, some messages are red but they fall off after a few days, and the rest of the messages are in blue. This is the transition period.

A week later, all messages are in blue.

We rotate the red key when we are confident all messages are now blue.

This flipping back and forth happens behind the scenes as Office 365 alternates between changing the DKIM signing selector (selector1 vs selector2) which correspond to CNAME 1 and CNAME 2. Because the customer domain has pre-populated these fields in DNS, they don’t need to be aware of which selector or key is active because Office 365 is in control. And when it comes time to flip back to key #1, the blue messages will taper off during the transition period.

This is how DKIM key signing ought to work – keys should be updated automatically so customers (who don’t understand DKIM that well, and are reticent to make DNS changes) don’t have to do anything beyond the initial DNS record publishing. By operating as a middleman, Office 365 can handle it all automatically.

And I think this is a great improvement in how DKIM key management is done.

Sometimes people ask me how they should configure Outlook and Office 365 (Exchange Online Protection, or EOP) so they work together in the best way. This is tough for me to recommend because it depends on the local set up.

However, I can talk about how I personally use it. I am both a normal end user through my account at work, @microsoft.com. And, I am end user and administrator through my personal domain, @terryzink.com. I’m the only person on my personal domain although I do have many email accounts on it.

So, here is how I set up my own accounts so they work best for me from an antispam point of view. One is for me as an administrator of my personal domain with a very simple configuration (one user), and one as an end user in a large organization. This guide does not tell an administrator of a large organization how to set things up.

One more thing - your mileage may vary.

1. In your DNS provider (or following your organization’s DNS change-management process), set up the required SPF, DKIM, and DMARC records for your domain

For my personal domain and for Microsoft

• For SPF, you’ll need to follow the official documentation we have but I’ve outlined the best configuration in this blog post:
  
  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
  
  If you have a complicated SPF record with lots of IPs sending as you with many nested includes, you may want to consider using a 3rd party service like ValiMail that allows you to publish a wildcard SPF entry, and then you manage your SPF record using their web interface. It’s easier than having to do the 10 DNS-lookup limit math, as well as try to fit everything into 255 characters in a DNS TXT record (or 512 if you concatenate them).
  
  
• You should enable DKIM manually by following the instructions in this blog post:
  
  http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx
  
  
• My personal domain terryzink.com has SPF records, DKIM records and DKIM signing enabled, and a DMARC p=reject record published.
  
  For microsoft.com, I added Office 365 to its SPF record, created DKIM records and enabled DKIM signing, and published a DMARC record of p=none. To do all of these, I had to go through Microsoft’s DNS change-management process.
  
  
• I don’t worry about spoofed messages getting through to either my domain or to Microsoft. For my personal domain, since I have a DMARC reject record, no one can spoof it. For Microsoft, we have an Exchange Transport Rule (ETR) that marks any message that fails DMARC from the domain Microsoft.com as SCL 9 which marks it as spam automatically, I talk about how to do this here:
  
  http://blogs.msdn.com/b/tzink/archive/2015/07/21/not-using-the-additional-spam-filtering-option-for-spf-hard-fail-to-block-apparently-internal-email-spoofing.aspx
  
  However, if I didn’t do any SPF, DKIM, or DMARC, I’d still be protected based upon EOP’s special antispoofing solution:
  
  http://blogs.msdn.com/b/tzink/archive/2015/09/10/combating-spoofing.aspx
  
  
• I have enabled IPv6 support for receiving inbound email on my personal domain. I have not enabled Microsoft.com for IPv6 but I would expect that we wouldn’t have any difficult since EOP issues 4xx on inbound IPv6 connections if they don’t have a PTR record on the sending IPv6 address, or the message has neither SPF nor DKIM.
  

2. In the Exchange Admin Center, I  turn off all of the Advanced Spam Filtering (ASF) options (your mileage may vary)

For my personal domain

I don’t have any of the Advanced Spam Filtering rules enabled for my personal domain – not SPF Hard Fail, not “Image Links to Remote Sites”, not “Backscatter NDR”, nor anything else. If you are an on-prem customer who uses Office 365 to relay outbound email, I recommend turning on the “Backscatter NDR” setting. I talk more about this here:

http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx

The other ASF settings are too aggressive for me, if you’re reading this blog post you may want to enable more.

For Bulk Mail, I use the default level of protection which sends anything with a Bulk Confidence Level (BCL) of 7 or higher to junk.

I set both spam and high confidence spam to be marked with an x-header.

For Microsoft

I can’t divulge Microsoft’s configuration for ASF rules, but we send all spam and high confidence spam to the junk folder.

Some customers enable more ASF rules, but the majority don’t enable any.

3. Turn off Outlook’s Junk Email Filtering

For my personal domain

I don’t use Outlook for personal email because I like pressing Ctrl+U to see the raw source of a message. Instead of Outlook, I use a combination of the Thunderbird email client and pull my messages over POP3 (not IMAP, long story) and sort spam based upon an x-header using inbox rules, and I also check mail on my phone.

The problem with checking mail on my phone and using POP3 is that I download all of my email, spam and non-spam alike. I turned off moving junk mail to my Junk folder in Outlook Web Access, I am debating whether or not to turn it back on or to change the spam action to Modify Subject Line so that when my phone downloads something, I know that it’s spam.

For Microsoft

For my @microsoft.com account, I don’t have much in the way of configurability since I am not the administrator of the domain. However, for the most part it isn’t necessary.

I find Outlook’s junk mail double filtering too aggressive and sends too much good email to Junk, so I turned it off (right-click on a message > Junk > Junk Email settings > first tab, Options).

Under the Safe Senders tab, I uncheck “Also trust e-mail from my Contacts” and “Automatically add people I e-mail to the Safe Senders List.” If I want to add to my Safe Senders List, I right-click on the message > Junk > Never Block Sender.

Outlook still sends my messages to the spam folder. It does this because in EOP, when a message is marked as spam EOP sets the Spam Confidence Level (SCL) MAPI property in Exchange and sets the X-MS-Exchange-Organization-SCL header with the SCL 5, 6, or 9. Outlook knows that if the MAPI SCL property is 5-9, move it to Junk.

However, if my mailbox was hosted on-prem, I’d have to either create a local ETR to interpret the headers of the message that EOP stamps and set the SCL locally, as describe here:

https://technet.microsoft.com/en-us/library/jj837173(v=exchg.150).aspx

Or, you could have the X-MS-Exchange-Organization headers preserved when sending from EOP to your on-premise Exchange server and send the message over TLS.

4. Set up Advanced Threat Protection (ATP)

ATP is available from EOP either as a paid add-on, or you can upgrade to our E5 SKU from Microsoft which bundles a bunch of other services in addition to ATP.

For my personal domain

I have all the default options enabled with Do-not-track-clicks off, Do-not-allow-click-throughs off, and the only “Do not rewrite” URL is Netflix.com for some reason (I was probably testing it). I don’t have anyone enabled for Safe Attachments but I’m the only one in my domain. I don’t notice any degradation of service for my personal email. Almost every email I get is in HTML format so the rewritten links don’t look any different. When I click on any rewritten link, the lookup time is negligible and I never notice any lag.

For Microsoft

Much of Microsoft is on both Safe Links and Safe Attachments. Here, because we get so much plain text email, I do notice that sometimes it is inconvenient for messages to have URLs in plain text wrapped. We are looking into giving administrators the option to not rewrite plain text URLs. I might do that if I were an admin, but the tradeoff is that spammers can just send their messages in plain-text to some end users.

Other than that, I don’t notice anything special about my mailbox, the feature is seamless.

It has been one year since I posted that Office 365 now supports inbound DMARC verification. What do we see in terms of how much mail it blocks in production?

Well, we’ve learned a lot of things; some of it good, and some of it bad. I took a look at our network-wide statistics yesterday and a total of 350 million messages arrived at our system with a DMARC record in the 5322.From address (I don’t have numbers on total email). Of that, about 3/4 of the messages passed DMARC and 1/4 of it failed:

That’s a lot of messages failing DMARC, but how much of that is marked as spam?

In Office 365, we don’t reject messages that fail DMARC with p=reject because (a) a lot of our customers have complex routing where they have other services in front of ours that break SPF, DKIM, and DMARC on legitimate email, and (b) a lot of senders don’t have all of their ducks in a row when it comes to SPF, DKIM, and DMARC; and (c) there is still some forwarded email (e.g., mailing lists) that fail DMARC that our customers could not get if we respected DMARC rejects.

So, given that, we override DMARC p=reject and stamp action=oreject for a DMARC fail/p=reject policy, or opctreject if it failed DMARC but the percent=xx randomly overrode a DMARC enforcement (the same for quarantine). Given that, how does the distribution of DMARC fail look like?

You can see that the majority of messages have a “don’t do anything special if this message fails DMARC” policy. Roughly one out of five messages that fail DMARC could get junked.

What do we do with messages that fail DMARC and subsequently go through the filter? Do they all get delivered to the inbox?

No. As it turns out, about 9 in 10 get delivered eventually. Other parts of our filter may still mark them as spam, so even if they fail DMARC with p=none, there is still a chance the message will be junked.

Of that 11%, what sends it to the spam folder? If not the DMARC policy, then what?

And of the non-spam that fails, does our filter also agree that the message is not-spam? Or our customers saying “We don’t care if it fails, it’s a good message so don’t bother even trying to filter it” ?

Here it is below:

Of messages that fail DMARC with p=none, our content filter still marks a message as spam for the majority of those cases. However, sometimes an end user’s blocked sender list (6%) flags it as spam, sometimes a customer’s Exchange Transport Rule (ETR) marks it as spam (4%, no doubt due to this blog post I wrote), and other times we think it’s malware (1%).

The picture is more complex for messages that are marked as non-spam that fail DMARC with p=none. That happens to 89% of DMARC fail/p=none messages, but you can see that much of the time end users are overriding with a safe sender (5%), or the message is an internal message that routes out and back in again within their organization (20%) or they have an IP allow or ETR allow rule (20%). Our filter only gets a chance to make a decision in just over half the cases.

So, clearly, there is a large justification for people to override a DMARC fail action if it happens so often. You may say “Oh, it’s not required because the filter won’t mark it as spam anyway” but in fact these are all pre-emptive overrides just in case because the message is failing sender authentication.

And to prove it, let’s go back to the messages that fail DMARC with p=reject. These should be marked as spam 100% of the time.

But they are not, here’s what that looks like:

In fully one quarter (!) of the cases, a DMARC fail/p=reject is not being marked as spam.

How can this be? Why aren’t 100% of messages that fail DMARC being marked as spam? Don’t we know that all sorts of bad things can happen?

Here’s why these messages are “rescued” from filtering:

From the above:

• 6% of the messages are internal, meaning that someone has a hybrid mail configuration set up in Exchange Online Protection with the proper connectors between the cloud and their on-prem environment, but these messages are failing DMARC. However, since they treated as internal messages, filtering is not enforced. This is a good thing.
  
  
• 27% (which sounds like a lot) is due to an IP or ETR allow. People know that sometimes a message will fail DMARC but yet they still need to override the verdict because it is a known breakage (e.g., mailing lists, or external senders to themselves that aren’t in their SPF or DKIM records). That part is a good thing.
  
  However, customers also do ETR allow rules just on a domain match. This is not a good thing because it’s easy to spoof a domain. I don’t have the breakdown on that.
  
  
• 6% of the messages are rescued because of end user safe senders. This is a mixed bag. End users want to receive email from legitimate senders who get breakage due to forwarding or routing. But sometimes end user safe sender spammers, too. This is a mixed good/bad thing.
  
  
• Finally, 61% of messages in this category are not marked as spam because our filters said not to mark it as spam. This is because we know that a lot of our customers have complex routing where SPF, DKIM, and DMARC are broken before we see the email message. If we enforced DMARC reject they would get far too many false positives. In this case we have to suppress DMARC enforcement.

This completely justifies our reticence to enforce DMARC rejects at the connection level. Our customers have complex configurations, there are a lot of broken senders out there, and end users sometimes want to receive messages even if the message fails DMARC.

So in the end, out of 350 million messages that failed DMARC, about 3.5 million were marked as spam because of a DMARC reject record and nothing else – about 1%.

I know that doesn’t sound like a lot, but 3.5 million spoofing/phishing messages that might otherwise have gone undetected is pretty good.

If you are a customer of Office 365 (Exchange Online Protection, or EOP), you may have noticed, or will be noticing, that we are adding DKIM signatures to your outgoing email, even if you haven’t explicitly enabled DKIM-signing for your domain (see instructions here: http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx). We are gradually rolling this out to everyone.

If you haven’t enabled DKIM-signing, EOP will create a default signing policy for your domain and use those in the selector and d= field in the DKIM signature. For example, suppose the customer Contoso Organization signed up with an initial domain of contoso.onmicrosoft.com, and one of their provisioned domains is fabrikam.com. An outgoing message with a default signature will look like the following:

From: Second Example <second.example@fabrikam.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795;
    h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
    bh=<body hash>;
    b=<signed field>;

Don’t worry if you see this, it means that DKIM is being affixed properly. Assigning DKIM signatures to your domain will help improve your deliverability around the Internet, and it also means that you can send email over IPv6 even if you don’t publish an SPF record. It also helps receivers roll up domain reputation for your domain, instead of having to live within shared outbound IP space.

For verifiers, there is an algorithm we use to formulate the selector/signing domain:

1. IF you see d=*.onmicrosoft.com, AND
2. IF you remove ‘selector1/2-‘, AND
3. IF you replace any dots in the From: address with dashes (e.g., fabrikam.com –> fabrikam-com) [1] and it matches the unremoved parts in the selector (e.g., selector1-fabrikam-com)
4. THEN you can consider the message implicitly DMARC aligned.

The idea here is we, as Office 365, know who are customers are and can properly attribute the message but our customer may not publish an SPF record, or may even publish an incorrect one. We don’t have access to their DNS so we can’t publish the required CNAMEs, but we can put information into the headers of a message that uniquely identifies their domain because they have to put something into their DNS records to enable themselves as a customer of ours. As a receiver, you can use the above to unwind it.

I call this an implicit DMARC alignment, somewhat similar to a DMARC Best Guess Pass.

Next, if you enable DKIM manually, the selector and d= domain will change so that it aligns with the From: address:

From: Second Example <second.example@fabrikam.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1; d=fabrikam.com; t=1429912795;
    h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
    bh=<body hash>;
    b=<signed field>;

Every domain gets their own DKIM keys, they are not shared among customers. They are not even shared among domains within the same customer with the exception of when we cannot attribute a message to a particular organization (i.e., you send from a non-provisioned domain and we don’t know it’s your organization).

This is all part of our ongoing quest to ensure the best security experience for all of our customers.

[1] You can also get this information by doing an MX record lookup and using the <domainGUID>. For example, if the domain where fabrikam.com:

fabrikam.com.    3600  IN  MX  5 fabrikam-com.mail.protection.outlook.com.

The <domainGUID> is the part before .mail.protection.outlook.com. It will not always be the same as the dot/dash replacement I say above because the algorithm works a little differently for domains with dashes in it.

As 2015 draws near to a close, I thought I’d write a blog post about the type of spear phishes we are seeing lately against our customer base. This is not general brand phish like someone spoofing Paypal, but instead a phisher trying to impersonate your domain, for example, if the domain under attack is woodgrovebank.com, we’re assuming the name of the CEO is John Doe.

1. Spoofing your exact domain in the From: address
   
   From: John Doe <ceo@woodgrovebank.com>
   To: Jane Roe <cfo@woodgrovebank.com>
   
   These are the most insidious attacks because if you are using Exchange and Outlook, if the email address matches what is in the Global Address Book, Outlook will pull the picture of the person from Active Directory and display it in the message, fooling you even more that the spoofed sender is legitimate when it is not.
   This is an industry-wide problem and the official solution is for domains to publish SPF, DKIM, and DMARC records if you want to do it yourself. If you can’t, then Exchange Online Protection (EOP) is rolling out its antispoofing solution that works automatically in the absence of SPF, DKIM, and DMARC. This is not something you turn on, we are going to enable it for everybody automatically so your domain is protected from Day 1.
   
   
2. Lookalike spoofing
   
   From: John Doe <ceo@woodgrövebank.com>
   To: Jane Roe <cfo@woodgrovebank.com>
   
   We have seen an increase in these lately, perhaps 1/10 of all spear phishes. The domain being spoofed is not actually the domain but instead contains a non-Roman alphabet character (or two, or three) in it. As a result, at a glance, it looks like the normal domain but in reality it is not.
   
   Phishers use this technique to get around SPF, DKIM, and DMARC because they know that the spoofed domain can’t possibly pre-register every single domain that looks like theirs. However, the drawback for phishers is that if the recipient hits reply, unless the phisher has the domain registered with an MX pointing somewhere, the message will go no where. In addition, since the sending domain and email address will not be in the Global Address Book if using Exchange + Outlook, the picture of the person won’t show up; that’s a level of deception that the phisher loses by using this technique.
   
   We’re aware of this problem in EOP and we our working on it. When we release protection for it, it will be wrapped into our existing antispoofing solution above.
   
   
3. ‘Display From’ attacks
   
   From: John Doe <john.doe@freemailprovider.com>
   To: Jane Roe <cfo@woodgrovebank.com>
   
   Here, the phisher sends a message to the CFO using his free web mail account, e.g., Gmail, Yahoo, or Outlook.com. The CFO is supposed to interpret this as the CEO not being able to get to his work account and instead sends a message from his mobile device.
   
   Attacks like these are effective in the sense that it’s possible to create accounts like this fairly easily by scraping around the Internet, looking for LinkedIn profiles, and creating reasonably legitimate-looking accounts at a free web mail provider. The message will also pass SPF, DKIM, and DMARC and will be sent from an IP with good reputation. Using regular language and email accounts may fool some users into thinking it is the real thing.
   
   The drawback is similar to #2; the Global Address Book will not pull the CEO’s picture and display it in Outlook/Exchange if using those two pieces of software. Also, the full email address will probably be displayed to the end user as it is unlikely to be in the person’s address book.
   
   As above, we’re aware of this problem. Any solution will go into our existing antispoofing solution above.
   
   In the interim, what some of our customers have done is create Exchange Transport Rules (ETRs) that say “If the message comes from ‘John Doe’ in the message header (or as a sender property), set the SCL to 9 (or delete the message, or send to quarantine) except of the message header ‘Authentication-Results’ contains the text ‘dmarc=pass action=none header.from=woodgrovebank.com’.
   
   That is not the only way to do it, of course, and you have to set up a DMARC record; alternatively, you could set up an SPF record and look for the results in that header, too. Anyhow, the idea here is that if John Doe sends to your organization, the message will be marked as spam unless it comes from your own domain. That will stop all Display From spoofs. The drawback is that all of the other John Doe’s in the world will also not be allowed to send email into your organization.
   

Those are the big three types of phishing attacks were are seeing beyond the regular phishing attacks that have been around for years. As you can see, some of them are addressed by sender authentication, but others are a result of phishers being forced to move to other attacks in response to stronger auth.

This is going to be a long post. Sorry. I didn’t have time to write a shorter one.

Who should be responsible for setting up email authentication records?

For years, I have been discussing the virtues of publishing email authentication records including SPF, DKIM, and DMARC. There are plenty of tutorials and documentation on the web, and I have written many articles in support of it, explaining its basics as well, and how it works in Office 365.

SPF, DKIM, and DMARC can be challenging to set up for numerous reasons:

1. SPF requires that you know who all of your senders are and keep them up-to-date. This is hard to do in large, decentralized service where any department can contract out another email sender to send on your domain’s behalf.
   
   
2. SPF also has a maximum 10 DNS lookups. In the modern world, it’s easy to exceed that limit with only a handful of 3rd parties sending as you. Office 365 alone requires you to have a spare lookup limit of 3 DNS lookups.
   
   
3. DKIM is tricky to set up, and even trickier to rotate keys. You have to download and install the software, and then keep the keys in sync across all those servers you are running. Then, you have to publish keys in DNS making sure to copy/paste correctly. Then, when it comes time to update the keys, you have to do it all over again – unless, of course, you are using Office 365 in which case there is slim chance of copy/paste errors and you never have to rotate keys.
   
   
4. DMARC is challenging to set up because you have monitor it all yourself and then make the decision to be more or less aggressive on your mail stream.

For domain owners who are highly motivated to do this sort of thing – people like me and all my friends at MAAWG – this is time-consuming but most of us enjoy it and so it’s not too bad.

However, I don’t think we should expect small business owners to do it. Instead, what I think should happen is this:

If you provide email infrastructure on behalf of someone else, you are responsible for helping your customers set up DKIM/DMARC alignment, and you should rotate keys automatically.

For example, if you are a large bulk email provider bulksender.com, you should:

1. Ensure that your customer sets up DKIM and then you rotate their keys automatically

a) Tell your customers to publish two common keys in their DNS, and these should be predictable. For example, for the domain contoso.com:

HereIsMyFirstKey._domainkey.contoso.com IN TXT "v=DKIM1; k=rsa; p=<public key #1>

HereIsMySecondKey._domainkey.contoso.com IN TXT "v=DKIM1; k=rsa; p=<public key #2>

b) The above is the bare minimum you should do. Ideally, you should not ask your customers to publish TXT records at all for DKIM, but instead publish CNAMEs that point to your own infrastructure:

HereIsMyFirstKey._domainkey.contoso.com IN CNAME HereIsMyFirstKey._domainkey.bigsender.com

HereIsMySecondKey._domainkey.contoso.com IN CNAME HereIsMySecondKey._domainkey.bigsender.com

Ideally, everyone would get their own key. However, this may not be possible as not everyone can store and replicate multiple keys securely. In that case, you may be stuck with common keys.

c) Third, the big sender should sign with the first key and then 6-12 months later, flip over to the second key. The first key should remain in place but then updated to new values a week or two later. Then, 6-12 months later, repeat the process and flip back.


Doing it this way ensures that the customer has DMARC alignment based upon the d=domain in the DKIM signature, and their DKIM keys are rotated automatically without them having to do anything. If you ask your customer to update their DKIM keys, my guess is that perhaps 5% of them will ever do it.

So don’t make them do it. Do it for them automatically by putting them into a good state from the beginning in that their email from your infrastructure is DKIM/DMARC aligned. You can still have your own 5321.MailFrom be your own domain for the purposes of bounce-processing and passing SPF.

Here in Office 365, we’re working on modifying the signup process such that in addition to publishing a couple of DNS records to verify your domain, you also have to publish some CNAMEs to get your DKIM properly set up, too. We use the DKIM selectors selector1 and selector2.

2. If you are a domain registrar with access to the domain’s DNS settings, you should auto-populate their SPF record with options to manage it themselves

SPF records are hard to maintain yourself for a couple of reasons. The first is if you are a small business owner, you probably have better things to do than play around with DNS settings and updating your SPF record (unless you are an email geek like me; if you’re not an email geek you do what your email service tells you to do). I see plenty of small domains and big companies get their SPF record syntactically wrong.

The second reason SPF records are hard to maintain is because once your business grows, you have to keep maintaining a list of 3rd party senders who send on your behalf and keep adding them to your SPF record, but SPF has a cap of 10 DNS lookups. In 2016, it’s easy to exceed that limit. Office 365 takes up 3, Google Apps takes up 3, and SalesForce takes up 2. You’re now at 8. How many more bulk senders can you add? The normal solution is to break it up by subdomains so some senders send from email.contoso.com, others from e-mail.contoso.com, and so forth.

That’s a pain to maintain, too. Believe me, I know, because I’ve worked with teams internal to Microsoft to set it up. The process of setting up these subdomains and then making DNS changes through the change review board is not fast, and even I find it hard to juggle so many different teams’ requests.

A big innovation I see in this space is through the use of SPF macros. Macros allow you as a domain owner to publish a wildcard in your SPF record and instead of returning a static SPF record, it looks it up dynamically. For example, suppose contoso.com’s traditional SPF record looked like this:

contoso.com IN TXT "v=spf1 ip4:1.2.3.4 include:spf.protection.outlook.com include:_spf.google.com include:salesforce.com include:bigsender.com –all"

Contoso knows that it has gone over the limit, so instead it publishes a macro in its SPF record:

contoso.com IN TXT "v=spf1 include:%{i}._ip.{%h}._ehlo.{%d}._spf.contoso.com –all"

Huh?

What macros do is tell the receiving mail server to substitute the part in %{…} with the corresponding value from the email you are checking with the metadata from the email. In the above:

%{i} means the connecting IP
%{h} means the connecting mail server’s EHLO or HELO string
%{d} means the domain you are looking up

If a mail server were to look up the SPF record for contoso.com and see that weird syntax, it would then do a second lookup substituting in the parameters from the message. So, if the email comes from the IP 1.2.3.4 from a mail server whose EHLO string is mailserver.com, and checking the domain contoso.com, then substituting the corresponding parts it looks up the SPF record for 1.2.3.4._ip.mailserver.com._ehlo.contoso.com._spf.contoso.com. The response might be something like this:

contoso.com IN TXT "v=spf1 ip4:1.2.3.4 –all"

A mail server could then do a regular SPF evaluation to see if 1.2.3.4 is in that particular SPF record. In this case it is.

If instead a message arrived from a mail server with an EHLO string NAM02-CY1-obe.outbound.protection.outlook.com from the IP 65.55.159.61, the server would look up 65.55.159.61._ip.NAM02-CY1-obe.outbound.protection.outlook.com._ehlo.contoso.com._spf.contoso.com then the DNS server might return:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com –all"

The mail server then does a normal SPF lookup on this record to see if the IP is in there (it is).

Or, instead if a message arrived with an EHLO string of localhost from the IP 254.1.1.1, the server would get back the macro and then do a second lookup on 254.1.1.1._ip.localhost._ehlo.contoso.com._spf.contoso.com. The DNS server might return:

contoso.com IN TXT "v=spf1 –all"

Because 254.1.1.1 is not in your SPF record at all, the dynamic SPF says it’s not there and tells the verifier to stop checking.

So, rather than you having to publish a static DNS record, you have a backend database that parses out variables from the DNS query and dynamically returns the corresponding response.

Receiver –> DNS –> parse out DNS query –> look up in table ---+
                                                              |
                                                              |
                                 +----------------------------+
                                 |
                                 +
+-------+---------+------------------------------------------------+
| IP    | EHLO    | SPF record to return                           |
+-------+---------+------------------------------------------------+
| IP #1 | EHLO #1 | v=spf1 include:1.2.3.4 –all                    |
| IP #2 | EHLO #2 | v=spf1 include:spf.protection.outlook.com –all |
| IP #3 | EHLO #3 | v=spf1 include:_spf.google.com –all            |
| IP #4 | EHLO #4 | v=spf1 include:_spf.bigsender.com –all         |
+-------+---------+------------------------------------------------+
                                |
                                |
                 Return corresponding SPF record                                 |
                                |
                  Receiver does normal SPF check

Instead of publishing all of your 3rd parties who send as you in DNS, you would use a backend database (preferably through a nice, pretty UX) to add all your senders (the fact that this publishes an SPF record is abstracted from you; you don’t even need to know what SPF is). Ideally, it would have a checkbox for the most common large senders but also let you manually enter IPs that are not associated with any common large sender.

Who do you use to send email?

_x_ Office 365
___ Google Apps
_x_ SalesForce
_x_ Big Sender
_x_ Click here to enter in IPs manually

You could enter in as many as you like because you aren’t worried about exceeding any DNS lookups, the lookup table parses it all out, looks it up in the table, and then dynamically returns the result depending upon the IP/EHLO combination.

It’s an elegant way around the 10 DNS lookups, helps prevent syntax errors, lets you stuff all of your senders into your root domain (@contoso.com instead of @email.contoso.com) and makes it easier to manage over the long term.

---

I, as an author of this blog and speaking of my own opinion and not necessarily on behalf of Microsoft, bring all this up and describe it this way because there is a small company that provides exactly this type of service called ValiMail (my examples above using macros copies their syntax).

I’m familiar with their service and I like what they do, it’s a great way to outsource your email authentication so you don’t have to do it yourself. I also like how they have a lot of automation involved when you set up DMARC records, your SPF record self-populates. That sets you up into a good state and keeps you there.

If you’re looking for a service to do this, you may want to see what they offer.

---

And this brings me back to the registrars.

It would be great if registrars provided a service like this for all their customers. When you registered a new domain, you would get a wildcard SPF record by default with the option to manually do it yourself. The registrar would also publish a default DMARC record for you with the option for you to manually do it yourself. In that way, if you don’t know how to do it yourself, your registrar takes care of it for you. And if you feel confident to do it yourself (or you’re a geek like me and enjoy doing it yourself) you could take over by picking the “I want to do it myself” option.

But in either case, your email is SPF/DMARC aligned and kept up-to-date with minimal inputs from you, right from the beginning of domain registration. I understand that registrars would then have to provide this service, but maybe they could contract that out.

Here at Office365 and Hotmail/outlook.com, we are making some changes with regards to our DKIM-signing in both services. We believe in sender authentication, especially with regards to DKIM, and plan to sign 100% of all email in both services.

1. First, email traffic from our consumer brands will all be DKIM-signed (eventually)

First, Outlook.com and Hotmail.com are going to start rolling out DKIM-signing for outbound traffic originating out of Office365 for users that have been migrated off the old outlook.com/Hotmail stack and onto the Office 365 stack. We are about 1/3 of the way finished that, so not every email from those domains will have DKIM signatures.

Initially, we will (a) add DKIM signatures only to a handful of domains, e.g., to @gmail.com and @yahoo.com and a couple of others, and (b) it will slowly ramp up from a handful of mail servers to 100% of mail servers. (c) Then, we will start signing for all outbound traffic to all domains. This is to prevent this traffic from going from 0 to millions of new DKIM-signatures overnight.

These domains will sign with d= domains in the DKIM-signatures that match the domains in the From: address (e.g., d=outlook.com, d=hotmail.com) which means they will be DKIM/DMARC aligned.

You can read more about the outlook.com to Office 365 migration here:

- New ways to get more done in Outlook.com
https://blogs.office.com/2015/05/21/new-ways-to-get-more-done-in-outlook-com/

2. Second, all outbound traffic out of Office 365 will add a second signature

a) All outbound email for our enterprise traffic in the Office 365 service will start getting a default DKIM signature with d=office365.com for email that originates out of our normal risk delivery pools (i.e., email that is not marked as spam). This means there will be a From: domain that does not align with the d= domain in the DKIM signature.

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=office365.com

This second signature will be added because we use it to aggregate our outbound sender reputation at a service level rather than at an IP-level. We then use it to monitor our service’s spam/non-spam ratio and take action when we observe our users sending high volumes of spam. This helps us maintain good deliverability around the Internet.

This DKIM signature will not be DKIM/DMARC aligned, it is added for outbound spam prevention.

b) For email that originates out of our high risk delivery pools (i.e., email that is marked as spam [before we shut them down], NDRs, other questionable quality email), will have a different d= domain, we haven’t set it up yet but will probably be something like d=somethingAtMicrosoft.net.

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=somethingAtMicrosoft.net

You can read more about our outbound spam strategies here:

- Higher Risk Delivery Pool for Outbound Message
https://technet.microsoft.com/en-us/library/jj200746(v=exchg.150).aspx

- Configure the Outbound Spam Policy
https://technet.microsoft.com/en-us/library/jj200737(v=exchg.150).aspx

This DKIM signature will not be DKIM/DMARC aligned, it is added for the purpose of outbound spam prevention.

c) However, all traffic out of Office 365 should also have a second signature with either a From/d= aligned signature because the customer has set up DKIM signing, or a default signature we add on their behalf that looks like this:

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=contoso.com

OR

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1-contoso-com; d=contoso.onmicrosoft.com

You can see we encode the From: domain into the selector in the event that a customer doesn’t set up DKIM in our UX. This is not yet deployed to our entire customer base but we are working on it (we have to update Active Directory for everyone and then publish DNS records and that takes time).

The custom DKIM signature will be DKIM/DMARC aligned. The default custom DKIM signature is not DKIM/DMARC aligned but with a simple adjustment of the DMARC algorithm (which we do internally), you can extract the domain from the DKIM signature and use it as de factor DKIM/DMARC alignment.
 
For more information:

- Exchange Online is rolling out default DKIM-signing to everyone
http://blogs.msdn.com/b/tzink/archive/2015/12/16/exchange-online-is-rolling-out-dkim-signing-to-everyone.aspx

- Manually hooking up DKIM signing in Office 365
http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx

3. Third, there are some things to be aware of with these DKIM signatures

a) Some of these DKIM-signatures will be broken because our customers route email through Office 365 and then through other systems which modify the message.

RFC 6376 – the RFC that defines DKIM – specifically says to treat a message with a broken DKIM signature as an unsigned message. This is because a DKIM signature may not survive forwarding along the Internet (headers get added, footers get added, messages get formatted, From: addresses get rewritten, etc.). For this reason, a message with a broken DKIM signature out of Office 365 should definitely not be rejected because there is a lot of legitimate email that may become modified.

b) Finally, our consumer traffic may or may not have the second DKIM signature with d=office365.com.

These are the changes that are coming to both services. For the average user, the changes will be transparent to you, you won’t notice anything different. However, what we as an industry use them for are antispoofing checks; antispoofing failure mitigations (an email that originates out of outlook.com which is forwarded will fail SPF but pass DKIM and therefore DMARC); better sender authentication which means that 3rd parties can block more spam, that is, suspicious email “from” outlook.com; better reputation tracking for email originating out of Office 365; improved deliverability to 3rd party services; and finally, compliance with industry best practices.

Thanks for reading.

A few months ago, I made the mistake of signing up for a webcast that opted me in to getting continuous communicates from them about upcoming online seminars.

I was getting tired of all of these invites so I unsubscribed.

I kept getting more invites so I unsubscribed again.

I kept getting even more invites so I unsubscribed a third time!

And then I got more invites!

I got fed up with this sender – I won’t name them out loud but let’s just say that it rhymes with ‘RightTalk’. I finally ended up creating an Exchange Transport Rule (ETR) about two months ago:

PS C:\> Get-TransportRule -Identity "Block RightTalk" | fl Description

Description : If the message:
  sender's address domain portion belongs to any of these domains: 'mail01.righttalk.net'

Take the following actions:
  reject the message and include the explanation 'Stop spamming me I already unsubscribed three times' with the status code: '5.7.1'

As you can see, I am rejecting the message and bouncing it back to them (they send authenticated email so I am not concerned about sending backscatter) and I even tell them why I am doing this. Ever since I created that rule two months ago, I haven’t gotten any messages from them in my inbox.

<Relaxed sigh>

However, yesterday I decided to check whether or not they took the hint and actually unsubscribed me.

Nope.

PS C:\> Get-MailDetailTransportRuleReport -TransportRule "Block RightTALK"

Even as recent as this past week, they are still sending me email. Neither unsubscribing nor bouncing their email has worked. As a customer of the Exchange Online service, I’m happy to not see these messages getting delivered to me. However, as a citizen of the Internet who fights spam for a living, I’m irritated that this sender does not unsubscribe me, nor do they do any sort of SMTP bounce processing.

The other day I was asked to come up with some common errors that we see when people set up SPF records as we want to start notifying our customers when they have these types of errors. I thought it would be a good idea to make this public and add to it as necessary.

1. You have too many DNS lookups

SPF specifies a maximum number of 10 DNS lookups (e.g., nested includes, A-record resolution, MX-record resolution, PTR record resolution, etc. are greater than 10). I talk about how to get around this here:

http://blogs.msdn.com/b/tzink/archive/2016/01/22/email-authentication-should-work-out-of-the-box-and-we-should-not-rely-upon-domain-owners-to-do-it-themselves.aspx

Most verifiers, if they can verify you before hitting the 10 DNS lookup limit, will pass if you haven’t hit 10 up to that point. But go over and this will generate a PermError.

2. Too many SPF records in DNS

This occurs when someone meant to add more IPs or 3rd parties to their SPF record and created a second TXT record instead of including them all into the first one:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com –all"
contoso.com IN TXT "v=spf1 ip4:1.2.3.4 –all"

Whereas it should be this:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 –all"

If this occurs, SPF should return a PermError. We here at Office 365 will cut you some slack and interpret two SPF records as a single one; that is, we detect your probable intent even though you didn’t do it correctly. Most other receivers are not nearly as forgiving.

3. Duplication of what you need for Office 365 to work

You only need to have include:spf.protection.outlook.com in your SPF record, you don’t need any of the following:

include:outlook.com
include:spf.messaging.microsoft.com
include:spf.frontbridge.com

While SPF still works if you include any of the others, you will get unnecessarily closer to the 10 DNS lookup limit (this prevents you from adding much more 3rd party services to send on your behalf).

As a matter of fact, if you have any of those in your SPF record, you should replace them with include:spf.protection.outlook.com.

4. Forgetting to include an ip4: and instead putting ip:

For example:

contoso.com IN TXT "v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip:9.10.11.12 –all"

Office 365 will cut you some slack and interpret an ip: as ip4:. Other services aren’t quite so forgiving and may generate a PermError.

6. Exceeding 255 characters in an SPF record

If you are going over 255 characters, it should be separated by a space and max of two components:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com <bunch of others> ip4:1.2.3.4" "ip4:5.6.7.8 –all"

If you go over 255 characters, I think most receivers will return a PermError but it varies by receiver.


7. Forgetting to include key parts of the record indicating that it is an SPF record

These are all incorrect:

contoso.com IN TXT "include:spf.protection.outlook.com ip4:1.2.3.4 –all"
contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4"
contoso.com IN TXT "include:spf.protection.outlook.com ip4:1.2.3.4"

The first one lacks v=spf1, the second does not have a failure policy, and the last one lacks both.

If you do this, most receivers will either return a PermError or will treat it as if there is no SPF record.

8. Having a failure policy of +all

It’s okay to have any of the following policies: -all, ~all, ?all. Don’t do +all:

contoso.com IN TXT "v=spf1 ip4:1.2.3.4 +all"

This allows the entire world to send email as you. I was talking to another (very) large receiver at MAAWG this past week and we’re talking about tightening up this behavior by rejecting in SMTP if you have a +all in your SPF record.

So don’t do it.

9. Having large IP ranges in your SPF record

IP ranges larger than /16 usually are wider than you need:

contoso.com IN TXT "v=spf1 ip4:1.0.0.0/2 –all"

That allows far too many IPs to send on your behalf. This is another pattern that I was talking about with the large receiver at MAAWG that we are looking to start rejecting in SMTP.

10. Including a PTR in your SPF record

This one… I am not so strict about:

contoso.com IN TXT "v=spf1 ptr ptr:contoso.com –all"

The SPF spec says not to do this and it is deprecated, but I can see the rationale for still using it. So while I recommend not to use it, I’m not so sure I’d want to reject on it.

Those are the most common errors that we see today, and how they are treated. As I think of or discover more, I will add to the list.

To test SPF records, I use the following two websites:

SPF Record Testing Tools:
http://www.kitterman.com/spf/validate.html

DMARCIAN’s SPF Surveyer
https://dmarcian.com/spf-survey/

Other than some Perl and shell scripts I wrote internally, that’s all I basically use.

Exchange Online Protection (EOP), the email filtering component of Office 365, is rolling out, or has already rolled out, full antispoof protection for all of its customers. Most of our customers already have this protection, and now we are preparing to roll it out to everyone else.


What is the spoofing problem EOP is solving?

Over the past several months, EOP (along with the rest of the industry) has seen a massive increase in targeted spear phishing attacks where the attacker spoofs an employee high up in the organization such as the CEO, and emails another high ranking employee such as the CFO, asking them to perform a wire transfer, or similar behavior. There are no attachments or links in the message, only regular language instructions asking the target to comply with the demands.

For example:

---

From: Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
To: Tom Amtir (the CFO) <tom@woodgrovebank.com>
Subject: Can you make this wire transfer for me?

Tom, we just closed on an acquisition of a new service but we’re trying to keep it quiet. Could you wire over $50,000 to them? The account number is below and we need to get this taken care of today.

Thanks.

Rudy

Sent from Outlook for iPhone

---

These types of messages are sent in low volume, and contain language that is grammatically correct without spelling errors, but are fraudulent. They also can cause a lot of financial damage to an organization if the targeted recipient is not aware that the message is malicious.

EOP already has antispoofing technology including SPF, DKIM, and DMARC [1]. However, many organizations don’t have either the expertise or resources needed to set these up or maintain them. Yet, they still need antispoofing protection – these types of messages must be detected and users protected even if you don’t have the required authentication records published.

This Exact DomainSpear Phishing Protection (name subject to change) is the new feature that EOP has rolled out for many of its existing customers, and will roll out for the rest over the next few weeks – the detection of spoofing for your domain even without the standard SPF, DKIM, or DMARC records.

You don’t have to do anything to receive this protection, you get it for free automatically. Furthermore, you can customize it to make it more or less strict by permitting others to send on your behalf.
 

How is EOP solving it?

First, EOP checks to see if the message is destined to your organization and comes from any of your provisioned domains, or a subdomain of any of your provisioned domains. For example, any of these may be potential spoofs:

From: Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
To: Tom Amtir (the CFO) <tom@woodgrovebank.com>

From: Rudy Bosive (the CEO) <rudy@foo.woodgrovebank.com>
To: Tom Amtir (the CFO) <tom@woodgrovebank.com>

From: Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
To: Tom Amtir (the CFO) <tom@bar.woodgrovebank.com>

From: Rudy Bosive (the CEO) <rudy@foo.woodgrovebank.com>
To: Tom Amtir (the CFO) <tom@bar.woodgrovebank.com>

If the From and To domains align, EOP checks to see if the message is legitimate. Is it a message that originated internally within the organization? That’s okay. Are they authorized to send email on your behalf? That’s also okay. Is it a known good bulk sender? That’s okay. EOP also uses the sending domain reputation (or lack of reputation), sending IP reputation, recipient reputation (how many messages do you receive from this sender? how is your email routed through the EOP service?), and also makes use of machine learning.

EOP uses of all of this data to make sure that the service marks malicious email as spoofs, and not any legitimate email.

How to tell if EOP thinks a message is a spoof

When EOP thinks a message “from” your domain to any of your domains is a spoof, it marks it as spam and adds the following header:

X-Microsoft-Antispam: …;SFTY:9.5

The X-Microsoft-Antispam header is already used by EOP to indicate various other spam filtering components. The SFTY:9.5 refers to the Safety Level of a message. This header property has other values but are reserved for internal use by EOP.

You can double check this by looking at the From: address and the To: address. Both domains will be the same, subdomains of each other, or part of your Accepted-Domains.

By the end of the second quarter of 2016, EOP will start adding Safety Tips to the message. Safety Tips are visual indicators letting you know that the message is fraudulent or may be a phishing scam. These Safety Tips are viewable when using Outlook on the web to view your email.

How can you exclude certain senders from being marked as spam?

Even though EOP attempts to exclude all legitimate senders from being marked as spam, it is possible that the service does not have enough history to make that determination.  This can happen if a new sender starts sending email as you, or the volume of email is too small to generate a positive reputation, or the sender comes a set of IPs that are known to send spam or phish. EOP does self-correct in cases where it has enough data to make a decision, but other corner cases may continue to be marked as spam.

To eliminate the chance of false positives, we recommend administrators use one of the following four options to exclude senders from being marked spam by our antispoofing filter:

1. Add the sender’s IP addresses to your SPF record, or have them authenticate with DKIM
   
   You can use either SPF or DKIM to have a 3rd party send email on your behalf (see note [2] at the end of this blog post for examples).
   
   Whichever method you choose, or ideally picking both methods, this will allow EOP to authenticate emails from these 3rd party services sending as your domain to your domain.
   
   However, it also allows others (for example, Yahoo, Gmail, Comcast, and so forth) to verify email to them sending as you. This is beneficial because it allows your customers to build trust with your domain no matter where their mailbox is located, and at the same time EOP will not mark a message a spam due to spoofing because it passes authentication of your domain.
   
   Advanced users: For more information on getting SPF records to work around the 10 DNS lookup limit, and automating your SPF records, see the blog post Email authentication should work out of the box and we should not rely upon domain owners to do it themselves.
   
   
2. Use the spoof policy in Powershell or UX in the Exchange Admin Center to exclude the sending IP address from Antispoofing enforcement
   
   This functionality is not yet available as of Feb 22, 2016 but will be released by the end of Q2 2016.
   
   Alternatively, if you want to permit various senders to send email on your behalf to your domain (but still undergo spam filtering), you can explicitly set this up.
   
   To allow a specific IP address to send email as your domain to your domains using Powershell:
   
   a) Connect to Exchange Online using Powershell
   
   b) Download the spoofed senders list, as above, with either basic or detailed view.
   
   Get-PhishFilterPolicy –SpoofAllowBlockList | Export-CSV "SpoofingSenders.csv"
   
   Or
   
   Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed | Export-CSV "SpoofingSenders.csv"
   
   
   c) Open up your favorite text editor (such as Notepad or Notepad++) and look for the IPs you want to specify overrides and type either Yes or No in the Allowed to Spoof column.
   
   - Specifying ‘Yes’ in the Standard view will allow all detected sender addresses from that IP address to send as your domain. Specifying ‘No’ will prevent it (that is, if EOP may believe it is a good sender but you can override it). Future sender addresses detected by the phish filter may or may not be blocked or allowed
   
   - Specifying ‘Yes’ or ‘No’ in the Detailed view will allow or block the detected sender address from the true sender sender spoofing your domain.
   
   - If there are spoofing senders you would like to proactively allow or block that do not currently appear in the Detailed view, you can specify the “True Sender”, “Spoofed Sender”, and the “Allowed to Spoof” verdict.
   
   Save the file with a new name UpdatedSpoofingSenders.csv.
   
   d) Update the changes you made in the "Allowed to Spoof" column by running the following two commands in this order:
   
   $UpdatedSpoofingSenders=Get-Content -Raw UpdatedSpoofingSenders.csv
   
   Set-PhishFilterPolicy –SpoofAllowBlockList $UpdatedSpoofingSenders
   
   Senders who you did not allow will be blocked.
   
   e) To verify your changes:
   
   Get-PhishFilterPolicy –SpoofAllowBlockList
   
   Or
   
   Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed
   
   Integration with the Office 365 Admin Portal is not available at this time, but will be later on in 2016. When that occurs, this blog post will be updated.
   
   Bonus: Office 365 is planning to give you insights into Intelligence Data. This encompasses a whole range of signals from our various platforms. These spoofing senders – many of whom are malicious – will in this Intelligence Data set. It is not the only set of signals we will provide, but is an important one. This Intelligence Data will be available later this year (2016).
   
   
3. Add the sender’s IP address to an IP Allow List in the Exchange Admin Center
   
   Alternatively, if you don’t want to add the sender’s IP addresses to your SPF record but also don’t want email to be marked as spam due to spoofing, you can add the IP or IPs to your IP Allow List. This will skip any spam filtering from these IP addresses and mark the message as SCL –1, which delivers the message to your inbox unless an Exchange Transport Rule (ETR) deletes or quarantines the message.
   
   If a message bypasses filtering due to an IP Allow list entry, you will see the following properties inserted into a header in the message:
   
   X-Forefront-Antispam-Report: IPV:CAL;…SFV:SKN;…SCL:-1
   
   The IPV:CAL means “IP Filtering Verdict: Customer Allow List”.
   
   For more information on managing IP Allow lists, see Configuring the connection filter policy in EOP.
   
   
4. Add the sender’s IP addresses plus sending domain to an Exchange Transport Rule (ETR) which bypasses filtering
   
   Alternatively, if you don’t want to skip filtering on all email from a specific set of IP addresses into your organization because those IPs are shared by more than just your domain, you can create an ETR. The ETR should look for a combination of sending IP addresses and a sending domain. You should never create an ETR that only looks for your domain because this can be easily exploited by spammers.
   
   The ETR syntax should be:
   
   

   ---

   Name: Antispoofing Allow rule to bypass filtering
   
   If the message…
   sender ip addresses belong to one of these ranges: ‘1.2.3.0/24’
   and sender’s address domain portion belongs to any of these domains: ‘contoso.com’
   
   Do the following…
   Set the spam confidence level (SCL) to ‘-1’
   and set the header ‘X-ETR’ with the value ‘Antispoofing allow rule set SCL –1’  

   ---

     
   You can add as many IP addresses as you want to the rule, you can add other domains to protect, you can modify the text of the header to stamp to make it more descriptive, and you can even specify Exceptions to the rule. 
   
   The result is that email from these IP ranges sending email as your domain will bypass spam filtering and get delivered to your users’ inboxes except if the user has the sender on their personal Blocked Sender list, and there are not other ETRs running at higher priority than this rule that take action on the message (for example, a rule that sends email to the Admin Quarantine).
   
   If a message bypasses filtering due to an ETR like the above, you will see the following header inserted into the message:
   
   X-Forefront-Antispam-Report: SFV:SKN;…SCL:-1
   X-ETR: Antispoofing allow rule set SCL -1
   
   For more information on ETRs, see Managing Transport Rules.
   
   Once the Allow/Block functionality above is released, you don’t need to do this ETR and instead should use that.
   
   Remember – is important to never, ever allow only your domain in an ETR by itself with no other criteria. If you do, a spammer can spoof your domain and it will get a free pass to the inbox.

Can antispoofing protection be turned off?

No, antispoofing protection cannot be disabled.

Instead, if you get false positives, you should use any of the workarounds above to bypass filtering for these senders. This ensures that rather than leaving you exposed to phishing messages, you instead block the most dangerous types of spoofs and allow in only authorized senders.

EOP has done a great job at minimizing potential false positives and so this change will cause minimal disruption to legitimate mailflow.


Is there anything else I should know about?

Yes.

1. In order to get full antispoofing protection, your domain’s MX record must point to EOP as its primary MX record. If it does not, antispoof protection will not be implemented for your domain.
   
   
2. Antispoof protection does not override IP Allow rules, ETR allow rules, or end user safe senders, all of which bypass spam filtering. This may change in the future.

Conclusion

These changes to EOP’s spam filtering will help protect your organization from some of the most malicious phishing messages that we see today. The feature is intended to minimize any false positives while also giving you the ability override the filter decisions when necessary.

As always, let us know how it works for you so we can continue to improve it!

Footnotes

[1] EOP supports DMARC for inbound email, which is a technology to stop spoofing of the From: domain. The main difference between DMARC and EOP’s Antispoofing solution is that DMARC requires certain DNS records to be published, whereas EOP’s Antispoofing solution does not. The second difference is that DMARC sends failure reports back to the forensic and aggregate reporting email addresses, whereas for EOP’s Antispoofing that information is only available via Powershell or through the Exchange Admin Center.

For more information, see these blog posts:

• Using DMARC in Office 365
• Best practices for Exchange Online customers to align with DMARC
• What is the best combination for your SPF, DKIM, and DMARC record?

[2] For setting up 3rd party services to send on your behalf (as your domain) and have it authenticate using the regular antispam authentication methods:

a) SPF Authentication

If you are sending from an on-premise mail server, or a cloud-hosted service, and you have a dedicated IP address, you should add them to your SPF record. For example, before updating your SPF record, it might look like this:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com –all"

After adding the dedicated IP address (or CIDR address range), your SPF record might look like this:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 –all"

If you are using a larger service like a bulk email service provider or software-as-a-service provider, they may ask you to include all of their servers which is much more manageable:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 include:bulkEmailProvider.com –all"

If you do this, your email that sends as you from this service will now authenticate with SPF.

For more information:

• Customize an SPF record to validate outbound email sent from your domain in Office 365
• Common errors in SPF records
  

b) DKIM authentication

Some bulk email service providers, or software-as-a-service providers, let you set up DKIM keys for email originating out of their service. This requires co-ordination between yourself and them to set up the necessary DNS records, and it is dependent on the organization. This is also a useful method for email authentication.
The message might look like the following:

Return-Path: <communication@bulkemailprovider.com>
From: <sender@contoso.com>
DKIM-Signature: s=s1024; d=contoso.com
Subject: Here is a message from Bulk Email Provider’s infrastructure, but with a DKIM signature authorized by contoso.com

In this example, Bulk Email Provider gave Contoso a public DKIM key to publish in their DNS record, and then signs with the corresponding private key when sending email and putting the resultant DKIM signature into the message. Third parties can then authenticate against the DKIM d= domain and compare it to the domain in the From: address.

For more information:

• Manually hooking up DKIM signing in Office 365
• What is DKIM?
  

* * * * * *

With either SPF or DKIM, when sending to EOP, a header is inserted into the message with the authentication results, and either the smtp.mailfrom or the header.d should match the domain in the header.from. In this case, contoso.com in the header.d in the DKIM-Signature header aligns with the domain in the From: address. In the absence of a DMARC record, EOP stamps dmarc=bestguesspass.

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
  smtp.mailfrom=bulkemailprovider.com; contoso.com; dkim=pass 
  (signature was verified) header.d=contoso.com; dmarc=bestguesspass 
  action=none header.from=contoso.com;