1

Hi experts,

I’m starting with Data classification and DLP in M365 - want to create some basic ones and got a bit confused… I would like to encrypt emails sent to outside of the organization… and looks like there are 3 ways to do it?

  1. LABEL - Create a “Label” that will be used to “Control Access” and allow “Add all users and groups in your organization”. This way if an email is sent outside, the external recipient will not able to read it. I will make the Label mandatory

  2. DLP - create a DLP policy with condition “Sender domain is” (add my domain) and action “Encrypt”.

3.Exchange TRASPORT RULE - with “Apply Office 365 Message Encryption…”

Which one is recommended?
Also, wondering, what happens if I use option 1 and 2 together? :)… Just curious…

This is a pretty basic I would say but cannot find some good explanation on when to use what/why

Btw, I have M365 E3 and M365 E5 Security subscription.

2 Spice ups
2

For clarity, is your plan to encrypt ALL emails outside your tenancy or just defined ones?

3

Some context on each.

Use sensitivity labels when you want fine-grained control over content protection, including encryption. It’s suitable for scenarios where you need different levels of protection (e.g., “Confidential,” “Internal Use Only,” etc.) based on the content.

Use DLP policies when you want to enforce specific rules (e.g., prevent credit card numbers from being sent via email) and ensure compliance. While DLP can trigger encryption, it’s not the primary method for external email encryption.

ETRs with OME are useful when you want a centralized approach to encrypting all external emails. It’s less granular than sensitivity labels but provides consistent encryption for outbound emails.

You can use options 1 and 2 together, however, you may have conflicting rules. If you do this, test thoroughly.

If you can give a little more details on the objective, if you mean all external emails or explicit ones, then this may help you decide which will be best for you.

1 Spice up
4

Make sure you are aware of what the receiving user experience is going to be like if they are not an Office 365 user. Some people may see a message saying they have to sign in to read it and think it’s a phishing attack.

5

thanks for the brief info…

Well, lets consider 2 scenarios:

1 - encrypt all emails that go outside of our tenant
2 - lets say only specific data (sensitive) to be encrypted. With this one, it just came to mind that I can also a Label to apply to email that contains sensitive data, and then create DLP based on that label and encrypt :slight_smile:

…so looks like quite few approaches that can be used

Anyway, when I will configure this for “production” env., looks like a combination of LABEL and DLP will be a way to go… And use labels for encryption (as you’ve mentioned DLP is not primarily for encryption)… and DLP for other control/notification… so that I do not mess it up with sensitive data that are encrypted by Labels and then encrypted again with DLP (such as credit card number or similar)

6

thanks for the links… Was not really aware that the encryption in M365 is not the same and there are two types - “Microsoft Purview Message Encryption” and “Information Rights Management (IRM)”

need to check more on those two…to understand the differences…

1 Spice up
7

btw - I’m not sure if I do something wrong, or why I cant apply “Confidential” label to new emails in my Outlook 365 desktop app.

When I switch to “New Outlook”, it works fine…

Confidential label is set to “control access” and selected “Assign permission now” and permission is configured for “All users and groups in your organization”

Is there any “bug”?.. or why it is working in New Outlook… I have 3 more labels configured with different set up and those are working fine. The main difference is that “Assign permission now” is not configured for those…

8

Are you likely to, or do you have a need to encrypt all emails?

I think you first need to understand what problem you are solving, who this will apply to, then how you will tackle this.

9

Hi Rod-IT,

I’ve just had a chat with stakeholders and we will be encrypting for specific groups… So lets say Confidential and External. So not all emails.

I have created few labels and controlling access/encryption via “Control Access” - which as you mentioned before would be better for fine controlling of data (as eventually I will have to deploy restrictions between departments as well, etc. So I believe I have the right direction to go with…

Would maybe ask two more thing if you could advise -
1- as I’ve read so far, it is not recommended to use a default label that encrypts data. However, I would like to create an “Internal” label that will be accessible with internal users only. I am not sure how to accomplish it as the only way I’ve found is via “Control Access” which will enable encryption by default… Would be great to get an advise on this… Is it true I should not use default label that will do encryption in that scenario? Or it is a good practice to have it encrypted. One of the downside I’ve noticed is that auto-save does not work for documents that have “encryption” label assigned - which is actually one of the main reasons I’m trying to have it non-encrypted.
UPDATE: I guess I’ve found auto-save fix → enabled co-authoring on tenant level. Will give it a day and test it. Or would it be better to have “Internal” label to be placed by default and not configure any “Control Access”, and then use DLP to prevent documents/emails to be sent externally?

2 - we have several external partners (around 30) that we share data with and I want to prevent a data for partener1 to be sent/accessible by partner2 etc. Is the way to achieve it via Label → Control Access → Assign permissions? As there will be quite a few sublabels :)… or DLP are more suitable for this.

Anyway, thanks for your help so far… You’ve showed me the right direction in my starting point with Data Classifications :slight_smile:

10

I would focus on the outbound emails at first, having rules or tags for internal emails, while nice, would be second on my list.

Do be aware that RPMSG emails may need a plugin on the external client and macOS has issues opening these.

There is a plugin, but last time I tried this, it didn’t work for macOS, or specifically didn’t for us.

Do bear in mind users who may be using iPhones, tablets, iPads etc, especially those outside your company.

11

good to know that… Its always useful to get advise from a user that has experience with it! So probably avoid encryption if possible when sharing with external parties as they use macOS ( we are small company but working with quite a few external partners)

just FYI - one of the incident that triggered discussion at our company was that a user send an email to a wrong external party. An email for “abc.com” was sent to “xyz.com”, and my goal is to prevent this to happen again as best as possible. These would be quite granular policies I believe, so want to understand the “basics” as best as possible - get some advise about best practice and what to use for what… such as “do I use label to achieve it?”, “do I use DLP for it?”, “should I use combination?”

Anyway, thanks again and I will continue with my research!

12

If you encrypt an email or mark is as confidential, it applies to the email, so if they send it to xyz.com, it’s private/confidential to them, regardless whether that was the correct address or not.

The system, with or without tags has no idea who the correct person is, so while you add a layer to it, it’s still only valid for the recipient, even if they are technically the wrong one.

Even if your company employed a whitelist of domains, this doesn’t help, the domain might be correct but the recipient wrong, or even the wrong domain, but still one you use frequently.

We tried disabling autcomplete in outlook and found because people have to now type the addresses, more were wrong.

It’s a balancing act.

13

that make sense… Stakeholders have quite nice picture they see about how it should work, however, reality is a bit more difficult to achieve it :smiley:

I was actually thinking of two solutions:

  1. creating labels/sublabels like: External\ABC, External\XYZ and then allow abc.com and xyz.com in those particular sublabels in “Access Control” → “add specific email or domain”… so if data are labelled correctly and sent to wrong recipient, the recipient will not access it…I will end up with several sublabels though

  2. Or create an “External” label and then DLPs with conditions “subject matches word or phrases = abc” AND "recipient domain is = abc.com " then allow send externally. Will need to train users to use key words in Subject then.

both of the above would need just minimal user interaction comparing to label option “Let user assign permission…”

…these are just my thoughts that may go completely wrong when I will be testing it coming days :slight_smile: …

14

Keep us posted.

Keep it simple too, you don’t want too many rules, making it harder for yourself and impossible for users to know how to send an email.

Be mindful as well of any automated systems you have, perhaps your finance package emails out clients bills / PO / fees etc, within these systems you can’t usually apply tags, so you may need sender exclusions or to apply those with a transport rule.

1 Spice up
15

Hi @Rod-IT , @PatrickFarrell

been a while now :slight_smile: … I’ve been dealing with the this project and almost finishing it. I am in testing phase, took your recommendations and trying to keep it as simple as possible to start with. However, I am struggling with sharing documents for external non-Microsoft users.

I have a confidential label that will encrypt data (email, document). Confidential email works fine - as it goes through OTP authentication and external partner can read it. However, this is not the case with confidential documents. From what I’ve read, this is a known limitation as the recipients’ app opening encrypted document MUST support that encryption. So… when I send “confidential” attachment to external partner using google workspace, they cannot open it at all…

Have you had to deal with this scenario? If so, how?

The same seems to be also for “confidential” documents being shared via link from sharepoint directly. They cannot open it.

This is the last part I need to figure out before deploying labels to entire organization. I’ve noticed this behaviour actually when I was recording “user experience” videos for colleagues :slight_smile: … and is now delaying me to finish off this deployment…

hope there is a solution different from forcing our users to change label to PUBLIC :confused: