SMTP OAuth Configuration Guide

Overview

Microsoft is retiring Basic Authentication (use of Username and Password) for the sending of emails via SMTP to Exchange Online. To maintain secure email functionality, our tools now use OAuth authentication in line with Microsoft’s recommendations.

• Microsoft Announcement - Basic SMTP Auth Retirement

This will affect any customers that have our products / solutions send emails through their Microsoft Exhange platform.

This change requires customers to update their Microsoft Entra (Azure AD) configuration to allow our application to send emails via SMTP using OAuth.

---

Prerequisites

• Access to your Microsoft Entra tenant

• Tenant ID available

• Admin privileges to grant application consent

---

Step 1 : Grant Admin Consent for our OAuth Email Sender App

You must add our multi-tenant Microsoft Entra application - named Navitas OAuth Email Sender to your environment and grant it permission to use SMTP.

Use the following URL (replace placeholders as needed):

https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=56bf2132-e8f1-4084-b809-e0a60225655e&redirect_uri=https://www.navitasonline.co.uk/NavitasOAuthEmailSender&scope=https://outlook.office365.com/.default

Parameters:

• {tenant} = Your Microsoft Entra Tenant ID

• client_id = 56bf2132-e8f1-4084-b809-e0a60225655e

• redirect_uri = https://www.navitasonline.co.uk/NavitasOAuthEmailSender

After visiting the link, sign in as an administrator and approve the requested permissions.

---

Step 2: Choose your Authentication Method

Depending on how you want the application to send emails, different approaches are available. If the solution is a robotic tool then you MUST configure a dedicated email account using Option A.  This is also an option for any tools where you don't want the agents to have to authorise use of their own email account.  For example if you have an email address such as [e-mail] that you want to be used to send all emails, then it can be authorised by following Option A.

You can configure SMTP sending using one of the following approaches :

---

Option A : Dedicated Service/Email Account (No User Interaction)

If you want a non-interactive setup (e.g., for automated systems), you must grant the application full access to a dedicated mailbox.

The steps below achieve the following actions:

• Registering Service Principals In Exchange for the Navitas Entra Email Application

• Granting Permissions for to the Email account for the Navitas Entra Email Application

Reference: https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth#register-service-principals-in-exchange

This process allows the application to send emails without requiring users to log in.

 

Step i: Register the Service Principle in Exchange Online

Unfortuately there is no graphical screens available to undertake the this process.  You will need to use PowerShell and command line entries to undertake this procedure. 

To use the New-ServicePrincipal cmdlet, open an Azure Powershell terminal and install ExchangeOnlineManagement and connect to your tenant as shown below:

1. Connect to Exchange Online PowerShell:

Install-Module -Name ExchangeOnlineManagement -allowprerelease
Import-module ExchangeOnlineManagement 
Connect-ExchangeOnline -Organization <tenantId>

Where <tenantId> is your Microsoft Entra Tenant ID.

2. Register the service principal using the application (client) ID:

New-ServicePrincipal -AppId 56bf2132-e8f1-4084-b809-e0a60225655e -ObjectId <OBJECT_ID> 

Note: In the Entra/Azure portal, make sure you retrieve the Object ID from the Service Principal, under Enterprise Applications, and not the App Registration. e.g. 80c54dc2-3314-4d57-89f3-e2620df95370

---

Step ii: Grant Mailbox Access Permissions

1. You can get your registered service principal's identifier using the Get-ServicePrincipal cmdlet.

Get-ServicePrincipal | fl

This will provide the  <SERVICE_PRINCIPAL_ID> for the application to be used in the following command.
 

2. Grant the service principal permission to send emails as the desired mailbox.

Add-MailboxPermission -Identity "[e-mail]" -User <SERVICE_PRINCIPAL_ID> -AccessRights FullAccess

---

Option B: User-Based Authentication (Interactive Login)

If you prefer to send emails using the consultant's individual user accounts (so the email appears in their Sent Items etc):

• No additional configuration is required beyond admin consent

• When a user sends an email, an interactive Microsoft login prompt will appear. For example :

• The user must authenticate using their Microsoft account

• The authorization is securely cached and does not need to be repeated frequently

---

Notes

• Ensure SMTP AUTH is enabled for the mailbox being used

• Admin consent is required before any authentication method will work

• OAuth tokens are managed automatically by the application once configured