# Exchange Online Protection (EOP) Best Practices and Recommendations

•
•
•
•
•
•

Yes. I said it.

Someone needed to put a line in the sand and today, that person is me.  I’m going to say these are some best practices.

But of course, your mileage may vary, depending on your type of organization (users at a local bank or city government will have different threats presented to them than an engineering firm with international customers, for example).  Though I work for Microsoft, these may not necessarily be Microsoft’s best practices.  Having migrated hundreds of thousands of mailboxes to the cloud for hundreds of customers over the last 7 years, though, I feel moderately confident that not all of our support engineers would take umbrage with them.  Which, if you know support engineers, says a lot.

While there is no one-size-fits-all prescriptive guidance from end-to-end, there are still a number of settings and configurations that every organization can use to improve their security posture–and all of the settings merit at least looking at to see if they would be of benefit to your organization.

We’ve also published some of these recommendations on our public documentation, available at: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/recommended-settings-for-eop-and-office365-atp

# Introduction

Exchange Online Protection (EOP) is the standard signature-based antivirus and antimalware engine that comes with an Office 365 subscription.  It is also available as a standalone service for customers who are have deployed on-premises mail solutions.  Advanced Threat Protection (ATP), a behavior-based heuristic threat protection service, can be added as an integrated or purchased as a standalone service as well.

# Background

Before we get into the details on how best to configure Exchange Online Protection and recommendations, I think it would be beneficial to discuss how email works under the hood.  The defining protocol for electronic mail communication is the Simple Mail Transfer Protocol, or SMTP.  Originally released as an internet standard in 1982, RFC 821 described the mechanisms that would reshape communication as we know it. Like all protocols and specifications, the technical details and capabilities of SMTP continue to be expanded and refined.  RFC 821 has had features both deprecated and added, and has continued to evolve for nearly 30 years.

SMTP is the digital evolution of something familiar to us: postal mail.  SMTP nomenclature features a lot of words that originate in our traditional vernacular, such as mailbox, gateway, envelope, sender, recipient, and address. Two very important ones that we’ll be talking about later, when it comes to email validation, authentication, and the handling of bulk, spam, spoof, and phishing emails, are the Sender and Recipient Headers.

Using postal mail as an example, imagine you are sending a letter.  When you create this letter, you’ll undoubtedly address it to someone (for example, “Dear Elvis,”), and when you’re done, you’re going to sign it, (“your biggest fan, Aaron”).  These are the RFC 5322 RCPT (recipient) and FROM (duh) fields.

Then, you’re going to take that letter, fold it up neatly, and put it inside an envelope. On the outside of the envelope, you address it to “The Elvis Lives Fan Club,” and you write your return address in the upper-left hand corner of the envelope.  Then, rethinking how you handle disappointment, you decide you don’t want to get replies sent to you personally, because you don’t want to actually know if your letter makes it to the Great Valley.  You erase your return address and write in the address of your mother. She’ll know how to break the bad news to you should the need arise.  These are the RFC 5321 RCPTTO (recipient) and MAILFROM fields.

Just as you can put any From address on the envelope, the same applies to SMTP.  This is where some sort of authentication and validation becomes extraordinarily important.

Some of the interchangeable terms you might hear:

 Field or Header Common Names RFC FROM P2 Sender 5322 RCPT P2 Recipient 5322 MAILFROM P1 Sender, Return-Path, Envelope Sender 5321 RCPTTO P1 Recipient, Envelope Recipient 5321

If you really want to dig in and learn more about SMTP structure and workings, head over to the IETF and look up RFC 2822, as well as the updates to it and related documents, such as 5322, 5335, and 5336, and 6531.

On to the good stuff!

# Mail Hosting Scenarios

Office 365 and Exchange Online support three core email hosting scenarios: fully hosted, standalone, and hybrid.

• Fully hosted – All mailboxes are hosted in Exchange Online
• Standalone – All mailboxes are hosted on-premises (Exchange or otherwise) or another external hosting service
• Hybrid – Some mailboxes are hosted in Exchange Online and others are hosted on-premises

In whatever situation you find yourself, the configuration recommendations are going to point to using Exchange Online Protection as your primary ingress point for email, since you’ll get the most benefit from the service that way.

# Domains

Exchange Online uses domains, like contoso.com, to route email messages and manage messaging options. Most customers choose to use their own domains with Exchange Online and Office 365.  While the overall ownership and settings for the domains are managed with a domain registrar or DNS hosting provider, they need to be added to Office 365 so that they are available for use in the service.

When you add a domain for use in Office 365, you’re asked to prove ownership of it, which is typically done by inserting a record into your public DNS. After it’s been added and verified for use in Office 365, it gets added to Exchange Online as an accepted domain.  Accepted domains in Exchange Online, much like Exchange Server, are used to determine which domains you have the authority to answer and accept mail for.

Exchange Online and Exchange Online Protection also have the concept of remote domains.  These are domains external to your Office 365 or Exchange Online Protection environment, but for which you want to manage some settings.  For example, you may want to disable out-of-office messages, disable non-delivery reports, or manage the message format settings for a particular domain.

2. Go to the Setup | Domains page.
4. Enter the name of the domain you want to add, then click Next.
5. Choose a method for how you want to verify that you own the domain.
1. If your domain is registered and DNS hosted at GoDaddy, 1&1, or one of our other supported registrars, you can choose to allow Office 365 to configure the records automatically.  Click Sign in | Next, provide your registrar credentials, and Office 365 will set up your records automatically.
2. You can also have an email sent to the registered administrative contact for the domain with a verification code. This probably isn’t the best choice if you don’t have access to the email account listed at the registrar.  If you have access to the registrar, you can update the WHOIS information, and then come back and try that option after the WHOIS database gets update.
3. You can use a TXT or MX record to verify your domain. Most organizations select this option, and then use the TXT record method to verify ownership, as they are less intrusive.  Select this option, and then and click Next to see instructions for how to add this DNS record.  This can take up to 30 minutes to verify, so it might be a good time to run to the cafeteria for a donut or some kale chips.  Just kidding.  No one eats kale chips as a first choice.
6. Choose how you want to make the DNS changes required for Office to use your domain.
1. Select Add the DNS records for me if you want Office to configure your DNS (See our list of supported registrars–your domain must be registered AND have its DNS hosted there.  If your domain is registered at one of these registrars but you host your own DNS, you’ll have to choose the option to manually add the DNS records yourself).
2. Select I’ll add the DNS records myself.
3. If you chose to add DNS records yourself , click Next and you’ll see a page with all the records that you need to add to your registrars website to set up your domain.  You may not need to configure all of the records for all the domains initially (such as Autodiscover, if you’re going to configure Exchange hybrid).  At this point, the only thing that you need to do is add the TXT record to prove you own the domain.
7. If you’ve added the records manually, you may need to wait and come back to click the Verify button.  You can safely click Skip this step, and then come back to Setup | Domains to verify domains later.

All done!  For more information on Domains in Office 365, see Domains.

## Directory-based Edge Blocking

When you add a domain to Office 365, it’s automatically added as an accepted domain in Exchange Online.  When it’s added, the domain type is set to Authoritative, meaning that if an entry doesn’t exist in the Global Address List (GAL) for an email address (user, group, public folder, or other recipient), then it doesn’t exist.  The GAL becomes the authoritative list of all the addresses available in the domain.

Directory-based Edge Blocking (DBEB, since we have an acronym for literally everything) takes this concept and applies it to the inbound edge with Exchange Online Protection.  It uses the Global Address List as a perimeter filter.  There are times, though, when this behavior may not be desirable–especially if you have a hybrid Exchange environment or other connected mail environments where all of your protected recipients aren’t synchornized or populated inside of Exchange Online’s directory.  For those times, you may need to disable DBEB.

### Disable or enable DBEB

Depending on if your recipients exist in Exchange Online, you may need to enable or disable DBEB.

2. Go to Mail flow | Accepted domains.
3. Select the domain and click Edit.
4. Select the domain type.
1. Set to Internal relay to disable DBEB.
2. Set to Authoritative to enable DBEB.
5. Click Save.

For more information on Directory-based Edge Blocking, see Use Directory-based Edge Blocking to reject messages sent to invalid recipients.

## Recommendations

1. We recommend adding and verifying all of the domains that you will use for email or sign-in identity to Office 365.  An exact domain match can only be verified in one tenant at a time.  You can, however, verify child domains in different tenants (for example, contoso.com may be in one tenant, but you need your subsidiary sub1.contoso.com in a separate tenant for political or legal reasons).  Exchange Online will honor MX-based routing decisions.
2. Once a domain is verified in Office 365 and added as an accepted domain in Exchange Online, it is automatically configured for Directory-based Edge Blocking.  To take advantage of edge filtering, ensure all recipients are configured in Exchange Online and enable DBEB.
3. If you work with partner organizations that use messaging systems that support limited content formats or don’t want to deliver certain system messages to them (such as out-of-office replies or non-delivery reports), consider setting up a Remote Domain.  For more information on remote domains, see Manage remote domains in Exchange Online.

# DNS

Four DNS records control how external entities see and interact with your organization: MX, SPF, DKIM, and DMARC.  If you’re new to DNS, I’d recommend that stop right now, go read up on our DNS basics cheat sheet, and then come back here. It will make your life better.

Office 365 has built-in anti-spoofing (pretending to be someone you’re not) protections designed to detect legitimate cases of spoofing while protecting your email environment from the illegitimate ones.  In the world of postal mail, you could equate spoofing to writing someone else’s address in the return address spot on the envelope, in hopes that whoever you sent it to would believe that the “fake” sender you put in the return address spot was the actual sender.  Spoofing can sometimes be seen as a way to try to add credibility or legitimacy to mail.

The DNS records we’re going to discuss, in regards to spoof and spam intelligence protections, have to do with protecting recipients from emails purporting to be from you.

Mail Exchanger, Sender Policy Framework, DomainKeys Identified Mail, and DMARC are those pieces.  These are there stories.

Let me say that again for those in the back:

The DNS records (SPF, DKIM, DMARC) we’re going to discuss have to do with protecting recipients from people pretending to be you.

Configuring an SPF record for your domain does not improve your own environment’s spam detection and catch rates.  Configuring SPF alone does not reduce the amount of spam you receive.

Configuring DKIM for your domain does not improve your own environment’s spam detection and catch rates.  Configuring DKIM alone does not reduce the amount of impersonated or otherwise illegitimate mail you receive.

Configuring DMARC for your domain does not improve your own environment’s spam detection and catch rates.  Configuring DMARC alone does not reduce the amount of impersonated or otherwise illegitimate mail you receive.

These measures are about telling other organizations who or what can legitimately send mail as you.  They are critically important to the proper and efficient workings of the internet and the global efforts to reduce spam, so please do your part.

It takes a village to reduce spam, but all it takes is one village idiot to mess it up for everyone.

## MX Record

A Mail Exchanger (MX) record is a DNS resource record designed to tell mail relay servers where to send email, similar to a postal address.  An MX record has three pieces of information: a hostname (the address), a priority or weight, and a time-to-live (how long the record is allowed to be cached by a system).

A stroll down memory lane …

In the dark ages of the Internet (November 1983, to be more precise), there were three records and a query type that defined how mail would flow and be delivered: the mail destination (MD) record, mail forwarder (MF) record, and mail agent (MAILA) query.  These were specified by the (now obsolete) RFC 833.  There were several record and query types specified in this RFC.  At 73 pages, it’s a lengthy read for not much info, but that’s what standards typically are.

The MAILA query type was designed to return the mail records for a domain–a mail destination (the eventual mailbox server) as well as mail relays (or mail forwarders) that could be expected to receive or queue mail for the recipient.

The nitty gritty comes down to this:

Let’s say the recipient is aaron@contoso.com.  A sending message transfer agent (MTA) would perform a MAILA DNS query (like, NSLOOKUP -QTYPE=MAILA -QNAME=contoso.com–don’t try this, the record query is deprecated), which might return something like this:

contoso.com MD IN mailhost.contoso.com
contoso.com MF IN relay.contoso.com

The interpretation is this: mailhost.contoso.com would be the best bet to deliver the mail, as it’s listed in the MD record, but relay.contoso.com could accept it and forward it on.

These records were deprecated in 1986 in favor of the simpler MX record, introduced in RFC 973.  The MX Record is simply a hostname of a recipient that can accept mail on a domain’s behalf combined with a priority or weight, and a time-to-live (expiration).  The mail host designated in the MX record will either:

• Accept the mail on the domain’s behalf and either relay it to another stop along the way or deliver it directly to the mailbox (if it is responsible for handling the actual mailbox)
• Reject the mail permanently (permission denied, mailbox full, etc)
• Reject or delay the mail temporarily (such as greylisting or unresponsive destination server)

A domain can have multiple MX records for load-balancing, backup, and distribution. For example, if a domain has a single MX record, regardless of the weight or priority, all traffic will get sent to that host:

Domain: fabrikam.com
Hostname: mail.fabrikam.com
Priority: 0
TTL: 1 hour

This record would indicate that the hostname mail.fabrikam.com would be solely responsible for receiving traffic on behalf of fabrikam.com.  When you introduce the concepts of multiple MX records and weight or priority, all equally-weighted records are returned in a round-robin fashion (one per query), and then if the queried record does not respond, the sending mail server fails to the next lowest in priority.

### MX Configuration and EOP Functionality

In regards to mail flow, if you are using Exchange Online Protection as part of your spam filtering solution, we recommend that EOP is on the edge, receiving email for your organization.  This means setting your MX record to the settings recommended in the Office 365 Admin Center (typically, domain-com.mail.protection.outlook.com).  There are a number of reasons we recommend this.

#### IP Reputation

Many of Exchange Online Protection’s spam policies rely on IP reputation checks.  As mail is processed on the internet (by us and other providers), information regarding spam and phishing messages is gathered and aggregated into a number of databases (both public and private). These databases contain addresses of systems known or likely to send spam.  Depending on the literature you read, these databases and services might be referred to a Domain Name System Block Lists (DNSBL), Real-Time Block Lists (RBL), black lists, or black hole lists. Those (and other ominous terms) typically indicate some sort of automated or curated lists of known and suspected spammers or junk mail senders.

If EOP is the second or third hop after another mail filtering solution (whether it’s on-premises or hosted somewhere else), we are making blacklist determinations based on the IP address of the MTA handing off to EOP, and not the original sender.  You are reducing the efficacy of EOP, and will instead need to rely on the IP reputation-based filtering settings on the edge MTA or third-party service acting as the first hop.

#### IP Throttling

Way back in 2014, we introduced IP throttling into Exchange Online Protection.  Our IP throttling is a form of greylisting, a reputation-based function designed to delay messages from systems for which there isn’t enough information yet to understand if they are legitimate or not.  When EOP receives a message from an unknown originating MTA, it issues a 450-level status response (451 5.7.500-699 (ASxxx) Please try again later), instructing the sending server to try again later.  Most legitimate systems will retry according to their queue settings; many spam-type systems won’t retry and will just move on to the next recipient or host.

If EOP is not the MX recipient for your domain, IP throttling and greylisting don’t work as designed, as they will be receiving mail from either your on-premises (trusted) environment or third-party (also presumably trusted) environment, and you don’t want to delay those.

#### DNS Record Checks

Exchange Online Protection also makes use of various DNS mechanisms later described (SPF, DKIM, DMARC) to determine the legitimacy of email.  If an on-premises or third-party system modifies the message in transit before EOP has a chance to verify those records, the results may end up being invalid.

#### IP Allow and Block Lists

Like other mail filtering systems, Exchange Online Protection provides mechanisms to block or allow traffic from certain IP addresses.  These policies do not work if your MX record is pointing to an on-premises or third-party gateway in front of or instead of EOP.  For maximum functionality of IP allow and block lists, EOP should be configured as your MX host.  Otherwise, you will need to configure IP allow and block lists in the external systems.  Note: If you have Exchange Transport Rules (ETRs) or spam rules that also rely on IP addresses or PTR lookups, they may not work correctly if Exchange Online Protection is not configured to be your MX host.

#### Enhanced IP Filtering for Connectors

[Updated 9/5/2019]

Every rule has exceptions, and EOP is no different.  We have begun rolling out a feature called Enhanced IP Filtering for Connectors which is designed to analyze an email header and evaluate whether or not we should base our decisions on the second-to-last-hop IP address.  This is specifically designed for scenarios where you have implemented a connector from another smarthost (such as a third-party filtering solution) that is trusted, and you want to base your spam scoring decisions on that previous address, not the address from your gateway.

For more information on this new feature, see https://docs.microsoft.com/en-us/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors.  The availability of this feature does not change the overall recommendations of the service, as it is still best to simplify the mail flow as much as possible. You will still see the biggest benefit from the service when your MX record is pointed to EOP directly.

### Recommendations

As you’ve seen, Exchange Online Protection makes use of many IP-based features which require it to be configured as the receiving MX host for your organization.  While it is possible to use other services in front of Exchange Online Protection, we can’t provide support on it, and you’ll be reducing the efficacy of the solution.  As such, we recommend that you configure EOP as your primary filtering solution.

1. Use Exchange Online Protection as your primary filtering solution by updating your external DNS MX record to point to the value specified in your Office 365 Admin Center (typically domain-tld.mail.protection.outlook.com).
2. Don’t use backup or lower-priority MX records that point to third-party or on-premises mail systems.  Spammers and bulk mail senders typically look for lower-priority MX records in an effort to bypass primary filtering systems, since the configurations are likely not the same.
3. For hybrid Exchange deployments, update your MX record to point to Exchange Online Protection.  The TLS inbound and outbound connectors between your on-premises environment will allow mail to be transferred to mailboxes hosted both in-cloud and on-premises.

For further information on configuring mail flow for Office 365, see Mail flow best practices for Exchange Online and Office 365.

## Sender Policy Framework (SPF)

The Sender Policy Framework authentication mechanism has its roots way back in 2000. It underwent a few proposals, but eventually emerged as a draft in 2003, and after some hemming and hawing, made its way to Experimental IETF status in 2005, and then published as an Experimental RFC 4408.  In 2014, SPF’s standing was further upgraded to Proposed Standard as part of RFC 7208.

Our detailed documentation for setting up SPF is located here, but I’ll consolidate and hopefully simplify it for you below.

SPF is configured via a TXT record in your organization’s external DNS for a particular domain. You can think of an SPF record as a list of hosts (names, IP addresses, or names and IP addresses listed inside another SPF record) that are allowed to send mail on the domain’s behalf.

An SPF record has 2 parts: the version information and the mechanisms (of which there are 8). We’ll use Microsoft’s SPF record as an example.  Take a look at it below:

"v=spf1 include:_spf-a.microsoft.com
include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com
include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153
ip4:147.243.1.47 ip4:147.243.1.48 -all"

In the example, v=spf1 is the version identifier information, and the rest of the record are the mechanisms. Valid mechanisms are:

 ALL Matches always; used for a default result like -all for all IPs not matched by prior mechanisms. A If the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match. IP4 If the sender is in a given IPv4 address range, match. IP6 If the sender is in a given IPv6 address range, match. MX If the domain name has an MX record resolving to the sender’s address, it will match (i.e. the mail comes from one of the domain’s incoming mail servers). PTR If the domain name (PTR record) for the client’s address is in the given domain and that domain name resolves to the client’s address (forward-confirmed reverse DNS), match. This mechanism is discouraged and should be avoided, if possible, per the note in RFC 7208 Section 5.5.  The name of the section is even called “ptr (do not use),” so that gives you an idea of how the IETF feels about it. EXISTS If the given domain name resolves to any address, match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like DNSBL-queries. INCLUDE References the policy of another domain. If that domain’s policy passes, this mechanism passes. However, if the included policy fails, processing continues. To fully delegate to another domain’s policy, the redirect extension must be used.

In addition to mechanisms, there are also 4 qualifiers:

• + (plus) for a PASS result. This can be omitted; e.g., +mx is the same as mx.
• ? (question mark) for a NEUTRAL result; interpreted like NONE (no policy).
• ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
• - (minus) for FAIL; the mail should be rejected.

So, when examining the Microsoft record, you’ll see that we use 3 of the mechanisms.  We use INCLUDE to designate which additional SPF records we’d like ours to reference, we use IP4 to match individual host IP addresses or ranges of IPs that may not have a DNS record specified, and we use the ALL mechanism with the (minus) qualifier to instruct recipient systems on how interpret senders claiming to send on behalf of microsoft.com: “the addresses listed in the INCLUDE and IP4 statements are authoritative, and we’re sure of it. For real.”

Frequently, when organizations first start configuring SPF records, they may be unsure of all of the hosts that are sending mail on their behalf, so they may choose to use the ~ qualifier with the ALL mechanism, which would instruct the receiving host to check for SPF, but not reject it if it doesn’t match.  Some spam filtering gateways do have options (non-RFC, mind you) to treat ~ as -.  Once you are certain that you have accounted for all your hosts, we recommend you implement the ALL mechanism with the – qualifier.

When you are looking at email headers, SPF records are validating the P1 or envelope header (the address specified when the SMTP MAIL FROM command is used, per RFC 5321).  From the header’s perspective, this is seen as Return-Path.

### Recommendations

1. Verify all of the hosts (IP address, hostnames, third-party services, web servers, etc.) that are sending mail on your behalf.
2. Implement an SPF record that includes those hosts, as well as the recommended Exchange Online Protection SPF record inclusion (include:spf.protection.outlook.com).
3. Use the ALL mechanism with the – qualifier.  DO NOT USE THE qualifier with ALL, as that is effectively treating all senders as authorized for your domain (seriously, why even HAVE an SPF record at that point).  If you use the qualifier, you lose automatically. Do not pass GO. Do not collect 200. 4. Do not implement more than one SPF TXT record. This is strictly against the RFC, as stated in Section 3: The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource record; multiple SPF records are not permitted for the same owner name. For more information, see How Office 365 uses Sender Policy Framework (SPF) to prevent spoofing. ## DomainKeys Identified Mail (DKIM) DomainKeys Identified Mail (DKIMl) is another authentication mechanism designed to detect spoofing, a technique commonly used in phishing and spam messages make the recipient believe the sender is someone different than they actually are. DKIM is a form of public key cryptography. Public key cryptography is a mechanism built from two keys (a public key, which is widely distributed and known) and a private key (which only the sender/content creator has access to). The content creator signs (or creates a crytographic hash) of selected content with their private key. A recipient or viewer of the content can access the sender’s public key, apply it to the signed or hashed content, and decrypt it and verify its content and source. PKI is kind of like a fingerprint or old-timey wax seal in that way–it provides non-repudiation, meaning that only the person with this particular private key can generate a hash that can be decoded by this public key. With DKIM, a sender (usually the sender’s email system, as it’s typically invisible to the end user) affixes a cryptographic signature of selected hashed content or fields in the header of an email message (for example, the From or Body parts may be hashed). This signature, as with all public key cryptography, is generated with the sender’s private key. The recipient system is able to look up that value against the public key denoted in the domain’s DKIM selector DNS record. This ensures that the system sending the mail was indeed cryptographically configured to send it, as a form of non-repudiation (as in, you can prove that an email originated from a given domain and sending infrastructure). DKIM supports multiple keys through the implementation of a tag mechanism called a selector. This allows for generating a specific selector/key-pair match for different sending systems. For example, you may configure your internal system to use selector1/key-pair A, and you may have a third-party mailing list service that is configured to use selector2/key-pair B. In so doing, you are able to verify which system originated a message, and, should a key get compromised, be able to replace that key without affecting other keys in operation. The values the sender system has chosen to sign influences how further processing of the message could affect the DKIM signature. For example, if the body of the message was hashed and a relaying MTA appends something like Scanned with X-Ray Vision at the end of the message, the cryptographic hash for the body has changed, and when the recipient checks the DKIM signature, the message will fail validation. The DKIM signature tells us what fields or properties were used in computing the hash. The valid tags are: • v, version • a, signing algorithm • d, domain • s, selector • c, canonicalization algorithm(s) for header and body • q, default query method • t, signature timestamp • x, expire time • h, header fields – list of those that have been signed • bh, body hash • b, signature of headers and body Here is a sample DKIM signature I received: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7vkAPfWWmvsnxoy+A2hlBJnRCGgVb82S4PPbht4k1jk=; b=BSujkHHL57sLIznA0NfJjzNV0WDq/y1F8+cxCP8dp1GEqSJOJGOttfkKdWBtUK3KRQ wAuXtTDfmb8vEeVEKikmehO6wb9cQsq97lBN5h+M3rcWctMOiN80NEgiOMs7kutYXcpn VbhRbOK8jJNIrWuV6eyVuiMM5YT2eVeqAXzmaYkIzqPwc3mb2z8Xtbzy2/gaGQl/cIzN bEYootv00ISVh9at58YMiQiZJ36611qxX60Lfqz5oM/5r/jQDthPFVDWFId493sBz439 9j9/Oi2hHlUtvLwlxu1iiuUTwwJBsAbB7Xa7tmWpapruia+/d17T1zytSnPXtbB3NA2p bSAw== Examining the sample DKIM signature I received, we can see the following:  Tag Value/Function v Version: 1 a Algorithm: RSA-SHA256 c Canonicalization: relaxed (header), relaxed (body) d Domain: gmail.com s Selector: s20161025 h Header fields: subject, to, references, from, message-id, date, user-agent, mime-version, in-reply-to, content-language, and content-transfer-encoding bh Body hash: 7vkAPfWWmvsnxoy+A2hlBJnRCGgVb82S4PPbht4k1jk= b Body and header signature: BSujkHHL57sLIznA0NfJjzNV0WDq/y1F8+cxCP8dp1GEqSJOJGOttfkKdWBtUK3KRQ wAuXtTDfmb8vEeVEKikmehO6wb9cQsq97lBN5h+M3rcWctMOiN80NEgiOMs7kutYXcpn VbhRbOK8jJNIrWuV6eyVuiMM5YT2eVeqAXzmaYkIzqPwc3mb2z8Xtbzy2/gaGQl/cIzN bEYootv00ISVh9at58YMiQiZJ36611qxX60Lfqz5oM/5r/jQDthPFVDWFId493sBz439 9j9/Oi2hHlUtvLwlxu1iiuUTwwJBsAbB7Xa7tmWpapruia+/d17T1zytSnPXtbB3NA2p bSAw== When the destination MTA receives the message with a signature, it knows it needs to look up the selector 20161025 for the domain gmail.com. The selector DNS record structure is part of the RFC, so the receiving MTA will look up the text record 20161025._domainkey.gmail.com, for which the value is: "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWy AicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA +/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqRtqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/ CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFb VLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4L xUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB" This DKIM record has two tags:  Tag Value/Function k (key type) Type of algorithm used in public key (RSA, in this example) p (public key) MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhy tae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZ p6qDKJOwjJ5R/OpHamlRG+YRJQqRtqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et +c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf 0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxA EwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB Note: The actual string for gmail.com’s public key is broken into two TXT records, since it’s a 2048-bit key. I concatenated it here for readability. There are a few more tags available, though not all of them are widely used. The DKIM selector record is formatted much like the authentication signature–with key-value pairs:  Tag Value v Version. OPTIONAL, RECOMMENDED. The version of the DKIM record. The default is DKIM1. The verifiers perform a string comparison on this value, so DKIM1 is not the same as DKIM1.0. DKIM1 is currently the only valid value, but as the standard evolves, new tags and formats may be introduced. g Granularity. OPTIONAL. The default value is “*”. The intent of the tag is to character match the signing address and further restrict the usage of the signing key. h Acceptable Hash Algorithms. OPTIONAL. This field, if present, should contain a colon-separated list of algorithms that might be used. Signers AND verifiers MUST support sha256. Verifiers MUST support the sha1 algorithm as well. k Key Type. OPTIONAL. The default value is RSA. This field, if present, indicates the type of DER-encoded public key exists in the “p=” tag. Signers AND verifiers MUST support the “rsa” type. n Notes. OPTIONAL. Plain-text, human-readable notes. No verifier should use this field; it is meant for administrators. p Public-key data. REQUIRED. This value must be base64 encoded. A blank or empty value means the key has been revoked. s Service Type. OPTIONAL. The default value is “*”. The current valid potential value is email, though it could be expanded should DKIM be used for other services in the future. t Flags. OPTIONAL. The default is for no flags to be set. Valid flags include y, which indicates the domain is testing DKIM (verifiers MUST NOT treat messages flagged as testing differently from unsigned mail, even if the signature fails to verify; and s, which indicates a DKIM signature header field using the “i=” tag MUST have the same domain on the right-hand side of the @ value in the “i=” tag and the “d=” tag. Exchange Online establishes two keys for every customer and signs all outbound mail using these keys by default. To ensure alignment, it is recommend that the appropriate DNS entries be created for each custom domain. ### Recommendations The following configurations and steps will allow you to enable DKIM signing for each custom domain in your tenant. We recommend that you configure DKIM for every domain in your organization. Since the DKIM keys are configured and managed in the tenant’s initial domain namespace (tenant.onmicrosoft.com), you’ll be creating CNAME records in your DNS to point to the records in our DNS. #### Enable DKIM for each custom domain in your tenant 1. Connect to Exchange Online PowerShell. 2. Show the domains verified in the tenant and their DKIM configuration status: Get-DkimSigningConfig 3. For one of your custom domains (in my example, I’m going to configure o365ninja.com), run: Get-DkimSigningConfig -DomainName o365ninja.com | Select Domain,Selector* Note: If nothing is returned, you’ll need to run New-DkimSigningConfig -DomainName <domain> -Enabledfalse firstOffice 365 should generate the DKIM selector public keys automatically, however.
4. Highlight and copy the Selector1CNAME value. We’re going to use this in a minute.
6. Once you’re in the spot to manage it, you’ll want to Add a record.  We’re going to select CNAME as the type, and then use the values from the Get-DkimSigningConfig to populate it.

Host: selector1._domainkey (since we’re in the o365ninja.com DNS zone, I don’t specify that part)
Points to: value in Selector1CNAME highlighted in Step 4.
7. Click Save.
8. Repeat Steps 4 and 6 for Selector2.
9. You should now have resolvable CNAMEs for selector1._domainkey.<domain> and selector2._domainkey.<domain>.
10. From PowerShell, enable DKIM signing for your custom domain:
4. Click Save.

## Recommendations

1. Use the Mail Flow Operational View above to figure out if a an Exchange Transport Rule (ETR) is the best place to configure EOP settings or if some other mechanism may be better, depending on how you want to manipulate a message.
2. If you are going to use an ETR to configure a bypass spam filtering SCL (-1), you should avoid including large consumer domains, such as outlook.com, hotmail.com, yahoo.com, or gmail.com, since that will increase the risk of spam and phishing attempts that get through to your user mailboxes.
3. Scope your rules appropriately.  By default, ETRs are configured to apply to all messages (inbound and outboud), so ensure that you’ve thought that out.  You can apply to all inbound or outbound messages, or all inbound or outbound messages destined to or from certain domains or senders.
4. Mail flow rules are processed sequentially.  If you have a message that meets multiple criteria, you may end up taking additional steps unnecessarily.  There is a configuration option in a rule to Stop additional processing.  For example, rules whose actions are Block should probably have Stop additional processing enabled, since there’s not much else to do except waste CPU cycles.
5. Some actions may take more than one rule to work.  For example, if you want to block a message but also forward it to someone’s manager, you can’t do them both in the same rule. You should configure the message to forward the rule first, and then create another rule immediately following it (with the exact same selection criteria), and configure the additional action.
6. When configuring “Allow” lists, our recommendations are this order:
– Exchange Transport Rules
– Outlook Safe Senders list
– Anti-spam policy: IP Allow Lists
– Anti-spam policy: Sender/Domain Allow Lists

# Malware Filtering

Exchange Online Protection offers multi-layered malware solution that’s designed to catch all known malware inbound to or outbound from your organization (known malware being signature-based things that our rotating malware engines have signature or detection patterns for). Malware filtering is automatically enabled in every tenant via the default anti-malware policy and cannot be deleted or disabled.

You can view and edit some properties of the default anti-malware policy, but you can’t delete it. For greater granularity, you can also create custom content filter policies and apply them to specified users, groups, or domains in your organization. Custom policies always take precedence over the default policy, but you can change the priority (that is, the running order) of your custom policies.  The default anti-malware policy does not allow you to change the scope of the users.

If malware is detected in an email attachment, the entire message will be quarantined and can only be released by an administrator. By default, no notifications are generated when this happens, though you do have the ability to modify that.

In order to apply more targeted policy settings, you’ll need to create custom policies.

## Anti-malware filter policies

You need to be assigned permissions before you can perform this procedure. In this case, you must be a member of the Organization Management or Hygiene Management role groups.

1. In the Security & Compliance Center, click Threat management | Policy | Anti-malware.

2. On the Anti-malware page, do one of the following:
1. Double-click the default policy in order to edit the company-wide policy.
2. Click the New icon to create a new policy that can be applied to users, groups, and domains in your organization. You can also edit existing custom policies by double-clicking them.
3. For custom policies only, specify a name for this policy. You can optionally specify a more detailed description as well. You cannot rename the default policy.
4. Click the Settings menu option. If malware is detected in an email attachment, the message will be quarantined and can be released only by an admin. In the Malware Detection Response section, use the option buttons to configure recipient notifications:

If you select Yes or Yes and use custom notification text, the intended recipient will receive email stating that they have quarantined messages.  You can customize the notification text if desired.  If you select No, the message is delivered to the quarantine silently.
Note: With Exchange Online Protection, the UI indicates that this messages configured for the malware response will be quarantined.  This is different than Exchange Server with the malware filter, and different than the options available in PowerShell.  The note at https://docs.microsoft.com/en-us/office365/securitycompliance/configure-anti-malware-policies indicates that for any option you choose, the result is that the message will be held in the quarantine.
5. In the Common attachment types filter section, choose which file types you want to have the Malware Detection Response option selected above applied on. New policies have the most commonly used malicious file types selected to be detected as malware by default.  You can only choose from the predefined list in the user interface.  If you want to add additional file types to be selectable in the Common attachment types filter area, you’ll need to add them via PowerShell.
6. In the Notifications section, you have the option to send a notification email message to senders or administrators when a message is detected as malware and is not delivered. These notifications are only sent when the entire message is deleted.
1. In the Sender Notifications section, select the check boxes to Notify internal senders (those within your organization) or to Notify external senders (those outside your organization) when a detected message is not delivered.

Note: The default notification text is “This message was created automatically by mail delivery software. Your email message was not delivered to the intended recipients because malware was detected.” The language in which the default notification text is sent is dependent on the locale of the message being processed.

From name. The name you want to be used as the sender of the customized notification.
From address. The email address you want to be used as the sender of the customized notification.
Messages from internal senders. The Subject and Message of the notification if the detected message originated from an internal sender.
Messages from external senders. The Subject and Message of the notification if the detected message originated from an external sender.

Note: You have to select Notify internal senders or Notify external senders under the Notifications sections in order to be able to customize the respective notifications.
7. For custom policies only, if you want to scope or target the policy, under Applied to, click the drop-down and then create a condition-based rule to specify the users, groups, and/or domains for whom to apply this policy. You can add and set multiple conditions, but can only use each condition type once.
• To select users, select The recipient is. In the subsequent dialog box, select one or more senders from your company from the user picker list and then click Add. To add senders who aren’t on the list, type an address in the text box next to Check names and then click Check names. Note: In this box, you can also use wildcards for multiple email addresses (for example: *@domainname). When you are done with your selections, click OK to return to the main screen.
• To select groups, select The recipient is a member of and then, in the subsequent dialog box, select or specify the groups. Click OK to return to the main screen.
• To select domains, select The recipient domain is and then, in the subsequent dialog box, select the domains. You can only choose domains that are added to your tenant.  Click OK to return to the main screen.
8. Click Save. A summary of your default policy settings appears in the right pane.

## Notes

If you need to add additional file extensions or types to be selectable in the Common attachment filter dialog, you’ll need to do so through PowerShell.

1. Connect to Exchange Online or Exchange Online Protection via PowerShell.
2. Create a PowerShell array containing the file types to add to the filter.  For example, I want to add ZIP and ZI_ to the attachment filter available in the Default policy.
[array]$FileTypesAdd = Get-MalwareFilterPolicy -Identity Default | Select-Object -Expand FileTypes$FileTypesAdd += "zip","zi_"
Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true -FileTypes$FileTypesAdd

## Recommendations

1. Only configure company-wide settings in the default anti-malware policy, since it cannot be scoped and will automatically apply to all users.
2. Create custom anti-malware policies to apply certain settings to targeted groups of users.
3. Turn on notifications for recipients so that they know a message was blocked due to malware.  This helps alleviate the “I’m expecting mail from” and “why haven’t I received it” questions.
4. If you are configuring an attachment blocking policy, use the Mail Flow Operational Overview above to determine if the Common Attachment Type Filter blocking is appropriate as opposed to configuring attachment blocking parameters via Transport Rules.  For example, you may want to configure your environment to quarantine messages that have attachments when the message doesn’t pass DMARC. That would require a Transport Rule.  However, if you just wanted to block .zip files across the board, you could use the Common Attachment Type Filter block to achieve that.

There are a number of additional configurations that don’t necessarily fall under configuring policies, but things that are good general practices.

## The Last Word on Allow Lists

I mentioned this previously, but any good record deserves another spin.

We provide you four mechanisms by which to allow mail to be whitelisted and pass into your environment (listed in order of most preferable to least preferable):

• Exchange Transport Rules
• Outlook Safe Senders
• Anti-spam policy: IP Allow Lists
• Anti-spam policy: Sender/Domain Allow Lists

Using the mail flow diagram above, you can see that if you add a sender to the anti-spam lists, you are effectively bypassing all of the protections we can offer you.

The most flexible and secure way to ensure you allow legitimate senders is by using a transport rule that checks the authentication headers of a message (looking for the Authentication-Results header to match ‘dmarc=pass’ or ‘spf=pass’ or ‘dmarc=bestguesspass’), and then setting the SCL to -1 based on that.  “SCL -1,” as you’ll recall, tells EOP to skip spam filtering, since it’s now marked as “safe/bypass.”

Exchange Transport rules allow the most flexibility (such as allowing sender domain or IP configuration in conjunction with authentication header results), followed by the end-user’s Safe Sender’s list.  If you configure settings in the anti-spam policy, you will be bypassing spam checks solely based on domains or IP addresses and not on additional spam characteristics.  Configuring allow rules in the anti-spam policy will bypass many of the safeguards and filtering capabilities of Exchange Online Protection.

If the sender you’re trying to whitelist doesn’t have properly configured DMARC, this is a great opportunity to reach out to them, point them to this blog (and other helpful resources), and help improve their security posture for email.

For further reading, check out Create safe sender lists in Office 365.

## Enabling End User Quarantine

Many customers choose to enable end-user quarantine, so that users can periodically review and release their own spam-quarantined messages.  End users are not able to release malware-quarantined messages.  This is a “you do you” type of item, as some of my customers don’t want their end users to have access to this data, while other customers teach their end users to be more self-supporting.  Personally, I recommend enabling it and putting the onus on the user to manage their options, and guide them to escalate to a service desk call if necessary.

You can enable end-user quarantine by completing the settings on https://outlook.office365.com/ecp/Antispam/EditEnduserSpamNotification.aspx.

For information about how to view an email message header in various email clients, see Message Header Analyzer documentation, or check out this blog post.

You can copy and paste the contents of the message header into the Message Header Analyzer tool. When you select a message in the quarantine in the Exchange admin center, the View message header link also easily lets you copy and paste the message header text into the tool. Once in the Message Header Analyzer tool, click Analyze headers in order to retrieve information about the header.

## Enabling Multi-Factor Authentication

Users often use a combination of the same password and email address which can be risky, especially when they are used to access resources outside of your organization. To help prevent users’ credentials from being compromised, it’s recommended that you enable multi-factor authentication (MFA).  This isn’t necessarily Exchange Online Protection-specific–it’s really geared towards any service (Microsoft and otherwise).

For instructions about enabling MFA in Office 365, see Set up multi-factor authentication for Office 365 users.

After you have enabled MFA on your tenant, your users can refer to Set up 2-step verification for Office 365 to set up their second sign-in method for Office 365.

RFC 2142 lays out a number of addresses that are required for systems hosting domains or mailboxes.  They’re not configured by default in Exchange Online or Exchange Online Protection; I’d recommend doing so just to be a good internet denizen.

The basic required addresses (from an RFC perspective) are:

No one is going to come knocking on your door if you don’t have them (namely, because you don’t have a way for anyone to get ahold of you).  There are no internet police sending you information superhighway traffic tickets for not having the RFC-required recipients.

### Configure the External Postmaster Address in Exchange Online

Exchange Online supports configuring the service to know about a postmaster address.  You still need to configure the mailbox manually.  To configure the address to be used for postmaster, you’ll need to connect to Exchange Online via PowerShell and run the following command:

You’ll still need a mailbox to answer for it, which we’ll get to in a minute.  For more information on configuring the Postmaster address, see Configure the external postmaster address in Exchange Online.

### Configure A Shared Mailbox and Basic Reply Rule

The idea here is to create a shared mailbox with all of those “standard” aliases, and then configure an auto-reply rule to route the sender to a webpage where they can find what they’re looking for. This is not the only way to skin this cat, but it is an easy way.  You’ll need to connect to Exchange Online via PowerShell to run this script. Set $Domain to whatever your domain is.$Domain = "@o365ninja.com"
New-Mailbox -Shared -Name "Service Mailbox" -DisplayName "Service Mailbox" -PrimarySmtpAddress "service$($Domain)" -Alias ServiceMailbox
[array]$Addresses = (Get-Mailbox ServiceMailbox).EmailAddresses Foreach ($address in ("postmaster","hostmaster","usenet","news","webmaster","www","uucp","ftp","abuse","noc","security")) { $Addresses += "$($address)$($Domain)"} Set-Mailbox ServiceMailbox -EmailAddresses$Addresses
Foreach ($address in ("postmaster","hostmaster","usenet","news","webmaster","www","uucp","ftp","abuse","noc","security")) {$Addresses += "$($address)$($Domain)"}
New-InboxRule -Mailbox ServiceMailbox -DeleteMessage

While these might not be totally connected to the EOP service, I feel like they deserve honorable mention.

## Remote Connectivity Analyzer

The Remote Connectivity Analyzer (you’re probably pretty good at guessing our acronyms by now–RCA) has several tests that you can use to test mail flow and Autodiscover, and is a good place to start looking if you’re experiencing mail flow issues.

Note: Before sending samples to Microsoft, refer to Anti-spam message headers and analyze the message headers from the email that users are receiving. Did these messages get through because of rules (SFV:SKA, SFV:SKN) or user safelist configurations (SFV:SFE)? Before sending samples to Microsoft, refer to Submitting spam back to Office 365.

No, this isn’t a chokehold or something, though a lot of us want to do that to spam.  If you receive content that you think should have been caught (undetected spam, for example), you can follow the directions here to submit it to us.  https://docs.microsoft.com/microsoft-365/security/office-365-security/admin-submission

## Security Baselines

It’s great to protect your mail, but it’s also great to protect your endpoints and devices against other types of threats (for example, the kinds that don’t show up through email).  We have published some Security Baselines for Windows, which are pretty useful.  You can read about the security baselines here: https://docs.microsoft.com/windows/security/threat-protection/windows-security-baselines#where-can-i-get-the-security-baselines.

# Common Scenarios and Troubleshooting

This section describes scenarios you should be aware of that are frequently observed in customer deployments.

1. Compromised users. Malicious email sometimes originates from users in an organization whose accounts have been compromised. If you have reason to suspect this is happening, you may want to consider configuring Azure Active Directory Identity Protection to identify the compromised users and mitigate the issue.  You can also check out the tools and tips I’ve provided at https://www.undocumented-features.com/2018/12/19/checking-for-compromised-email-accounts/.
2. Compromised users unable to send mail.  After a user account has been blocked for sending suspicious mail, you’ll need to re-enable them.  See Removing a user from the Restricted Users portal after sending spam email.
3. Filter tuning. When managing your spam filter policies, you can select a bulk complaint level (BCL) to treat bulk email as spam. The default setting of 7 allows most good bulk messages to be delivered. However, adjusting to 5 or 6 is a good practice if you feel you are receiving too much spam. Rule of thumb: If there is a high rate of false positives, these may be too sensitive; if there is a high rate of false negatives, these may be not sensitive enough.

From cat videos to uses for the ShamWow, the interwebs have no shortage of reading material.  Here’s some additional stuff in the Exchange Online Protection vein should you still need help falling asleep.

What is Exchange Online Protection – In case I haven’t answered it well enough, here’s some other people who basically say the same thing. https://docs.microsoft.com/en-us/office365/securitycompliance/eop/what-is-eop

Mail flow rules – This is an enormous read with all of the conditions, exceptions, and actions you can take with transport rules. https://docs.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules

Common attachment blocking scenarios – There are a two core ways to block attachments in Exchange Online: Common Attachment Type Filtering (as part of the malware policy) and Exchange Transport Rules.  You have similar capabilities with both, so it’s going to be up to you to determine which is going to meet your needs.  We’ve published an extensive guide on configuring attachment blocking options with Exchange Transport Rules here: https://docs.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/common-attachment-blocking-scenarios

Advanced Threat Protection – I decided to embark upon this post because of the positive feedback I’d received on a similar post for Advanced Threat Protection.  Go check it out if you have the service (or are interested in the features it provides): https://www.undocumented-features.com/2018/05/10/atp-safe-attachments-safe-links-and-anti-phishing-policies-or-all-the-policies-you-can-shake-a-stick-at/