This article takes you through how to integrate your own SMTP server to be used for all emails sent by Enboarder!

These emails include notifications sent to workflow stakeholders, emails sent to Admin users, emails from the communication module, integration updates, and other alert emails.

Before you begin: Like anything worth doing, integrations take time. Please allow up to 4 weeks for this integration to be completed, this includes time for scoping, development and testing. You’ll also need to have a system expert and/or system administrator to assist in the completion of this integration.

Prerequisites

Before integrating, you'll need to get the below details from your IT team, or pass this article to them to help you get set up!

Details of any restrictions on the SMTP server. These restrictions may include sender and recipient email ids having to be valid on a particular domain (example: @corp.com), attachment file types, etc. This is very important and these may impact the delivery of emails or notifications that have been sent by Enboarder.
If the SMTP server needs to allowlist IPs that can send messages, please pass these details to your Customer Success Manager to review before proceeding with any further steps.
Gather the technical details of the SMTP server. These include the server name/IP, port, username, password, use TLS. You can add these details in Enboarder and set this up yourself. (Please note: if your SMTP needs to allowlist IPs, you'll need to wait on this step until your Customer Success Manager gives your the green light.)

Here is a questionnaire to help gather these details

SMTP Restriction	Yes/ No	Details
(From / Sender) Email ID
(To / Recipient) Email ID
Attachment types allowed
Attachment sizes
IP allowlisting needed

Consider setting up SMTP on your account during a time frame when normal emails may not be sent usually, such as weekends, late evenings, etc. This way, you can run a set of tests to ensure that the SMTP server if having restrictions works well with scenarios where Enboarder sends out emails. The set of tests will be explained in the SMTP Server Integration Tests section at the bottom of this page.

IP Allowlist Process

Below is the list of Enboarder IP addresses that need to be allowlisted through your companies mail server by region, in case you have restrictions for IP addresses:

3.105.45.51 Sydney
44.233.236.201 Oregon
3.97.171.129 Canada
3.64.222.166 Frankfurt

A note for Office 365 setup

Office 365 does not support userid/password authentication for new connections from May 1, 2023. For all new connections with Office 365, please see the next section for detail to set up OAuth2 authentication. Please refer to this Microsoft documentation for more detail.

Steps to set up OAuth2 in Office 365

Please skip this section in case user/password is working with your Office 365 setup. This step is required only if you are using Office 365 and want to use OAuth2 for SMTP authentication.

You will need to perform the below two steps to set up OAuth2 authentication:

App registration in Azure AD portal
Set up custom tile in Enboarder

App registration in Azure AD portal

The organization must have an admin account in Microsoft Azure and have all users set up in Microsoft Azure directory
The admin user must set up an application for one or more tenants in https://portal.azure.com and register it to set up OAuth flow
Login to the Azure portal. Go to Azure Active Directory → App registration → New Registration

Set up the following properties of this app:

Name - Enter a meaningful application name that will be displayed to users of the app. Example: Enboarder-SMTP
Supported account types - Select which accounts you would like your application to support based on requirements.
- Accounts in this organizational directory only
- Accounts in any organizational directory
- Accounts in any organizational directory and personal Microsoft accounts
Redirect URI (optional) - Select the type of app - Web or Public client (mobile & desktop), and then enter the redirect URI (or reply URL) for the application.
- Please select web as the app type
- Put value https://auth.enboarder.com/oauth

The following permissions should be enabled for Microsoft Graph API and the admin user should provide consent for the same:
- Application Permission
  - Mail.Send
  - user.read
After the application is registered, please generate the client secret:

Setup in Enboarder:

Once the feature is enabled by our Support Team, you can log in as an Admin user with a role that can assess Integration settings into Enboarder.

Step one (if using OAuth authentication):

Set up custom tile in Enboarder

Go to settings → Apps and Integrations → App center page
Click on the 'Add new' tile

On the next page, fill out the information as per the below:

Field Name	Detail
Application Name	The display name of tile. You can put any name.
Oauth2 Token URL	`https://login.microsoftonline.com/{{tenantid}}/oauth2/v2.0/token`
Oauth2 Client ID	The `client_id` generated in Microsoft Azure AD app.
Oauth2 Client Secret	The `client_secret` generated in Microsoft Azure AD app.
Oauth2 scopes	`https://graph.microsoft.com/.default offline_access`
Oauth Flow option	Please select client credential option.

Click on Add integration
The system will generate the token and save it
Once done, the system will show the tile as integrated

Step two:

Navigate to Settings (Right top corner icon) > Integrations > Our Extensions > then click on the "Custom Email Server" icon.

Please click on ‘SMTP settings' where you will see a pop up:
- You will see 2 options
  - Basic authentication
  - oauth2

Please select OAuth2 only if you are using Office 365 server smtp.office365.com for new connections after May 1, 2023.

Please double-check the details to ensure accuracy. Use the ‘Test connection’ button to validate the details before saving.

OAuth2

If you are using OAuth2, the user and password fields will be removed and a 'Select integration type' list will be available, which lists all custom integrations added using Add new option in app center page.

Add the values below and test the connection. if successful then save it:

server address - smtp.office365.com
port - 587
select integration which is added specifically for SMTP oauth2
Default sender address - this should be valid admin user email id in Azure portal.

Steps for SMTP servers with sender and recipient restrictions

SMTP servers may have the following type of restrictions on the email IDs of senders and recipients.

No restrictions. This requires no further steps. All good to go.
Both sender and receiver email ids have to be actual email ids of certain domains, such as the corporate domain. In this case, participants like new starters who have given their personal emails, won’t work. Kindly discuss with your SMTP provider on this and get it sorted out before using it with Enboarder.
Either sender or receiver email ids have to be actual email ids of certain domains like the corporate domain. In this case, follow the below steps.

1. From email ID for notifications, reminders to stakeholders

Designate an appropriate email id, most likely your corporate or company domain. Stakeholders who receive the email will see this email id and the name associated as the sender for these emails.

You will need to contact our support team to have the sender email address updated. This will be displayed in Settings > General Setup > Branding.

For all brands, including the default, kindly set up the ‘Sender email address’ with a valid email id that is allowed by the SMTP server. This ensures that emails via SMTP server work fine when sent to recipients with other domains in their email ids.

2. From email ID for Admin and Integration emails

Kindly share the email ID with our Support Team.

SMTP Server Integration Tests

Consider setting up SMTP on your account during a time frame when normal emails may not be sent usually like weekends, late evenings, etc. This way, we may run a set of tests to ensure that the SMTP server if having restrictions works well with scenarios where Enboarder sends out emails. The set of tests will be explained below.

Notification and Stakeholder emails

Consider using all the below tests for recipients who use personal or non-corporate email-ids.

Notification
Communication module
Event or Calendar invite module
Send data email sent to personal email-ids with file attachments in the email
Forms with file uploads that are forwarded to personal email-ids

Admin emails

Consider using all the below tests if admin users will be created with personal email-IDs. In most cases, they won’t, so the below would not be required.

Create a new admin user with a personal email-id and check if the email-id receives the email to set up the password and log in.
Try the forgot password scenario to see if the email-id receives the email to set up the password and log in.

All done! If you have any questions pop them in the Chatbot within the system and we will be in touch.