E-mail delivery (Microsoft Entra ID)

Send platform e-mail from your own Microsoft 365 mailbox.

By default, the e-mail your 3rdRisk environment sends — assessment invitations, reminders, notifications — comes from a 3rdRisk address. If your organisation uses Microsoft 365, you can have it sent from one of your own mailboxes instead, through Microsoft Entra ID, so that recipients see a sender they recognise and the mail leaves through your own tenant.

This article covers that route. The alternative adds DNS records to a sending subdomain instead of using an app registration, and is described separately.

Overview

You register an application in Microsoft Entra ID, give it permission to send mail, and send us four values through a secure channel. We then configure your environment to send through it. No DNS changes are needed, because the mail leaves from your own tenant rather than from ours.

What you need: an Entra ID role that can create app registrations and grant admin consent, and a mailbox to send from.

Note: 3rdRisk configures the delivery itself. There is no e-mail setting in the platform for this — you create the app registration, send us the values, and we complete it from our side.

1. Register the application

Sign in to the Microsoft Entra admin center with an administrator account and open Identity, then Applications, then App registrations, then New registration.
Enter a name that makes its purpose clear, for example 3rdRisk – Mail.
Select Register.
On Overview, copy the Application (client) ID and the Directory (tenant) ID.

Note: this must be a separate registration from the one you may already have for single sign-on. Sharing one application across both is possible but makes the permissions harder to reason about, and rotating the secret for one then breaks the other.

2. Grant permission to send mail

In the application, open API permissions.
Click on Add a permission, choose Microsoft Graph, then Application permissions.
Search for Mail.Send, tick it, and Click on Add permissions.
Back on the list, Click on Grant admin consent above the table, and confirm.

The permission must be an application permission rather than a delegated one, because the platform sends mail on its own without a signed-in user. Admin consent is required and the permission does not take effect until it is granted.

Note: as granted, Mail.Send allows the application to send as any mailbox in your tenant. See Restricting which mailbox it can use below if that is broader than you want, which for most organisations it will be.

3. Create a client secret

Open Certificates & secrets, then New client secret.
Give it a description and an expiry period.
Copy the secret Value immediately.

Note: the Value is shown only once, right after you create it. If you navigate away before copying it, delete it and create another — the Secret ID shown afterwards is not the secret. Make a note of the expiry date, because mail stops being sent when the secret lapses.

4. Send us four values

Send these to your Customer Success Manager, or to 3rdRiskSupport@diligent.com, through the secure channel they provide:

Value	Where it came from
Application (client) ID	the Overview page in step 1
Directory (tenant) ID	the Overview page in step 1
Client secret	the Value from step 3
Expiry date of the secret	the expiry you chose in step 3
The mailbox to send from	a mailbox in your tenant, for example `compliance@your-company.com`

We configure your environment and confirm when it is live.

Note: never send the client secret by e-mail, chat or in a document. Use the secure channel your Customer Success Manager provides. Send the expiry date with it, so we can arrange renewal before it lapses rather than after mail has stopped.

Restricting which mailbox it can use

Mail.Send as an application permission is tenant-wide: as granted, the registration can send as any mailbox. Most organisations narrow that to the single mailbox we send from, using an application access policy in Exchange Online.

Create a mail-enabled security group containing only the mailbox you want the application to send as.
Using the Exchange Online PowerShell module, run New-ApplicationAccessPolicy for the application's client ID, scoped to that group, with an access right of RestrictAccess.
Verify the result with Get-ApplicationAccessPolicy, and test it with Test-ApplicationAccessPolicy before you rely on it.

This is optional as far as the integration is concerned, and strongly worth doing. Microsoft documents the cmdlets, and you need the Exchange Online PowerShell module and administrative privileges to run them.

Known limitations

Mail stops when the secret expires. There is no warning from the platform. Send us the expiry date, and renew before it lapses.
The permission must be an application permission, admin-consented. A delegated permission will not work, because no user is signed in when the platform sends.
The send-from mailbox must exist in your tenant and, if you apply an access policy, must be inside the group the policy allows.
One sender per environment. All mail for an environment leaves from the same mailbox.
This changes who mail comes from, not what it says. The wording of the messages is configured separately.

Learn more about the content of the messages: E-mail templates