- 1 Provisioning
- 2 Getting your Hosted CanIt MX Records
- 3 User Counts
- 4 Other Best Practices
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. Using our Hosted CanIt product, this routing address is initially filled in by entering it as the "Route To:" address for the My Domains->Request Additional Domain form. Otherwise, for on-premise installations of CanIt you can provide it for both fields on the "Configure Routing and Verification" page of the Setup->Wizards->Domain Configuration Wizard.
The exact hostname you need to provide in either case is 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.
Getting your Hosted CanIt MX Records
Normally, the MX Records that should be published for your domain would be made available from the My Domain->My Domains page of the WebUI. However, it is very likely that you will see that there is an error preventing these from being shown.
By default Office 365, as well as any other version of Microsoft Exchange, does not validate recipients. We have this as a minimum requirements so that we can automatically generate accounts for you without generating accounts that don't actually exist. The Recipient Verification section below discusses all of the ways that you can make this work.
Once you have used one of the methods below, you will likely find that the MX records are still not visible from the My Domains->My Domains page. This is because the automatic process that runs this test only occurs once per day. You can force it to run immediately by scrolling just below the MX Records section on that page to the section discussing the errors. This section has a button to "Re-Check Domains for Validation". Clicking this will initiate the test, but the results take a few seconds to come back. Wait for about 5 seconds and then refresh the page and you should now see the records.
If you do not see the MX Records after employing one of the 3 methods and running the check again, please contact Roaring Penguin technical support for help.
As mentioned in the previous section, 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. CanIt normally generates user accounts for you, but to do so accurately it needs some method to reject invalid recipients and to cause alias addresses to use a single account (AKA "stream").
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:
Note: You may already be using the "Authoritative" setting with a fully populated list, but you will likely still need to switch it off and back on unless you have done so before. It can also take some time for this setting to propagate to all of the Office 365 servers, so our tests will not necessarily pass for about half an hour.
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 defined using Setup->User Lookups (see the "Online Documentation" link in the top-right corner of that page to see instructions on setting this up).
Once set up, AD/LDAP has multiple functions, so you need to tell us which functions should be used by which domains. The one that is relevant to verification and user counts is Setup->Domain Mappings which tells us that this is the method to use to find "stream" names (which will also reject addresses that don't resolve a "stream" name). This has the additional benefit of being able to detect existing aliases and to support authentication, as below.
The other function is to allow for user authentication to the CanIt portal with their AD/LDAP credentials. This is defined from Setup->Authentication Mappings.
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.
If you are using AD/LDAP, as defined above, user aliases will automatically be detected. However, if you don't have an external AD/LDAP system, or if you need to support distribution groups, shared mailboxes and other situations where an address does not resolve to a single primary mailbox, extra steps are required. This is discussed in depth in our article on Aliases.
Other Best Practices
Do not treat CanIt IPs specially
Office 365 allows you to mark specific IPs as "Safe". Unfortunately, this breaks Directory-Based Edge Blocking, so do not mark our IPs as "Safe".
If you do have an external AD/LDAP system you can connect CanIt to it as discussed for Recipient Verification above to use it for authentication as well.
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 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, you must enable 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.