Can delegated Mail.Send be used as a background service?

Question

We do not generally have a logged in user account when sending these emails (it occurs in the background).

As a daemon application, there is no identity logging into the service.

Is it possible to use delegated mail.send in a daemon application?

Answer 1

Hi @Adam Day

The delegated Mail.Send permission certainly cannot be used as a background service. Delegated permissions are usually used in scenarios that require user interaction, and are not suitable for daemons.

Server-to-server interactions are only supported with application permissions. So please grant the mail.send application permission to your application, then your application will be able to send emails on behalf of other users without the user logging in.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

The delegated Mail.Send permission can absolutely be used by a daemon/background service.

You will however need to get the initial Refresh and Access tokens interactively (i.e. by using the Auth Code Flow) and store/cache them. (You need the "offline_access" permission in your app registration and scope to ensure you get a Refresh token, otherwise you won't be able to persist your access without the user account having to log in all the time.)

The daemon can then use the cached access and refresh tokens. It will need to ensure the refresh token does not expire by requesting a new one as needed and updating the cache accordingly.

The interactive step will need to be performed again if the access/refresh tokens become invalidated (i.e. because the user reset their password, forced a signout, ...) so it's recommended to use a specific account with a long lasting password, ...