Configuring Exchange Online Protection for email on a shared host19 January 2019
I’ve had a webhosting package, including email mailboxes, for longer than I care to remember. It’s always been on shared CPanel hosting, most recently with Vidahost, which has now become Tsohost.
It’s a sad state of affairs, but I’m fairly certain that I receive more spam emails than genuine. Those that are not detected by the spam protection offered by my hosting company might eventually be recognized as spam by my email client on my laptop (Apple Mail, Mac OS X), but I still see more unread spam emails in my inbox than any other type of email.
My hosting company offers Spamassassin via the shared CPanel. As far as I understand it, this has two disadvantages:
- Spamassassin is difficult to configure and requires continual tweaking in order to maintain performance
- Spamassassin cannot be adequately configured on a shared CPanel platform
(Unfortunately don’t have references for these assertions to hand.)
My last bout of googling (duckduckgoing?) brought Exchange Online Protection (EOP) to my awareness for the first time. Some commentators explicitly recommended it for email mailboxes on shared hosting and enthused over the excellent performance in terms of spam recognition.
I decided to give it a go, not realising how difficult it would due to the obfuscate nature of Microsoft cloud products and out of date documentation.
This is how I managed it (note, I’ve used the placeholder domain name crocodile.com throughout).
Trial Exchange Online Protection
I don’t have an existing Microsoft of Office 365 account, so created one in the course of signing up for the Exchange Online Protection trial here: https://products.office.com/en-us/exchange/exchange-email-security-spam-protection
As I’m essentially just using Office 365 as a mail relay, the specifics of my Office 365 account were not particularly critical. You need to choose a domain name, which will appear as domain.onmicrosoft.com, and an admin user, email@example.com.
At the end of this process I could log in to www.office.com and could see two or three standard apps. No access to Exchange, but more about that later.
Add email domain to Office 365
- Add the target email domain, e.g. crocodile.com, on Office 365 > Admin > Setup > Domains: https://portal.office.com/AdminPortal/Home#/Domains
- Verify the domain by adding the secret TXT record provided by Office 365 to the shared hosting’s DNS records (CPanel -> Zone Editor)
- Name = target domain name (crocodile.com.)
- Record = see Microsoft admin portal (MS=ms0123456789)
- TTL = 3600
The domain was validated without problems.
Configure Exchange connector to forward incoming emails to hosting mailserver
All of the guides and tutorials I could find assumed that I could access the Exchange settings from Office 365, but I could not find any link to Exchange. Eventually I discovered that logging in to https://outlook.office365.com/ecp using the account created above leads directly to the Exchange settings.
Edit 7/4/2020: The correct location for editing Exchange settings seems to be https://eur04b.admin.protection.outlook.com/ecp/. It can be found in the Microsoft 365 Admin Centre under Show all > Admin centers > All admin centers > Exchange Online Protection
- Add connector to Exchange Admin Center > mail flow > connectors to forward incoming email to target domain
- From: Office 365, To: Organization’s email server
- When to use: Only these domains: *.crocodile.com
- Add smart host. Don’t make the same mistake that I intially made and put in your regular domain (crocodile.com) here. That’s going to create a loop in which EOP tries to forward the email to itself. Instead we need the FQDN of the hosting company’s mail server. In my case it’s the domain confgured in my mail client for receiving and sending email. Let’s call it hosting.mailserver.com
- TLS on, trusted CA on
- For validation, use a valid firstname.lastname@example.org email address (seems to always fail if validation attempt is made immediately. Either repeat, or wait a couple of minutes before attempting)
- Edit MX record (CPanel -> Zone Editor) to point to Office 365 (The destination syntax for crocodile.com would be crocodile-com.mail.protection.outlook.com: Ref.). I read a great tip recommending to reduce the TTL of the existing MX entry some time before changing the other settings, so that the edit to the destination value will propagate faster.
- Name: crocodile.com
- Destination: crocodile-com.mail.protection.outlook.com
- TTL: 3600
- Test: I made the change to MX entry on my CPanel hosting, sent a test email from an icloud account, and the email arrived immediately. I’m no expert on email headers, but the email seems to have passed through EOP based on these excerpts:
Received: from mail-vi1eur04lp2050.outbound.protection.outlook.com ([xxx.xxx.xxx.xxx]:nnnnn helo=EUR04-VI1-obe.outbound.protection.outlook.com) ... Received: from DB3EUR04FT039.eop-eur04.prod.protection.outlook.com ... Received-SPF: Pass (protection.outlook.com: domain of icloud.com designates xxx.xxx.xxx.xxx as permitted sender) receiver=protection.outlook.com;
Emails can also be traced in the Security and Compliance > Mail Flow > Message Trace area of Office 365: https://protection.office.com/#/messagetrace
Handling spam hits
Exchange Online somewhat assumes that the smart host in question is an on-premises Exchange server, which of course is not the case for me. However, it’s possible to edit the spam filtering rules to, for example, add an X-Header to the email.
Exchange Admin Center > protection > spam filter: https://eur04b.admin.protection.outlook.com/ecp/?exsvurl=1&p=DistributionGroups&wa=wsignin1.0
I can then configure an CPanel email filter to recognise this X-Header and handle the email accordingly.
Alternatively, the suspect spam emails can be quarantined in Exchange.
End-user spam notifications can also be configured here, perhaps not a bad idea for the bedding-in period.
I believe it’s also possible to use Office 365 to relay outgoing email from the CPanel mailbox. I don’t currently have any need for this and the configuration of the appropriate Exchange connectors looks a bit more complicated.
I’m presently signed up to a free trial. The costs are around $1 or €1 per user per month. Good value, if it works. I’ll be updating this article with my conclusions after a couple of weeks.
After 1 week: First impressions are very positive, with not one single spam email slipping past EOP. There was some confusion:
- Some spam still arrived, having not been routed via EOP. I guess this was due to latency in propagating the MX record. Interestingly, there was a very clear difference between genuine email (the new MX record was very quickly recognised, this email started arriving via EOP very quickly) and a significant amount of spam, which continued to use the old MX record. I set up a temporary email filter in CPanel to send all email that had not arrived via EOP to my junk folder. I was able to remove this filter after a four or five days.
- The spam reporting in Office 365 really confused me, as one graph was showing around 30 – 40 spam detections per day, but I was unable to find these emails in the reporting tools (Message trace) or Quarantine. It seems that EOP drops a certain category of emails where the spam certainty is 100%, based on the originating IP address. These emails do not appear in any of the reporting tools.
- The spam detection that does appear in the reporting/quarantine has been very accurate so far.
So far it’s looking good and will be well worth the 1€/month when my trial expires.