Understanding Secure Collaboration Gateway Logic

This document explains how eShare's Secure Mail Gateway (SMG) decides whether an outbound message gets secured, and what a recipient sees when it does. It's intended for anyone who needs to understand SMG's behavior — for example, when troubleshooting why a message was or wasn't secured. For setup instructions, see the separate SMG configuration article. The following will be reviewed:

• How SMG Decides What to Secure

• Pass-Through Scenarios

• Internal Recipients

• Custom SMG Templates

How SMG Decides What to Secure

A message can reach SMG one of two ways: it carries a Microsoft Purview sensitivity label, or it matches an Exchange mail flow rule that's been set up to route traffic through SMG. Either way, SMG checks it against your Sharing Policies — header name and keyword value first, then sensitivity label as a fallback — and if there's a match, that policy governs what happens next: whether the message body gets secured along with attachments, or just the attachments, and what permissions and expiry the resulting Trusted Share has.

How the Header/Keyword Match Works:  SMG has no visibility into your Exchange rules on its own — the connection between Exchange and a Sharing Policy is a value, not a shared setting. On the Exchange side, a mail flow rule inserts a specific name and a value — typically into a message header, though it can also be placed in the subject or body — onto any outbound message that meets the conditions you've defined there (sent externally, has an attachment, and so on). On the eShare side, inside a Sharing Policy, a header or body name and Keyword field holds that same value, along with where SMG should look for it: in the subject, the body, the header, or a combination.

For a match to happen, both sides have to agree exactly:

• The value in the Exchange rule and the Sharing Policy's  name and Keyword field must be identical, character for character.

• The location SMG is told to check (subject, body, or header) must match where the Exchange rule actually inserts the value.

If either side is off — a typo in the value, or Exchange inserting it into the header while the policy is set to check the subject — SMG won't recognize the message as belonging to that policy, and it falls through to the next check (or to no match at all, if nothing else applies). This is also why changing what SMG secures always means touching both sides: the Exchange rule's conditions and value, and the corresponding Sharing Policy's 'Keyword' field.

The diagram below walks through the full decision path, end to end.

Pass-Through Scenarios

Even when a message matches a Sharing Policy, SMG won't create a Trusted Share if there's nothing meaningful to secure:

Handling Internal Recipients

When a message that SMG secures also has internal recipients — for example, a colleague copied on an email to an external partner — a policy setting determines whether they're treated the same as external recipients. If so, they also get the Trusted Share or eShare link. If not, they get the original, unmodified email instead. This only applies when SMG has actually created a Trusted Share; if nothing needed securing, everyone gets the unmodified message regardless of this setting.

Secure Message Body

• When 'Secure message body' is on, both the message body and any attachments are secured. The recipient must open the Trusted Share to read the message text — it is not visible in the email itself. This applies even when there is no attachment at all; a Trusted Share can be created purely to secure the message body.

• When 'Secure message body' is off, the message body is left as sent, and only attachments and native links are replaced with eShare links.

Custom SMG Templates

By default, SMG-secured messages use eShare's standard email templates. A Sharing Policy can instead be assigned a custom template set, changing the look and wording of the notification — this only affects presentation and has no bearing on the matching or securing logic described above.