Skip to content

How the Product Works with MS Exchange EWS


Revenue Inbox is designed to run concurrently with other processes engaging a mail server’s Exchange Web Services (EWS) and provides the customers with the necessary controls regulating EWS access by Revenue Inbox.


What EWS access control tools allow:

Different deployment options

Revenue Inbox supports Multi-Tenant, Single-Tenant, and On-Premise scenarios.

  • These scenarios imply various levels of data and configuration isolation between tenants: logical isolation for Multi-tenant instances, physical isolation for Single-tenant instances, of full customer control for On-premise deployments
  • As a best use practice, Multi-tenant deployment is recommended as the most cost-efficient one for an average customer, also providing a solid level of security. Other options should be considered if specific security requirements prohibit Multi-tenant operation in your Org


IP Address restrictions: Revenue Inbox operates via a fixed set of IP addresses

The customers using corporate firewall IP address restrictions for Salesforce or MS Exchange servers connection need to allow-list specific IP addresses used by Revenue Inbox.

  • Such whitelisting is complementary, it does not block any existing server traffic

  • See more details on configuring IP restrictions and the list of IP addresses used in Multi-tenant environments here

  • For Single-tenant configurations a specific list is communicated during Revenue Inbox deployment

  • As a best practice, such configuration should be added over the current customer configuration, to prevent interfering with existing traffic


Filtering Revenue Inbox EWS traffic Revenue Inbox

Filtering can be configured to use a pre-set UserAgent header on every EWS call made to the customer’s MS Exchange server. Such configuration allows traffic filtering on multiple levels:

  • On MS Exchange / Office 365 side: using MS Exchange controls, as documented here

    • This configuration control allows additive listing of allow-listed applications, and if used by in a customer’s Org it may be extended to include traffic from/to Revenue Inbox
  • By a stateful firewall which can block HTTPS traffic

    • As in the above case, a custom rule can be built based on an added UserAgent HTTP header to allow Revenue Inbox-originated EWS traffic pass through, in addition to any other allowed traffic
  • The value of the UserAgent header for all EWS traffic can be set as requested by a customer

  • As a best practice, customers who already implemented EWS traffic filtering using one of the above approaches should consider extending their configuration to allow Revenue Inbox EWS traffic


Allow EWS Access for a specific list of mailboxes only

In some configurations, Revenue Inbox can use Exchange Impersonation and communicate with MS Exchange server through pre-configured Service Accounts.

  • If EWS are not used in any other way in a customer’s configuration, then only specific mail accounts which need EWS access may be enabled to access them, in particular an Impersonating account set up for Revenue Inbox
  • Refer to this Microsoft article for details on enabling EWS access
  • Note that certain Revenue Inbox functions may be not supported for this configuration (e.g. the Add-In will not be available, refer to this article for more information), contact our CSM team for details


Best practices configuration flow
  • Choose the Revenue Inbox deployment model that suits your Org’s needs
  • Decide whether Revenue Inbox IP address filtering shall be configured in your Org
  • Decide whether Revenue Inbox EWS traffic filtering shall be configured in your Org
  • Decide which user authentication model shall be used in your organization: whether the end users will sign in to MS Exchange or Office 365 themselves, whether Exchange Impersonation and Service accounts will be used, and whether the RI Outlook Add-In will be used; depending on that EWS access may be allowed only for a Service account authenticating a list of end users


EWS connection allows to establish MS Exchange or O365 (With Exchange Online) servers access to all data types at once: Emails, Calendar, Tasks, Contacts. The permissions set is called EWS.AccessAsUser.All; in contrast to MS Graph O365 access EWS does not have a technical possibility to limit access to specific data types.

>>> Click to see a screenshot <<<


Also see this FAQ entry for more information and this article to learn how to resolve the “Need Admin Approval” error.



Customized data type specific access to mailboxes on O365 servers is available for big Enterprise customers over MS Graph connection. See this article for details


Get back to us
We would love to hear from you



Question or comment: