Freigeben über

If your MX record doesn't point to Office 365, how do you disable spam filtering in Office 365?

  • Artikel

One of the questions that has come up recently, especially as a lot of customers migrate over from an existing spam filtering solution to Office 365, is how to force Office 365 to rely upon the spam/non-spam verdict of the service that's sitting in front of Exchange Online and not double-filter.

Office 365 already has a way to do this via connectors if the email server in front is an on-premise Exchange server. It does this by using TLS certs to "promote" the pre-existing properties of a message stamped by the Exchange server so they are re-used by Office 365. But what if your server in front is not Exchange? Then what?

There are a few ways to do this, but the key thing is that there is no simple way to disable spam filtering in Office 365. The option for "Do not filter spam" does not exist at an organizational level. Instead, you have to do a few tricks depending on the configuration.

  1. You want the service in front of Office 365 to get rid of spam, such as sending it to a spam quarantine.
    .
    In this case, the spam is taken care of somewhere else, and all email going to Office 365 is non-spam (according to the upstream filter). Therefore, you can create a set of IP Allow List entries corresponding to the relay IPs into the service. This will set SCL -1 and send all email into your users' inbox, bypassing spam scanning, and stamp IPV:CAL and SFV:SKN in the X-Forefront-Antispam-Report header.Alternatively (even preferably) you can create an Exchange Transport Rule (ETR) for those connecting IPs that (a) sets the SCL to -1, and (b) sets an x-header:
    . X-Relay-IP-for-service: Allow email from <name of service>

    .
    ... as it is already filtered for spam.
    .
    This way, when someone in your organization gets a message that is spam, and you decide to escalate to Office 365 for missing spam even though we didn't filter it because you said not to, we'll be able to quickly look at the headers and see that's why the message was delivered to the user's inbox..

  • You want to use Office 365 to manage both spam (in the Junk Email folder) and non-spam.
    .
    In this case, you want non-spam to end up in users' inboxes, and spam to go to the Junk Email folder the way it would for something like an Outlook.com or Gmail account.This requires you to configure the upstream mail service to configure two headers: one that is stamped when the service marks a message a spam, and a second one that is stamped when the service marks a message as non-spam. For example, Office 365 uses the X-Forefront-Antispam-Report header to stamp SCL -1 or 1 for non-spam, and SCL 5 or 6 when it is spam, and SCL 9 when it is high confidence spam.
    .
    Then, in the Office 365 platform, you would write an ETR that sets SCL -1 when it sees the stamp for non-spam, and SCL 6 (or 9, depending on what you want the action to be) when the message has the spam stamp.
    .
    You can extend this for safe and blocked senders, safe and blocked domains, etc. Whatever stamp the upfront service stamps in each case should be consumed downstream.

There is another method such as disabling junk mail filtering on a per-mailbox basis which will force messages to go through filtering but still land in the inbox (this is what I do on my own personal email, although my MX points to Office 365). However, this is an advanced scenario and causes customers a lot of trouble.

Putting additional services in front of Office 365 is what we call "complex routing"; there are several scenarios for complex routing, and the MX pointing to another service is the simplest case.

Finally, if you do use complex routing like this, there are some things to be aware of:

  • You lose a big chunk of the benefits of pointing your MX to Office 365 as the first hop in the path. Make sure you read the first article in the Related Posts section at the bottom of this article
    .
  • Outlook Web Access (OWA) has some client-side integration that lights up when hooked together with Office 365, and some of those features depend on Office 365 being the first hop in the path (e.g., showing a '?' in the sender photo). When these behaviors come to Outlook desktop client, it will have the same requirement. That's another feature loss for complex routing.
    .
  • Additional services in front of Office 365 results in additional layers of management complexity
    .
  • Advanced Threat Protection works much better when Office 365 is the first hop in the path, we usually recommend putting other services behind us, and then looping the email back in via a connector. You'll have to use ETRs again and they are more complex, but that way you get the full protection
    .
  • If you get missed spam or false positives because of this configuration, it is challenging for us to do much with them because parts of our filter have been disabled

Related posts