Mail server connection

A mail server connection holds the settings used to send mail from a Mail action in a workflow or a Mail transform in a pipeline. You edit it in the Metadata perspective.

Besides the classic SMTP protocols, a connection can send over Microsoft 365 by choosing the GRAPH protocol.

Choosing the protocol

The Protocol list decides how mail leaves Deem Integrator:

Protocol	Use it for
SMTP / SMTPS	A classic mail server, with or without TLS
GRAPH	Microsoft 365, using an app registration instead of a mailbox password

Picking GRAPH shows the Microsoft 365 fields and hides the SMTP ones. The SMTP values are kept, not deleted — switching back to SMTP brings them all back. They are hidden rather than greyed out, because a visible-but-unused host name reads as if it were still in effect.

Note

Existing connections are unaffected. The Microsoft 365 fields were added alongside the old ones, so connections made before this change load and run exactly as before.

Microsoft 365 fields

Field	Where it comes from
Tenant id	Your Entra ID (Azure AD) tenant
Client id	The app registration
Client secret	The app registration
Sender	The mailbox mail is sent from

Set-up on the Microsoft side:

1. Register an application in Entra ID.
2. Grant it the application permission Mail.Send, and give admin consent.
3. Create a client secret.
4. Add an application access policy in Exchange Online that limits the app to the mailboxes it is allowed to send as.

Caution

Step 4 is not optional in practice. Mail.Send as an application permission otherwise allows sending as any mailbox in the tenant.

Deem Integrator fetches and refreshes access tokens by itself. Nothing needs renewing except the client secret, which expires on the schedule you set in Entra ID.

Testing the connection

Two buttons, doing different things:

Test checks that the credentials work. For a Microsoft 365 connection it fetches an access token and stops there — no mail is sent. This catches a wrong tenant id, client id or secret, and missing admin consent, which are the usual causes of failure.

Send test mail actually sends one. Fill in From, To and Subject; the body is a fixed ping. From is prefilled from the connection. The dialog uses the values currently in the editor, including changes you have not saved yet, so you can try a setting before committing to it. It stays open after sending so you can correct something and try again, and it works for both SMTP and Microsoft 365.

Using it

Nothing changes in the Mail action or the Mail transform. Point them at the connection as before, and the protocol on the connection decides how the message is delivered. Message content, attachments and formatting are identical either way.

Tip

A useful migration path for a Microsoft 365 customer: change one connection to GRAPH, verify it with Send test mail, and leave the rest on SMTP until you are happy. Nothing is shared between connections.

Troubleshooting

• Basic authentication is not supported from an SMTP connection means the Microsoft 365 tenant has turned off basic authentication. Move that connection to GRAPH.
• Test fails but the settings look right — check that admin consent was granted for Mail.Send, and that the secret has not expired.
• Test passes but Send test mail fails — that points at the application access policy, or at a sender mailbox the policy does not cover.
• A message over roughly 4 MB, including attachments, is rejected on the Microsoft 365 route.