SMTP Settings
Required Settings for sending E-mail messages
The sender you set on the e-mail process node (from-parameter) must have the same domain as the SMTP server, or the SMTP server must be allowed to send mails on behalf of the sender in the from-parameter.
Per portal you can select which SMTP Server you want to use to send e-mail messages from.
The list of available SMTP Servers was previously managed on Workspace Level (or in DevOps portal for Kubernetes Runtimes). This has changed since 2024-12-12, you can now manage the profiles directly from the Portal Settings, via button [Manage project SMTP servers]:

On the overlay for SMTP Servers, add or edit an entry.

Parameters to set, are:
Host (smtp server hostname, like smtp.gmail.com or smtp.office365.com).
Port (587 is the standard for secure SMTP via TLS).
Username (the account that can connect to the server and has sufficient rights to send messages on behalf of the from-address you want to use in your project's emails).
Password for that username to access the SMTP server.
After one or more SMTP server profiles have been set up, you can pick one on the Portal Settings to be used specifically for sending out E-mail messages using the Email Process Node.
Office 365 Account Settings
If you are using an Office365 account, following info is very important:
The account-username to be used in the WEM SMTP Profile must be an active account in Office365 - you may need to specifically login to Office365 with this account as Microsoft may require this for accounts to be activated and checked with additional information - also check Multi-Factor settings that may cause issues when an application acts as non-interactive-user. This account may be setup as a non-personal account (like smtpsender@yourdomain.com).
The Office365 Account must have a valid office license with a mailbox (so you can also see the Sent Items there and useful info like non-delivery-reports).
The Office365 Account has permissions or aliases to send on behalf of all the addresses used in the FROM parameter of the email nodes in your application (like noreply@yourdomain.com).
The Office365 Account must be setup using MFA and an App Password must be created. This App Password must be used in the WEM SMTP Profile Settings. This is necessary to work around the required Multi Factor Authentication and to enable another application like your WEM Runtime Portal to login to Office365 bypassing the MFA.
Read this link from Microsoft about how to set up App Password.
SMTP with OAuth2
On our Kubernetes Runtimes with minimal version 5.3.0, we now support SMTP with OAuth2 authentication.
These settings can only be managed in the DevOps Portal (and will be available on runtimes that support this feature), and projects should have the option "Publish DevOps Settings" disabled (see manage hostnames on portal settings). If Publish DevOps Settings is still enabled, the publish action will clear the settings in DevOps Portal.
When you do have a mailserver that supports SMTP with OAuth2 authentication (like Microsoft365), you need to follow its guidelines on how to correctly setup this feature. For Microsoft, it requires quite a few technical steps (including some PowerShell Commands).
When the "App Registration" is ready, you (or your WEM DevOps Administrator) can setup the profile:
PER Application specifically, or
As Standard Global Runtime Setting - available to all projects on that runtime that do not have their own specific SMTP Settings.
The Settings screens looks like (with example settings from Microsoft365):

For Microsoft, it is important to include the OAuth Scope as indicated (without it, the mail action will log a Bad Request). Other provides may have different requirements for their Scope.
The OAuth Email can be a specific email account that is only used for the OAuth registration. It does NOT have to be used as the FROM (Sender) in the Email Node, BUT the OAuth Email MUST be specifically permitted to send messages on behalf of the FROM used in the Email Nodes.
The Client Secret (at least in Microsoft365) has a forced expiration date. Microsoft does NOT send out reminders to update your Client Secrets - you need to somehow log it and create your own reminders to renew Client Secrets in time. This means a new secret should be created with a new expiration date and has to be changed in all the applications that use this feature. You cannot reuse the same secret and just change the date. Or you can choose to set a very long expiration date - which is not really the recommended way. So - if you are using OAuth for SMTP, and at some point it seems to stop working: most likely the Client Secret has expired. Check the Mail Log in the DevOps Portal and check the registration in the SMTP provider environment.
Last updated
Was this helpful?
