- 1 Provisioning
- 2 Getting your Hosted CanIt MX Records
- 3 Recipient Verification
- 4 User Counts
- 5 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.
Azure Active Directory
If you are using a version of CanIt from 10.2.0 or later, you will be able to tie directly into Office 365's Azure Active Directory system in order to validate recipients and to automatically detect aliases. There is a wizard to set this up from Setup->User Lookups. You just need to pick the correct "Method" after providing a name for the lookup. Setting this up is somewhat involved, but it is fairly well documented. Once you get to the main settings page for the lookup, click the "Online Documentation" link in the top-right corner for setup instructions.
Once defined, you need to tell CanIt which domains should use that lookup from Setup->Domain Mappings.
As below, we automatically populate a Setup->Verification Server for all new domain requests on Hosted CanIt, if you are using Azure AD, you should remove that entry as it is redundant.
Note that Azure AD, at the time of writing, does not support user authentication, so you will need to set up an additional IMAP lookup to allow users to log in, or define their credentials locally (not recommended).
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 mentioned below, but then you will only need to keep the list current in on Office 365. 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.
With any new request on Hosted CanIt the Setup->Verification Server is automatically pointed at the same hostname that was provided for routing with the request form. If you are not using Hosted CanIt, you will be prompted to define the Verification Server by the Setup->Wizards->Domain Configuration Wizard on the same page as the routing information and can use the same address. You can also add the Verification Server by hand, or after the fact.
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.
As above, using AD/LDAP as the Domain Mapping makes a Setup->Verification Server entry redundant. We add that entry automatically on Hosted CanIt, so you should remove it if you do set up this lookup method.
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-700 "Only accept mail for accounts in the Valid Recipients table".
As is the case with any Domain using Roaring Penguin, users and generated automatically if we identify them as being valid. The counts are determined by the number of unique "Streams" (end-user quarantines) that we see in use during the given billing cycle. These numbers are provided from My Domains->My Provisioning (Hosted CanIt) or Administration->Provisioning (on-site installation). The numbers will not appear if we are not validating users, as discussed above.
If you use either the SMTP Verification or Valid Recipient Table method above, this will allow us to create a unique stream for every email address. We will have no way of automatically accommodating aliases, distribution groups, etc. Options to make us aware of these are discussed below.
If you use either Azure or generic Active Directory (or LDAP) we do have the ability to automatically detect those. This requires that
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.