.png)
Securing Email Integration: Authentication, Permissions, and Data Access
Conexiom’s secure email integration (currently supporting Microsoft 365) is designed for minimal access, full auditability, and future extensibility.
Security Overview
Conexiom’s email integration is designed to securely connect to customer mailboxes using industry‑standard authentication and access controls.
The integration currently only supports Microsoft 365 mailboxes using the Microsoft Graph API. Customers may access these mailboxes through Outlook or other compatible email clients, but integration access is governed at the mailbox and API level, not by a specific email application.
The architecture and security model are intentionally designed to be extensible, allowing Conexiom to support additional email platforms in the future while maintaining the same principles around scoped access, minimal permissions, auditing, and revocation.
Authentication and Token Handling
Conexiom never handles or stores customer passwords or mailbox credentials.
In the current Microsoft 365 implementation, when a customer grants access, Microsoft issues an authorization code. This code is exchanged via OAuth 2.0 for access and refresh tokens, which are used to authenticate calls to the email provider’s API (currently Microsoft Graph).
Tokens are encrypted and stored securely and are used solely to provide authenticated, scoped access to the specific mailbox that granted consent.
Permissions and Access Model
Conexiom follows a least‑privilege, delegated access model.
In the current Microsoft 365 implementation, delegated Microsoft Graph permissions are used, meaning access is limited to the individual mailbox that authorizes the integration. No tenant‑wide or organization‑level access is granted.
The permissions currently required are:
Mail.ReadWrite
Required to read email messages and apply categories to them.MailboxSettings.ReadWrite
Required to create mailbox categories before applying them to messages.offline_access
Required to maintain authenticated access using refresh tokens without repeated user interaction.
These permissions apply at the mailbox level and are independent of the email client used to access the mailbox (for example, Outlook).
Mailbox Actions and Visibility
Conexiom’s access to customer mailboxes is effectively read‑only, with one controlled exception.
In the current Microsoft 365 implementation, the integration creates two dedicated mailbox categories:
Sent to Conexiom
Not sent to Conexiom
Relevant emails are tagged with one of these categories so customers can clearly see how messages were handled when viewing their mailbox.
Aside from creating these categories and applying them to emails, Conexiom does not send, delete, move, or otherwise modify email messages or mailbox configuration.
Data Access, Notifications, and Filtering
Conexiom operates as a passive listener.
In the current Microsoft 365 implementation, the email provider sends notifications when new emails arrive in the subscribed mailbox. Conexiom does not continuously poll or scan mailboxes.
Only emails that pass the filters configured in the Conexiom Portal are retrieved and processed. Emails that do not meet configured criteria are ignored and are not ingested.
Once an email passes filtering, it follows Conexiom’s standard email ingestion, validation, and routing pipeline.
Auditing and Operational Visibility
All notifications, filtering decisions, and routing actions are logged and associated with trace identifiers. This provides auditing and troubleshooting visibility without expanding mailbox access scope.
Access Revocation and Lifecycle Management
Access can be revoked at any time through the Conexiom Portal or through the email platform’s administrative controls (for example, Microsoft 365 or Azure AD for the current implementation).
When access is revoked:
Subscriptions for email notifications are removed
Access and refresh tokens are invalidated
Conexiom can no longer receive notifications or access mailbox data