CanIt works with Office 365 as it does with any SMTP mail service; MX records for the domain are pointed to CanIt, and filtered mail is directed to the Office 365 server by configuring routing using Setup->Domain Routing in Canit. This routing address is initially filled with the one that you give us upon requesting the domain. You simply need to provide the MX records that are given to you in the O365 admin portal. These usually look something like:
After the domain has been provisioned, there are a handful of extra steps that are required to get Office 365 to conform to the standards that we expect, as discussed below.
One shortcoming of Office365 is that Microsoft doesn't provide external access to an Active Directory system and does not properly validate recipients via SMTP by default (this is the case for any Microsoft Exchange system). CanIt requires some method of recipient verification so that it doesn't end up accepting and billing for users that don't exist.
The below methods for Verification will ensure that we do not accept mail for addresses that do not exist, however it will treat all unique email addresses as distinct accounts when CanIt tries to generate streams. In order for CanIt to recognize any aliases, distribution lists, or shared mailboxes as addresses that should not be billed for, you must use Setup->Address-to-Stream Mappings in order to consolidate them into an existing user's stream. The easiest way to do this is to simply direct mail to a responsible party within that list, for example:
Address Stream email@example.com firstname.lastname@example.org
This would allow Alice to review any pending message for sales as if it had been sent to her, but CanIt will still deliver that message to email@example.com after it passes through.
Alternatively, you may instead choose to push all group mail through a single stream that will be monitored by the administrator, increasing your user count by only one for all group addresses.
CanIt also have the Setup->Aliases page which serves the same function as Address-to-Stream Mapping, except that the mail is actually re-written to the target address. In the above example, this would deliver all mail for firstname.lastname@example.org to only email@example.com. This is not very useful for groups, but can allow you to accept mail for addresses that don't actually exist on the back-end.
Note that end-users can create these mappings by using Preferences->My Addresses and Preferences->Aliases, respectively. Each requires that a recipient at the alias address confirm that request (this means that aliases for non-existent addresses cannot be added using this method).
If you have access to the Office 365 management portal you should also be able to get valid recipient checks working correctly, allowing us to keep an up-to-date list of valid address automatically. This requires you to enable the Directory Based Edge Blocking (DBEB) feature. This is analogous to our Valid Recipient list, but will only then require you to keep the list current in one place. Instructions can be found here:
If you have your own external AD/LDAP which Office 365 is connecting to we can also use that for recipient verification, making the need for a SMTP-based verification process unnecessary. This is done using Setup->User Lookups and must be defined for use with Setup->Domain Mappings. This has the additional benefit of being able to detect existing aliases and to support authentication, as below.
Valid Recipient Table
Without changing anything in Office 365, you can work around a missing external verification source from directly within CanIt by manually defining the list of possible recipients using Rules->Valid Recipients, and by enforcing the list with Preferences->Quarantine Settings->S-950. See Recipient Verification below another way to set up automated verification.
Other Best Practices
Restricting Inbound Connections to CanIt
Office 365 allows you to restrict incoming connection from only select IP addresses so that no spam is able to bypass our filter. At the time of writing, it appears that this should be set under Email Protection->Setup->Inbound Servers. The IP addresses for Hosted customers are available from the My Domains->My Domains page of our WebUI.
If you do have an external AD/LDAP system, as discussed for Recipient Verification above, you can also use it for authentication by setting it up in Setup->Authentication Mappings.
Office 365 does provide a public POP3 and IMAP service which you should be able to use for authentication instead. This must also be set up using the the Setup->User Lookups wizard, then must be enabled from Setup->Authentication Mappings. Some clients have reported success with the following settings:
POP3: outlook.office365.com/995 IMAP: outlook.office365.com
If these settings don't work, or if you have any other concerns about this integration, you will need to contact Microsoft for more information.
Supporting SPF Checks
Office 365 may checks for SPF results. As a result, any sender that has a valid SPF record will be flagged after it passes through us and has a possibility of being rejected since we are bound not to be included in those records.
For this reason, we strongly recommend enabling Sender Rewriting Scheme. In the default stream for your realm, go to Preferences : Quarantine Settings and set S-930 Enable SRS (Sender Rewriting Scheme) to Yes
This will allow us to re-write the sender address in such a way that the Office 365 will not flag the failed SPF checks. We also check for SPF records, so you will not lose any security as a result of this change.
Hosted CanIt offers outbound filtering support for Office 365 but as with all outbound filtering it needs to be requested on a per-domain basis, since it is a premium feature. This can be done with My Domains->Request Outbound Filtering by selecting Office 365 as the source. Once this is done, you need to set Hosted CanIt up as the outbound Connector using the information that is provided in the confirmation email that you will receive. As of the time of writing, this setting in Office 365 is located in the Exchange Admin Center under Mail Flow->Connectors.
For on-premise implementations, Outbound Filtering is not advised for Office 365 domains. It requires a significant level of setup and maintenance to allow only the desired relay connections from Microsoft's ever-changing list of IP's. We have site-specific automations and custom code to handle this on Hosted which cannot be easily transferred to on-premise appliances.