If you have a 3rd party mail security system, or you have locked down Office 365 inbound mail flow, you may notice that when you attempt to share something with an internal colleague in SharePoint Online, the sharing invitation NDRs and gets bounced back. If your mail goes direct to Office 365 and you have configured an Inbound Connector in order to lock down inbound mail (eg to only allow Mimecast to send mail to Office 365), you may see the following error:
Your message wasn't delivered because the recipient's email provider rejected it.
Alternatively, your 3rd party mail hygeine product (in my case, Mimecast) blocked the message before it could get to Office 365 with a slightly different error:
Remote Server returned '< #5.5.0 smtp;550 Administrative Lockout - Inbound not allowed >'
The reason for this error is because the SharePoint Online service is spoofing your email address to send the sharing invitation. If we look more closely at the source server name, we can see that, in my example, the email came from DB4.MAIL.YLO001.MSOPRD.MSFT.NET, which is one of Microsofts own SMTP servers (probably running MDaemon ;-D). The email is coming from a Microsoft SMTP server and is using one of your own email addresses. Not many email services will like this, particularly mail security services such as Mimecast or MessageLabs if this is where your MX records point. To get around this, you will need to allow the SharePoint Online IP address ranges to send using your domain name.
If your MX records point to Office 365 and you have an Inbound Connector configured for locking down inbound mail flow, then you can connect to Exchange Online Powershell and add the SharePoint Online IP addresses to your connector:
First, run Get-InboundConnector | fl and note down the existing SenderIPAddresses. In this example, I will use 22.214.171.124 for demonstration purposes.
Then run the below command to change the IP addresses assigned to the connector. Make sure you include the IP addresses of the mail system which your MX records point to, or you will end up not receiving any mail at all!
Set-InboundConnector -Identity "Connector Name" -SenderIPAddresses 126.96.36.199/32, 188.8.131.52/27, 184.108.40.206/24, 220.127.116.11/24, 18.104.22.168/27, 22.214.171.124/24, 126.96.36.199/24, 188.8.131.52/24, 184.108.40.206/27, 220.127.116.11/27, 18.104.22.168/27, 22.214.171.124/27, 126.96.36.199/25, 188.8.131.52/27, 184.108.40.206/27, 220.127.116.11/27, 18.104.22.168/25, 22.214.171.124/24, 126.96.36.199/24, 188.8.131.52/24, 184.108.40.206/24, 220.127.116.11/24, 18.104.22.168/24, 22.214.171.124/24, 126.96.36.199/24, 188.8.131.52/24, 184.108.40.206/24, 220.127.116.11/24, 18.104.22.168/24, 22.214.171.124/24, 126.96.36.199/24, 188.8.131.52/24, 184.108.40.206/24, 220.127.116.11/27, 18.104.22.168/27, 22.214.171.124/27, 126.96.36.199/27, 188.8.131.52/27, 184.108.40.206/27, 220.127.116.11/26, 18.104.22.168/27, 22.214.171.124/27, 126.96.36.199/27, 188.8.131.52/25, 184.108.40.206/27, 220.127.116.11/26, 18.104.22.168/27, 22.214.171.124/27, 126.96.36.199/27, 188.8.131.52/27, 184.108.40.206/25, 220.127.116.11/27, 18.104.22.168/27, 22.214.171.124/27, 126.96.36.199/27, 188.8.131.52/27, 184.108.40.206/27, 220.127.116.11/27, 18.104.22.168/27, 22.214.171.124/26, 126.96.36.199/27, 188.8.131.52/26, 184.108.40.206/27, 220.127.116.11/27, 18.104.22.168/27
The list of IP addresses above is all of the SharePoint Online IPs at the time of writing, however this is subject to change and should be checked by yourself prior to running this command. You can check the list of IP addresses here: https://support.office.com/en-ca/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2?ui=en-US&rs=en-CA&ad=CA#BKMK_SPO
In my case the problem was actually with my Mimecast configuration, not Office 365. In Mimecast there is an Inbound Lockout Policy section under Gateway>Policies. The policies configured here say that any Inbound messages from our domain name should be dropped by the firewall. This stops spoofing and is a default policy. To stop Mimecast blocking messages from SharePoint Online, I created a new Inbound Lockout Policy which did not block emails to my domain name when the Sender IP address was one of SharePoint Online’s IPs. This rectified the problem.
Locking down mail flow does have many benefits, but simplified administration is not one of them unfortunately!