5 ways to set the from field when sending mail from Office 365 / Azure infrastructure
My goal is to send customers a notification on the status of their interaction with my Tenant via an App Auth Only application. Let’s say that the an anonymous user submits an form to a SharePoint list. I don’t want them to see no-reply@sharepoint.com e-mail address in the confirmation e-mail from field. Here are some options.
#5: Twilio’s SendGrid and other 3rd party service.
SendGrid gives Azure account holders 25K monthly e-mail messages for free. This, and other services are great, but, what if my tenant prefers direct control of their communication infrastructure. I know it’s silly, they’re already on Azure, but what can you do.
#4: On-prem SMTP Service.
This is the most interesting and bizarre option at the same time. We’re abandoning the cloud and setting up our own SMTP server on internal network just to send out mail? SMH. But fine, let’s just see what we need to make that happen. VPN, Express Router or a number of things to connect the cloud service to our internal network. That’s it.
Dos and Dont’s
Please don’t open any ports on your network just for mail.
Do take your compliance person to lunch and beg them to consider a 3rd party service.
#3: Flow actions.
We now have two options with Flows. The Send Mail action in advanced mode has a From field that can be set to an e-mail address the user has permissions to send as or send on behalf as. A shared mailbox is a great way to utilize this field.
The other option is the Send from a shared mailbox action. Same idea. Got both of them working very quickly.
#2: SharePoint 2010 Workflow.
No control here what so ever. Combine that with Microsoft won’t let SharePoint Workflow 2013 send e-mail to non-domains addresses and that Flow is the future, Workflows are out.
#1: A queue service
Imagine pushing e-mail messages to a queue service, then using another application on your network to collect the messages and send them out without needing to link the cloud and your internal network? Neither can I. Absolute overkill, unless it’s part of an elaborate product or service offering. Even then, See #5 as a viable option.
Shared Mailbox setup.
Have an admin do these steps, unless you’re the admin, in which case… In O365 Admin, go to Groups, Shared mailboxes. Create a new mailbox, or edit an existing one. Change the shared mailbox permissions for the account used to create the Flow.
Public Service Announcement: Please avoid hard-coding user names and passwords and gateways in your code. Product or program managers should have the power to make changes to something as simple as an e-mail account. Plus, do you really want a password to an O365 account in your source code? Just don’t. Do make services interchangeable and pluggable.
References:
Sending Email from Web App using On-Prem SMTP Server and Storage Queue Relay
Leave a Reply
Want to join the discussion?Feel free to contribute!