Recently I undertook the task of migrating our on-premise Exchange 2007 server to Office 365/Exchange Online. This was a major undertaking, which in and of itself could be an entire series of blog posts spanning many, many... many posts. This is something that I may tackle at some point in the near future. But for now, what I'm going to focus on here is how I set out to get SharePoint sending it's various emails and alerts using Exchange Online.
While user mailboxes are now sending and receiving their email after all was said and done, I still had a number of systems, applications, and even a printer that needed to be configured to send email via Exchange Online. Our SharePoint 2013 and 2010 farms were on the forefront of my mind. SharePoint Outgoing Email settings simply ask you for an SMTP server, which is going to be connecting via port 25.
As I looked into how to get this to interface with Exchange Online, I found a few different methods. One method explained that since Exchange Online uses port 587 for it's incoming connections, that you would have to set up an SMTP relay. The idea here is that you setup your own SMTP service running within your network, and point SharePoint towards this. Then configure this SMTP service with an outbound port 587 connection to outlook.office365.com, providing it valid credentials for an account that has an Exchange Online mailbox. This does work nicely. However, there are a few downsides to this method.
One downside is you must also make sure that the "from" address you're stamping your email with also matches the account you're using to relay up to Exchange Online with. If these don't match, your email bounces to the bad mail folder of your SMTP server. But what if you have more than one SharePoint farm? More than one application/site all needing to send mail? More than one printer or other email enabled device? They're all going to share the same "from" address, they're all going to come from the same Exchange Online account.
This may or may not be an issue depending on you or your companies preferences. You may want to, and see great benefit in, having one big Company Alerts account that everything of this nature comes from. But I personally don't want SharePoint 2013 alerts, SharePoint 2010 alerts, scans from the Xerox, updates from Windows Server Update Services, etc. all coming to me from the same email address. Sometimes I like to setup email rules that nicely organize your automatic alerts into folders, some I want front and center in my Inbox. I like to add certain emails to the VIP list on my iPhone so I see it as a high priority, read now kinda thing. I like being able to tell alerts, invitations, and reports apart from a quick glance, letting me know which ones I need to immediatly open and read fully vs. the ones I can just ignore most of the day.
You could separate them out using multiple SMTP servers, each one configured differently, each one with a different Exchange Online account. But I don't see that as ideal. Plus, I don't like the idea of using up one Exchange Online license per acccount you wanted sending alerts.
With further research I found some suggestions to configure a Remote Domain for your SMTP server, and allowing incoming email to be relayed to your Exchange Online protection service smart host (e.g. yourdomain-com.mail.protection.outlook.com). This worked great! Not only could all of the internal systems easly relay email through the local SMTP server on up through Exchange Online, but I could use whatever "from" address I wanted again, same as when we were running with on-premises Exchange. I took this architecture and made it a little simpler, thinking ahead to the future, and created an internal only CNAME of simply "smtp", and used that for SharePoint, the printer, etc. Leaves it open to reconfigure email in the future from one centralized place instead of having to go out and touch all of those devices/applications/servers individually again to change it.
But with this solution I noticed that the relay didn't require credentials, and it also didn't require a special port 587 setup. Wait a minute, let's try something. And sure enough, I could simply put the mail.protection.outlook.com smart host directly into SharePoint Outgoing Email settings, and it works just fine via port 25. After researching and trying these more complex setups, I found that none of it was needed. I did, however, decide to keep the "smtp" internal CNAME in place, and simply updated it to point directly at our organizations Exchange Online smart host instead. If something changes, Microsoft decides to lock access to the smart host down a little more, we move off of Exchange Online, etc. I can put something in place and repoint the DNS again without needing to run through the settings pages of multiple systems.
So the primary take away here is that you don't need all of the additional hoops or complicated setups to bounce your email around internally, transforming it into something special that can connect to Exchange Online. Simply sending it up to your organizational smart host will do the trick.