Why your DLP policy isn’t DLP (and how to fix it in Microsoft 365)

Most SMBs think they’ve “done DLP” because they ticked a box in Exchange.

They scan outbound email.

They block the occasional credit card number.

They call it done.

That’s not DLP. That’s transport filtering.

Real data loss doesn’t just leave through email anymore. It walks out via USB, clipboard, browser uploads, and users who don’t realise they’re doing anything wrong.

If you’re only protecting email, you’re protecting yesterday’s risk.

The shift is simple: stop thinking about where data leaves, and start thinking about where data lives and how it’s used.

What is Microsoft Purview DLP, really?

At its core, Microsoft Purview DLP is a policy engine that watches how sensitive data is used and shared, then steps in when it shouldn’t be.

Not just email. Not just files.

Behaviour.

It looks across Microsoft 365 — Exchange, SharePoint, Teams — and now endpoint devices as well.

That matters.

Exchange DLP scans emails and attachments and enforces actions.
Endpoint DLP extends this to USB copies, printing, clipboard, and uploads.

“We’ve got DLP on email, so we’re covered.”

No, you’ve just moved the problem somewhere else.

Data will always find another path out.

Step-by-Step: building a real DLP policy (Exchange + endpoint)

1. Go to the Purview portal

Navigate to Data loss prevention → Policies → Create policy.

2. Choose your locations

Select Exchange Online and Devices.

3. Define what matters

Use built-in sensitive information types and add context like external recipients.

4. Choose actions that teach

Warn, block, or allow override with justification.

5. Turn on endpoint coverage

Monitor and control how sensitive data is used directly on devices.

User copies sensitive file to USB → Block
User uploads to personal cloud → Block
User tries to email externally → Warn or encrypt

Notice what’s missing?
Separate tools.

Why this actually changes behaviour

Most security controls are reactive.

DLP — when done right — isn’t.

It works in the moment.

That’s the real win.

Instead of cleaning up incidents, you prevent them.

And you educate users while they work.

“Why did that get blocked?”

Now you’ve got a conversation instead of a breach.

My recommendation?

Start with one policy that covers Exchange and Endpoints. Run in audit mode. Then enforce.

Security doesn’t fail at the perimeter anymore. It fails in the moment of use.

DLP isn’t there to watch data leave.
It’s there to stop it leaving in the first place.

Exchange Online Protection anti-spam / anti-phish policy stacking

Most people think email security in Microsoft 365 is a switch. It’s not. It’s a stack.

And the stack runs in an order you don’t get to vote on.

I see the same thing on tenant after tenant. Someone opened the anti-spam policy years ago, nudged a slider, ticked a box they’d read about on a forum, and walked away. The default phishing policy has never been touched. Connection filter? Empty. Then a dodgy invoice lands in the MD’s inbox and everyone’s surprised.

Here’s the part that catches people out. Those custom tweaks you made? They might be the reason the bad mail got through.

Stop hand-building policies. Turn on the presets and learn the order things fire in. That’s the whole job.

What is policy stacking, really?

Every inbound message runs a gauntlet. Connection filtering checks the source IP. Anti-malware scans the payload. Anti-spam scores the content. Anti-phishing checks for spoofing and impersonation. Each layer has its own policy, and each policy has a priority number.

That’s not one setting. That’s five layers, each with its own verdict, stacked on top of each other.

The catch is precedence. When two policies could apply to the same person, only one wins — the one with the highest priority. Your hand-rolled custom policy beats the preset. The preset beats the default. So if you built a loose custom anti-spam policy back in 2021 and switched on the Standard preset last week, the custom one still wins. The preset you thought protected everyone is being skipped for those users.

Microsoft lays out the full order of precedence — read it once and it’ll save you a dozen support tickets.

Step-by-Step: turn on the stack

You do all of this in the Microsoft Defender portal. No PowerShell. No Exchange admin center.

Open the presets

Go to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Preset Security Policies.

Turn on Standard for everyone

Flip Standard protection to On and apply it to All recipients. That covers anti-spam, anti-malware, anti-phishing — and, if you’re licensed for Defender, Safe Links and Safe Attachments — all on Microsoft’s recommended settings, all maintained for you.

Turn on Strict for the people who get targeted

Flip Strict protection on and scope it to the MD, finance, payroll, and anyone with signing authority. Strict catches more and complains more. That trade is worth it for the accounts attackers actually go after.

Add your impersonation names

In the Strict wizard, add the names and addresses of your VIPs to impersonation protection. This is the bit that stops “Hi, it’s the boss, can you buy some gift cards.”

Delete the cruft

Go back to your custom anti-spam and anti-phishing policies. Any old one that’s weaker than the preset is now a hole. Remove it, or you’ve armoured the front door and left a window wide open.

Notice what’s missing from that list?

Inbound mail flow:
  Connection filter → Anti-malware → Anti-spam → Anti-phishing

Standard preset  → All recipients
Strict preset    → VIPs + impersonation list

No sliders. No SCL thresholds. No ASF tick-boxes you read about once and never quite understood. The presets carry all of that, and Microsoft updates them as the threats move. You’re not tuning a spam filter any more. You’re choosing who gets the strong one.

Why this actually changes behaviour

“We’ve always had email security on.”

Sure. But “on” and “correctly ordered” are two different sentences. Most tenants I audit have layers fighting each other — a custom policy quietly overriding the preset, an exclusion nobody remembers, a default policy doing the bare minimum for half the staff.

Presets end that argument. Everyone gets a known-good baseline. Your VIPs get more. And because the settings aren’t yours to drift, the config still makes sense in two years when someone else opens it.

For an MSP, that’s gold. You deploy the same posture across every client in an afternoon, document it in one screenshot, and stop defending slider choices in a review. Consistency is a security control. Drift is the vulnerability.

If you’re still hand-tuning spam policies client by client, you’re doing unpaid work that makes them less safe.

Turn on the presets. Fix the order. Delete the rest.

That’s not a spam setting. It’s a security baseline — and it’s already in the licence you sold them.

Tuning Safe Links and Safe Attachments in Defender for Office 365 Without Breaking Your Tenant

If you’re running M365 Business Premium for clients, Safe Links and Safe Attachments are already doing work — whether you configured them or not. The Built-in protection preset applies to every mailbox the moment Defender for Office 365 is licensed. The question isn’t “is it on?” — it’s “is it tuned for the way your client actually receives mail?” Out of the box, it’s closer to a safety net than a security control.

Prerequisites MSPs skip

Before you touch a single policy, confirm three things. First, mail has to flow through Exchange Online Protection. Hybrid tenants with a third-party gateway in front (Mimecast, Proofpoint, anything rewriting URLs) will often cause Safe Links to skip wrapping — Microsoft explicitly warns that pre-wrapping can prevent Safe Links from processing the link at all. Second, confirm licensing: Safe Links and Safe Attachments require Defender for Office 365 Plan 1 (included in Business Premium). Plan 2 features (Safe Documents, Threat Explorer real-time detections) need separate entitlement. Third, set quarantine notifications up before you tighten policies — users need end-user spam notifications or a quarantine policy with access enabled, or your service desk gets the entire phishing queue.

Where to configure — Standard preset, not custom, 90% of the time

The Microsoft Defender portal is your canonical surface: security.microsoft.com → Email & collaboration → Policies & rules → Threat policies. From there:

Preset security policies for 90% of clients. Enable Standard, assign to all recipients by domain.
Safe Links and Safe Attachments tiles are for custom policies — only use them when a specific user group needs different behaviour (execs on Strict, a lab OU excluded, etc.).
Configuration analyzer — this is the tile most MSPs never click. It diffs your current policies against Standard and Strict baselines and flags every setting that’s weaker than Microsoft’s recommendation.

Microsoft’s own guidance is explicit: prefer presets over custom policies. See Set up Safe Links policies and Set up Safe Attachments policies.

The rollout pattern that actually works

Don’t flip Strict on Monday morning. Use a three-ring rollout:

Ring 1 — IT and security-aware staff (week 1). Assign Standard preset. Watch quarantine, false-positive submissions, and user complaints. This ring tolerates noise.
Ring 2 — a tolerant business unit (week 2–3). Finance is usually a bad pilot (high-volume invoices with wrapped URLs confuse people). Pick sales ops, marketing, or IT-adjacent teams.
Ring 3 — everyone else (week 4+). By now you have a real signal on which domains need Tenant Allow/Block entries.

For Strict preset, add a fourth ring limited to exec and finance groups — or leave it off. Strict’s aggressive bulk thresholds (BCL 4) will blow up newsletters and marketing workflows. Details at Preset security policies.

Top three pitfalls

1. Custom policies silently overriding presets. Preset security policies have the highest priority except when a custom policy explicitly targets the same user. If you inherited a tenant with a custom Safe Links policy from 2019 that says AllowClickThrough = true, it beats your shiny new Standard preset. Audit first: open every existing policy before assigning presets.

2. Over-allowlisting domains. Every entry in “Do not rewrite the following URLs” is a permanent click-through exception. Treat it like firewall rules — justify, document, review annually. A forgotten *.sharepointdomain.com wildcard is how payloads land.

3. Ignoring the Configuration analyzer. Run it quarterly. Tenants drift: an admin raises a threshold to silence a complaint, nobody reverses it, six months later the baseline is gone. The Configuration analyzer surfaces this in one screen.

Tune deliberately, measure through Threat Explorer, and treat preset policies as your default — the time to build a custom policy is when you can describe exactly which preset setting it’s overriding and why.

A Cleaner Way to Connect PowerShell to Exchange Online

If you still rely on Connect-ExchangeOnline with a username, password, and an MFA prompt, you already know the pain. Scripts break overnight. Scheduled tasks fail when a token expires. Service accounts get flagged by conditional access. And the moment someone enables MFA on the admin account you’ve been quietly using, your automation falls over.

I’ve been written a new script —

https://github.com/directorcia/Office365/blob/master/o365-connect-exo-cert.ps1

with full documentation here:

https://github.com/directorcia/Office365/wiki/Connect-to-Exchange-Online-with-Certificates

— that swaps all of that for certificate-based app authentication. There’s nothing exotic about the underlying approach; Microsoft has supported it for years. What’s been missing is a clean, one-shot way to set it up without spending an afternoon clicking through the Entra portal. That’s what this script gives me, and I think it earns its place in any MSP’s toolkit.

What the Script Actually Does

There are two modes, controlled by switches.

-GenerateLocalCertificate creates a self-signed RSA-2048 certificate in your current user’s certificate store, exports the public key as a .cer file, and optionally exports a password-protected .pfx. By default it’s valid for two years. That’s the local side of the handshake.

-UseCertificateAuth is the everyday mode. You tell it which tenant to connect to — or let it look up the details in a profile map file — and it signs into Exchange Online using that certificate. No password. No browser. No MFA dialog.

The clever bit is the third option: combining -GenerateLocalCertificate with -ProvisionEntraApp -Tenant 'contoso.onmicrosoft.com'. In a single run, the script will generate the local certificate, authenticate to Microsoft Graph via a device-code flow, create the Entra ID app registration if it doesn’t exist, upload the certificate, grant Exchange.ManageAsApp and Application.Read.All with admin consent, create the matching service principal, sign you into Exchange Online to add the app to the Organization Management role group, and save the tenant, app ID, and certificate thumbprint to a JSON profile file so future connections don’t need any of those parameters.

That’s a job that normally takes twenty minutes of clicking, copying GUIDs, and second-guessing whether the right role got assigned. The script does it in about ninety seconds.

Getting Started

If you’re new to certificate auth, the first run is the one that matters. Drop the script onto an admin machine, open PowerShell, and run:

.\o365-connect-exo-cert.ps1 -GenerateLocalCertificate -ProvisionEntraApp -Tenant 'yourtenant.onmicrosoft.com'

You’ll be prompted to sign in twice — once via device code for the Graph permissions (which if you use the –copydevicecodetoclipboard, option will put the required device code straight into the clipboard to paste into the request), then again with Connect-ExchangeOnline so the script can add the app to the role group. Both need a Global Admin account. After that, every future run is just:

.\o365-connect-exo-cert.ps1 -UseCertificateAuth -Tenant 'yourtenant.onmicrosoft.com'

No prompts. No browser. The script reads the tenant, app ID, and thumbprint from o365-exo-cert-auth.json (saved to parent directory), finds the certificate in your local store, builds a signed JWT, and you’re in. One caveat worth flagging: when you’ve just provisioned a brand-new app, give it fifteen to thirty minutes for role assignments to replicate before you try to connect. The script warns about this in its output, but it’s the single most common reason a fresh setup looks broken when it isn’t.

If you’re managing more than one tenant, the profile file is where this really earns its keep. Each provisioning run appends or updates an entry, so you can ask for a connection by -ProfileName, -Tenant, or -Organization and the script picks the right credentials. When several profiles match, it lists them and lets you choose.

Why Certificates Beat Passwords

The security argument is the easy one. A certificate’s private key never leaves the machine that generated it. Nothing crosses the wire that an attacker could intercept and replay. There’s no shared secret to rotate across a team, no admin password sitting in a vault that someone might extract, and no MFA bypass to engineer because the flow doesn’t involve a user account at all.

Permissions are scoped too. The app holds only Exchange.ManageAsApp and read-only access to application metadata. If the certificate is ever compromised, you remove the key credential from the app registration and the access is gone — no password reset required, no impact on any human admin account.

The script enforces TLS 1.2, refuses to assign RBAC if the EXO session has landed in the wrong tenant, warns when the certificate is within thirty days of expiry, and keeps the device-code value off the clipboard by default to avoid leaks on RDP or shared sessions. Small things, but they add up.

Why It’s a Win for Automation

Certificate auth is what makes unattended Exchange Online work actually unattended. A scheduled task running at 2 a.m. doesn’t have a human to click “Approve” on an MFA prompt. With this approach, you point Task Scheduler at the script with -noprompt, pass the tenant, and walk away.

For an MSP, that becomes a per-tenant capability rather than a per-admin one. One profile file, one shared script, separate certificates per tenant or per admin machine — and now mailbox audits, distribution group cleanup, shared mailbox provisioning, and any of the other recurring chores you keep meaning to automate can run on a timer instead of waiting for a quiet Friday afternoon. Pair it with a Power Automate flow or a daily Copilot summary in Teams, and you’ve got reporting that lands in front of the right people without anyone signing in.

Where I’d Take It Next

If you’ve never moved off interactive sign-in for Exchange Online, this is the path I’d take. Spend half an hour standing it up against a test tenant. Get comfortable with the profile file. Then start moving your scheduled work over, one job at a time. The shift from “who’s signing in?” to “which certificate is presenting itself?” is a quiet one, but once your automation stops breaking every time an admin’s MFA settings change, you won’t go back.

PowerShell script to extract Exchange Online data for your own AI analysis

A while ago I wrote a script that reads Microsoft 365 security information and exports it to a JSON data file. The idea is that you can take this data file and use it with your AI of choice. I have now developed a similar script but for Exchange Online information.

When you run the script it will connect to Exchange online and extract the information from a variety of locations

It will produce 2 output JSON files in the parent directory. The standard data file can be quite large, in the case above it is around 15MB. The other file produced is more ‘compact’ around 100 – 200KB

You can then take either of these JSON files and feed them into you AI system of choice. The above shows you the result when I fed it into Copilot Researcher.,

and I even got a nice Word document when I fed it into Claude online.

You can download the script here:

https://github.com/directorcia/Office365/blob/master/Analysis/Exchange/exo-extract.ps1

and find the documentation here:

https://github.com/directorcia/Office365/wiki/Extract-Exchange-Online-information

as well as a long prompt you can use with your Ai of choice here:

https://github.com/directorcia/Office365/blob/master/Analysis/Exchange/prompt-long.txt

Given that email systems are typically at the highest security risk, this script shoudl allow you to quickly and easily evaluate its posture as well as giving you a range of improvement suggestions.

ASD OWA settings check script

I’ve taken the Exchange Online Outlook web app policies settings recommendations from the ASD Blueprint for Secure Cloud and created an online JSON settings file here:

https://github.com/directorcia/bp/blob/main/ASD/Exchange-Online/Roles/owamail.json

I’ve then created a PowerShell script here:

https://github.com/directorcia/Office365/blob/master/asd-owamail-get.ps1

with documentation here:

https://github.com/directorcia/Office365/wiki/ASD-OWA-Mailbox-Configuration-Check

that reads the online JSON file (or uses a local version if you want to use that) and compares the recommended ASD settings to those in your own Exchange Online environment. Note, the script makes NO CHANGES to your environment, it simply reads the current settings.

It then produces the console output you see above and a HTML report like this:

You can refer to this page I also created:

https://github.com/directorcia/bp/wiki/Exchange-Online-OWA-Mailbox-Security-Controls

as to why these settings are important to the security of your M365 environment.

Look out for more scripts like this coming soon. I welcome any suggestion about improving this.

The name is already being used–Shared Mailbox troubleshooting script

I recently had to move a mailbox alias from an existing mailbox to a hared mailbox. Every time I attempted to do so I received the following error:

The name is already being used. Please try another name

The error isn’t real helpful because it doesn’t tell you exactly what the other object causing the conflict could be. To make life easier and look across the array of places the conflict could be I created the following script:

https://github.com/directorcia/Office365/blob/master/find-name-conflict.ps1

with documentation at:

https://github.com/directorcia/Office365/wiki/Find-Name-Conflict-%E2%80%90-Shared-Mailbox-Diagnostic-Tool

In my case the issue was with a ‘Name’ value in Entra ID but the script will also give your recommendations on what PowerShell commands to run to overcome any issues it detects. I ran these and I was good to!

Hopefully, this script makes it easier to find any conflicts.

Configuring and Using Encrypted Email (Office 365 Message Encryption) with M365 Business Premium

Office 365 Message Encryption (OME) is a Microsoft 365 feature that protects email content by converting it into indecipherable text that only authorized recipients can read[1]. Microsoft 365 Business Premium includes this capability, allowing you to send confidential emails that only intended recipients (inside or outside your organization) can access. This report provides a step-by-step guide to enable and use OME, and a complete walkthrough of sending and receiving encrypted emails for both Microsoft 365 users and external (non-M365) recipients, along with best practices and troubleshooting tips.

Prerequisites and Setup for Office Message Encryption

Before using OME, ensure your Microsoft 365 environment meets the requirements and is configured correctly:

Eligible Microsoft 365 Subscription: Microsoft 365 Business Premium includes Office Message Encryption rights out-of-the-box[2]. (It comes with Azure Information Protection Plan 1, which OME leverages.) Other plans that include OME are Office 365/M365 E3 and E5, Office 365 A1/A3/A5, etc.[2]. If you are on a plan like Business Standard or Exchange Online-only, you would need to add Azure Information Protection Plan 1 to get OME functionality[2]. Each user who will send encrypted emails must have a valid license that supports OME[2].
Azure Rights Management (Azure RMS) Activation: OME is built on Azure RMS (the protection technology of Azure Information Protection)[3]. Azure RMS must be active in your tenant for encryption to work. In most cases, eligible subscriptions have Azure RMS automatically activated by Microsoft[3]. However, if it was turned off or not enabled, an administrator should activate it. You can activate Azure RMS via the Microsoft Purview compliance portal or Azure portal (the option “Activate” under Azure Information Protection)[3]. Once Azure RMS is active, Microsoft 365 automatically enables OME for your organization[3].
Verify configuration (Admin step): As an admin, it’s good to verify that encryption is enabled. For example, you can use Exchange Online PowerShell to run Get-IRMConfiguration; the output AzureRMSLicensingEnabled should be True (meaning OME is enabled in the tenant)[3][3]. If it’s False, run Set-IRMConfiguration -AzureRMSLicensingEnabled $true to enable OME[3][3]. (By default this shouldn’t be needed for Business Premium, but it’s a useful check in troubleshooting scenarios.)
User mail client requirements: Users can send/view encrypted emails using Outlook on the web or recent versions of Outlook desktop/mobile. For the best experience (including the newer “encrypt-only” capabilities), users should have Outlook 365 (subscription version) or Outlook 2019/2021. Older Outlook clients (e.g. 2016) also support OME but may not support the newest policy (like encrypt-only) without updates[4]. Ensure Office is updated so that the “Encrypt” button or permission options appear in the client. In Outlook on the web (OWA), the Encrypt option is available in the compose toolbar by default; if not, an admin may need to ensure the OWA mailbox policy has IRM enabled[5] (this is usually true by default).

(Optional) Configure automatic encryption policies: After ensuring OME is active, admins can set up policies to apply encryption automatically in certain cases. This isn’t required for basic usage (users can always manually encrypt an email), but it’s a useful configuration:
- Mail flow rules (transport rules) in Exchange Admin Center can automatically encrypt emails that match specific conditions. For example, an admin might create a rule to encrypt all emails sent externally or any email containing certain keywords (like “Confidential”)[1][1]. These rules use Microsoft Purview Message Encryption as the action to protect messages automatically.
- Sensitivity labels (from Microsoft Purview Information Protection) can be configured to apply encryption. In Business Premium, you can create labels such as “Confidential – Encrypt” that, when a user applies the label to an email, it automatically encrypts that message. This is a more user-friendly and consistent way to invoke encryption and can also enforce permissions (e.g., restrict forwarding).
- Branding (optional): Administrators can customize the appearance of encrypted mail notifications sent to external recipients. For instance, you can add your organization’s logo, custom title, or instructions to the encryption portal email template[6]. Branding is configured via PowerShell (Set-OMEConfiguration) and is a best practice so that recipients recognize the secure message as coming from your company.

Sending Encrypted Emails (Step-by-Step Guide)

Once OME is enabled for your account, sending an encrypted email is straightforward. You do not need to manage any encryption keys yourself – the encryption is handled by Microsoft’s service in the background. Here’s how to send an encrypted email using Outlook:

Encryption Options: When applying encryption in Step 2, you may have a few choices depending on your configuration:

Encrypt-Only – Encrypts the email (and attachments) so that only authorized recipients can read it, but does not restrict what recipients can do with the content. Recipients could potentially copy or forward the content after decrypting, so use this when you want confidentiality but don’t need to restrict sharing.[4][4]
Do Not Forward – Encrypts the email and applies Information Rights Management restrictions prohibiting the recipient from forwarding, printing, or copying the email’s content[6]. The recipient can read and reply, but cannot share it further. This is ideal for highly sensitive emails where you want to keep tight control.
Sensitivity Labels – If your organization uses labels (like “Confidential”) configured to apply encryption, you might see those as options (for example, an email labeled Confidential might auto-encrypt and restrict to internal employees only). These will function similarly to the above, with preset scopes and restrictions defined by your admin.

Note: You do not need to exchange certificates or use special plugins to send encrypted mail using OME. As long as you have a supported M365 account with OME enabled, the feature is built into Outlook. This is much simpler than using S/MIME certificates, which require exchanging keys. With OME, just clicking “Encrypt” in Outlook is enough – Microsoft manages the encryption keys behind the scenes[6][6].

After sending, you might want to verify that your message was encrypted. In your Sent Items, the message should show an icon or text indicating it is protected. For instance, Outlook might display a small padlock icon or a banner “Do Not Forward” on the sent email if that was applied. Additionally, if you try to open the email from Sent Items, it may show that you (as sender) have full permissions. You can also double-check with a test recipient that they received an encrypted message (they will see indications on their side, described next).

Receiving and Opening Encrypted Emails

When a recipient gets an encrypted email, their experience will vary slightly depending on whether they are using a Microsoft 365/Outlook account or a third-party email service. We outline both scenarios below.

1. Microsoft 365/Office users (Internal or External with M365 accounts): If the recipient uses Outlook and has a Microsoft 365 account (either in your organization or another organization that uses Azure AD), the encrypted email arrives in their inbox like a regular email. In Outlook 2016 or later, they will see an alert in the Reading Pane that the message has restricted permissions[4] (for example, “Encrypt-Only” or “Do Not Forward” noted). They can simply open the email normally – Outlook will automatically retrieve the decryption key in the background using their credentials. After opening, the content is readable within Outlook just like any other email[4]. In short, for M365 users, reading an OME email is usually one-click: open it and read. For Outlook on the web or mobile, it’s similar – they click the message and, as long as they’re logged in with the authorized account, the message opens. (If by chance their client cannot display it directly – e.g., an older Outlook not fully updated – the email will instead contain a “Read Message” link guiding them to the web portal. But as of recent updates, Outlook 2019/M365 apps support the direct decrypt in the client for the Encrypt-Only policy[4].)

2. External or non-Microsoft recipients: If the recipient is outside M365 (for example, using Gmail, Yahoo, or any other email provider), they will receive an email letting them know you sent an encrypted message. The email will typically show your original subject line and a body message like: “\ has sent you a protected message” with a button or link that says “Read the message” (or an HTML attachment that they need to open)[6].

From the external recipient’s perspective, these are the steps to open an encrypted mail:

As seen above, Microsoft has designed OME so that even external recipients have a user-friendly (if slightly multi-step) way to access encrypted mail. They do not have to install anything; a web browser is enough. They either sign in with an existing email account or use a one-time code sent to their email[4][4]. Once that is done, they can read and even respond securely. This approach means you can confidently send sensitive data to clients or partners using Gmail, Yahoo, etc., and know that only they (not an unintended person) can read it.

Important: Certain parts of the email are not encrypted for practical reasons: the email subject line and metadata (sender, timestamp) are visible in the notification email. Only the body and attachments are encrypted. Therefore, as a best practice, do not put highly sensitive info in the subject line of an email – keep it generic and put details in the body or attachments which will be encrypted.

Also note, if an external recipient tries to forward the original notification email itself, it won’t help others read the message because only the intended recipient can authenticate to view the content. If you applied “Do Not Forward” protection, an external recipient cannot forward the content from the portal either (the portal will enforce no forwarding). If a Microsoft 365 recipient tries to forward a “Do Not Forward” encrypted email, the forwarded message will be unreadable to the new third-party, since they aren’t authorized – the system will either block it or send a protected email that the new recipient cannot open[6].

Best Practices for Using OME Effectively

Using Office Message Encryption adds security, but it’s important to use it correctly. Here are some best practices and tips:

Train users and set expectations: Educate anyone sending encrypted emails on how OME works and when to use it (e.g. for personal data, financial info, confidential documents). Likewise, prepare external recipients if possible. For instance, if you’re emailing a client securely for the first time, you might call or text them beforehand, saying “You’ll receive a secure encrypted email from me with a link – it’s safe to open.” This helps external recipients not mistake your encrypted email for a phishing attempt.
Use “Do Not Forward” for highly sensitive content: If you want to ensure the information doesn’t get re-shared, use the Do Not Forward option (or a similar rights-protected label). This way, even if a recipient’s account were compromised or someone was tempted to share the email, the protected content cannot be opened by unauthorized people[6]. It adds an extra layer beyond encryption alone.
Avoid sensitive details in subject or preview text: As noted, the email subject is visible to anyone who might intercept the message (or just in the recipient’s inbox preview). Keep subjects generic and put sensitive info only in the encrypted body/attachments.
Verify encryption on outgoing emails: When you send an encrypted email, double-check that Outlook shows it’s encrypted (look for the lock icon or a permissions message in the compose window)[6]. If you don’t see the encryption indicator, you may have missed a step. Also, you can send a test email to yourself (to a separate account) to see how the experience looks for recipients.
Consider sensitivity labels for consistency: If your organization frequently encrypts emails, using sensitivity labels can make it easier and more standardized. For example, a label “Private – Recipients Only” could automatically encrypt and set Do Not Forward, in one click for the user. It ensures the correct policy is applied and also might apply visual markings to the email. Business Premium allows configuring such labels in the Purview compliance center.
Be cautious with group emails: OME can encrypt emails sent to multiple people, but ensure each recipient is intended. If you send to a distribution list or a group, all members will be able to read it; if someone is later added to that group, they may not access past encrypted mail. For external groups, OME might not resolve all members. Ideally, send encrypted mail to individual addresses to maintain clarity over who can decrypt it.
External recipient guidance: Some external recipients might struggle with the process (for example, the one-time passcode email might land in their spam folder or they may not realize they can use a Google login). Be ready to guide them. Microsoft’s support page “Open encrypted and protected messages” is a useful reference to share if someone has trouble.
Remove encryption if needed: If you accidentally sent an email with encryption but later need to share the content openly, you (the sender) have the ability to remove encryption after sending. In Outlook, find the sent encrypted message, open it, go to File > Permissions (or Encrypt) and choose “Unrestricted Access” (for Outlook desktop)[6]. This essentially decrypts the message for all recipients, allowing them to view it without the special process. Use this carefully – it will make that content accessible just like a normal email.
Leverage branding for trust: As mentioned, consider adding your organization’s branding to encrypted emails (logo, custom instructions)[6]. This helps recipients trust that the encryption message is legitimately from your company and not a phishing scam. The branding appears on the “Read the message” page and in the email that contains the link.
Stay updated: Microsoft continually improves OME. For example, the “Encrypt-Only” mode was added to allow direct decryption in modern Outlook apps[4]. Keep your Outlook client updated to benefit from the latest improvements (e.g., some older versions required always using the web portal; newer versions can decrypt in-app). Similarly, stay informed via Microsoft 365 updates for any changes to the encryption experience.

Monitoring, Management, and Compliance Considerations

From an IT administration and compliance perspective, encrypted emails introduce some new considerations. Here’s how to manage and monitor OME usage in your organization and ensure compliance requirements are met:

Tracking encrypted messages: Administrators may want to know when and how often users are sending encrypted emails (for example, to ensure policies are followed). Microsoft 365 provides an Encryption Report in the compliance center (Purview portal) that shows statistics and details of encrypted emails. In the Microsoft Purview portal, under Data Loss Prevention or Reports, you can find a report for Message Encryption usage[7]. This report can show which emails were encrypted, by whom, and if they were automatically encrypted by a rule or manually. It can typically be scheduled to be sent via email or viewed on demand[7]. Use this to monitor adoption and detect any anomalies (like an unusual spike in encrypted emails, which might indicate users handling a lot of sensitive info).
Audit logs: Each time a user sends an encrypted email, an event is recorded in the Unified Audit Log in Microsoft 365 (if auditing is enabled). Admins can search the audit log for activities related to OME (such as the “Applied sensitivity label” event if labels are used, or mail flow rule events). There isn’t a special “encryption” event per se for each message, but the encryption report mentioned above is a higher-level view. If deeper investigation is needed (e.g., for a specific incident), administrators with proper permissions could also access the content (see eDiscovery below).
eDiscovery and compliance searches: Encrypted emails are still stored in mailboxes (in an encrypted form). Compliance officers may worry: can we perform eDiscovery on encrypted content? The answer is yes – Microsoft Purview eDiscovery tools can decrypt encrypted emails so that compliance or legal reviewers can search and read them, provided the reviewer has the necessary permissions (specifically, the “RMS Decrypt” permission in Purview)[8][8]. In practice, during a content search or eDiscovery case, the system will decrypt the content of OME emails when exporting results or adding items to a review set, so that the reviewer can see the actual email text[8][8]. This ensures that using OME doesn’t impede your organization’s ability to fulfill legal discovery or compliance obligations, as long as authorized personnel are doing the searching.
Data Protection and compliance standards: Using OME can help your organization comply with regulations that require protection of sensitive data in transit (such as GDPR, HIPAA for healthcare communications, or financial privacy laws). The encryption ensures that even if an email is inadvertently sent to the wrong party or intercepted, it cannot be read by unauthorized persons. That said, encryption is one piece of the puzzle – you should still enforce data loss prevention policies and train users on handling sensitive info. OME works in tandem with Data Loss Prevention (DLP) policies: for instance, a DLP policy detecting a credit card number could automatically trigger encryption of the email instead of blocking it, allowing the email to go out securely rather than in plain text[1].
Advanced Message Encryption: For organizations with higher-end licenses (E5 or as an add-on), Advanced Message Encryption provides additional management capabilities. This includes the ability for admins to revoke access to a sent encrypted email or set it to expire after a certain time. For example, if an employee sent an encrypted email externally by mistake, an admin with Advanced Message Encryption could revoke that message, so that when the recipient tries to read it, they get a notice that the message is no longer available. Business Premium does not include Advanced Message Encryption (that’s an E5 feature), but it’s useful to know such features exist in case your compliance needs grow in the future.
Ensuring availability of encryption features: If users report that they can’t find the Encrypt button or that encrypted emails aren’t opening, revisit the configuration:
- Make sure the user is logged into their Outlook with the correct account that has the Business Premium license. If not, have them sign out and sign back in with their licensed account[5][5].
- Check that the Outlook on the web policy has IRM enabled (an admin can do Get-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default | FL IRMEnabled. It should be True. If not, set it to true to expose the Encrypt option in OWA)[5].
- Ensure there are no older Active Directory Rights Management (on-premises AD RMS) configurations interfering – Microsoft’s OME will not work simultaneously with an old AD RMS setup. If you previously used AD RMS, you should migrate those keys to Azure RMS[3].
Internal monitoring and scanning: Note that Exchange Online can still scan encrypted emails for malware and spam before encryption is applied. If you manually encrypt a message and send it, the content gets encrypted after it passes through the Outbox, meaning Microsoft’s server has the plaintext to scan for viruses. If an admin sets up an automatic encryption rule, it typically applies at the transport stage after other filters. So your use of OME shouldn’t reduce the effectiveness of Exchange Online Protection (EOP) for anti-malware. However, once encrypted, other systems (like a recipient’s email server or a journaling system outside Microsoft) can’t inspect the content. Keep this in mind if your enterprise routes mail through any gateway that needs to inspect content – you may need to allow that encryption happens at the final stage.

In summary, Microsoft 365 Business Premium provides a robust encryption capability for email. By configuring it properly and following the best practices above, you can greatly reduce the risk of sensitive information leaking via email, while still maintaining usability for your users and external contacts. Always balance security with practicality – use encryption when it’s truly needed (so users take it seriously), and make sure to support recipients who might be unfamiliar with the process. With OME, you empower users to protect data on their own, which is a powerful tool in your organization’s security arsenal.

Further Resources

For more information and support on Office 365 Message Encryption, consider these resources:

Microsoft Learn – Email encryption in Microsoft 365: An overview of all email encryption options in M365, including OME, S/MIME, and IRM[9]. This is useful for understanding how OME compares to other encryption methods.
Microsoft Learn – Set up Message Encryption: Step-by-step guidance for admins to enable and test OME in a tenant[3][3].
Microsoft 365 Business Premium Training – Protect Email with OME: Microsoft offers a training module on using OME (protecting email) as part of their Business Premium documentation[1][1].
Troubleshoot OME (Microsoft Support): Common issues and solutions if encrypted messages can’t be opened or the encrypt option is missing[5][5].
User Guide – Send, View, and Reply to Encrypted Emails: Microsoft support article for end-users on how to send and read encrypted messages in Outlook[4][4] – this can be shared with new users or external recipients if they need guidance.

Each of these resources can provide deeper insights or up-to-date instructions as OME evolves. By following the steps and tips in this report, you should be well-equipped to configure Office Message Encryption in Microsoft 365 Business Premium and use it to securely send/receive sensitive emails with confidence. Enjoy the peace of mind that comes from that extra layer of security on your communications! [4][4]

References

[1] Send encrypted email with Microsoft 365 Business Premium – Microsoft …

[2] Message Encryption FAQ | Microsoft Learn

[3] Set up Microsoft Purview Message Encryption | Microsoft Learn

[4] Send, view, and reply to encrypted messages in Outlook for PC

[5] Resolve Microsoft Purview Message Encryption issues

[6] How to Encrypt Emails in Outlook and Office 365 — LazyAdmin

[7] O365 Encrypted Email – How can I tell which outgoing emails were …

[8] Decryption in Microsoft Purview eDiscovery tools

[9] Email encryption in Microsoft 365 | Microsoft Learn