Author: thalpius

In the previous post, encrypting an email containing a BSN turned out to be the easy part: a DLP policy, a sensitive information type, and a Do Not Forward action got the job done in an afternoon. This post covers the harder half of the promise, controlling what happens to that email after it has already been sent. Can it expire on its own? Can it be pulled back if it was sent to the wrong person? That is Microsoft Purview Advanced Message Encryption, and testing it surfaced more undocumented behavior than expected.

Table of Contents

1. What Advanced Message Encryption Adds
2. Setting Up the Branding Action
3. Testing Revocation
4. Testing Expiration
5. Conclusion

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. Several values and behaviors described in this post fall outside Microsoft’s documented ranges and were only confirmed through direct testing in a single tenant; they are not guaranteed to behave the same way in every environment, and Microsoft support was not consulted before publishing. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first.

What Advanced Message Encryption Adds

Advanced Message Encryption (AME) sits on top of the Purview Message Encryption covered in the previous post. It requires a Microsoft 365 E5, E5 Compliance, or E5 Information Protection & Governance license, on top of the base encryption capability that already comes with E3. Without one of those licenses, the cmdlets in this post either fail outright or simply have no effect.

AME adds three things: multiple branding templates, message expiration, and message revocation. All three depend on the recipient reading the message through the OME web portal rather than natively inline. That is a detail worth repeating from the previous post’s “What the Recipient Actually Sees” section: a Microsoft-account recipient normally gets a native, login-free reading experience, and native messages cannot be revoked or expired, regardless of licensing. To guarantee every external recipient goes through the portal, a separate Exchange transport rule is needed:

New-TransportRule -Name "Force Portal - BSN" -FromScope "InOrganization" -ApplyRightsProtectionTemplate "Do Not Forward" -ApplyRightsProtectionCustomizationTemplate "BSN-Template"

This rule is separate from, and runs alongside, the DLP policy from the previous post. Both can trigger encryption independently.

Setting Up the Branding Action

A custom branding template only guarantees revocation and expiration support once it is actually applied through a mail flow rule. If a custom branding template is needed, it is worth knowing that it does not appear as a protection option in the same dropdown as Encrypt and Do Not Forward. It requires a second, separate DLP action called Apply branding to encrypted messages, added alongside the encryption action rather than instead of it.

The template itself is created and modified through PowerShell:

New-OMEConfiguration -Identity "BSN-Template" -ExternalMailExpiryInDays 7

With the transport rule from the previous section referencing this template directly, every external recipient, including Microsoft account holders who would otherwise get the native experience, is forced through the portal.

Testing Revocation

Checking whether a message is revocable does not require sending anything new. Given a Message ID (found through Message Trace), the status can be queried directly:

Get-OMEMessageStatus -MessageId "<message-id>" | ft -a Subject, IsRevocable

This returned IsRevocable: True without issues, confirming the setup (DLP policy, branding template, and transport rule) was correctly forcing portal-based delivery.

Actually revoking the message was a different story:

Set-OMEMessageRevocation -Revoke $true -MessageId "<message-id>"

This consistently failed with a 401 error, reproducible across multiple messages and after a fresh PowerShell session:

Write-ErrorMessage : StatusCode: 401, ReasonPhrase: 'Auth Failed. For details, use the Token Validation Service
correlation ID to get more details from Core Auth telemetry. OAuthEvent currTvsCorrId: [correlation-id]'

The stack trace pointed to an internal service-to-service call, Exchange’s OMEMessageHelper submitting a revocation confirmation to Microsoft’s internal Substrate Bus service, failing its own authentication. That is not something a tenant admin, even with Global Administrator and Compliance Administrator roles assigned, can fix through configuration. It is a backend issue, and the correlation ID in the error is meant for a Microsoft support ticket, not for tenant-side troubleshooting.

The sender-side alternative, “Remove external access” in Outlook on the web’s Sent Items, turned out not to apply here either. That option appears to be reserved for messages manually encrypted by a user through Outlook’s own Encrypt button, not messages encrypted automatically by a DLP policy or transport rule.

Revocation, in this tenant, remains an open issue pending a Microsoft support ticket.

Testing Expiration

Expiration looked more promising, and testing it surfaced a chain of undocumented behavior worth walking through.

The only documented parameter is -ExternalMailExpiryInDays, an integer from 1 to 730. Waiting a full day to confirm a test felt impractical, so the boundaries of that restriction got tested directly.

Passing a TimeSpan-formatted string failed immediately, revealing that the parameter is parsed as a number, not a duration:

Set-OMEConfiguration -Identity "BSN-Template" -ExternalMailExpiryInDays "0.00:05:00"
Cannot convert value "0.00:05:00" to type "System.Double"

That error was more informative than expected: the parameter is documented as an Int32, but the actual conversion target is System.Double. Decimal values are apparently accepted despite the documented 1-730 integer range:

Set-OMEConfiguration -Identity "BSN-Template" -ExternalMailExpiryInDays 0.1

This succeeded, and reading the configuration back confirmed it was stored precisely, as a genuine TimeSpan rather than being rounded up to a full day:

ExternalMailExpiryInterval : 00:14:24

0.1 days is 2.4 hours, and a smaller test, 0.01 days, also went through cleanly and stored as 14 minutes and 24 seconds exactly, no rounding, no rejected value, despite being two orders of magnitude below the documented minimum.

Sending a fresh test message confirmed via Message Trace details that both the DLP policy and the transport rule were applied as expected.

But after the 14-minute-24-second window passed, the message remained fully readable, with no expiration notice in the wrapper email at all.

Re-authenticating into the portal made no difference.

The likely explanation: the configuration is stored correctly regardless of how small the value is, but the enforcement layer, the background process that actually checks “has this expired”, appears to be built around the documented whole-day granularity, and silently treats sub-day values as no expiration at all rather than a short one.

Reverting to the officially supported minimum confirmed this. With the value set back to a full day:

Set-OMEConfiguration -Identity "BSN-Template" -ExternalMailExpiryInDays 1

the wrapper email for a fresh test message displayed an explicit expiration notice, “Access to the message will expire on [date] (UTC)”, which never appeared with the fractional values. Storage accepts fractional days; enforcement and the user-facing expiration notice apparently do not.

After the expiration window passed, opening the same link consistently returned a generic error, “Sorry, we can’t display your message right now, Something went wrong and your encrypted message couldn’t be opened”, rather than a specific “this message has expired” notice. Sending a brand new test message immediately afterward opened without issue, confirming the failure was tied specifically to the expired message rather than a broader service outage. Expiration works as intended; Microsoft’s error messaging around it, however, doesn’t make that obvious.

Conclusion

1. Advanced Message Encryption is a licensing gate, not just a feature toggle: without Microsoft 365 E5 or an equivalent add-on, expiration and revocation are not available regardless of how the rest of the configuration is set up.
2. Branding is a separate action, and a prerequisite: revocation and expiration only apply to messages that go through the OME portal, which itself depends on a custom branding template applied through a mail flow rule, not the DLP encryption action alone.
3. A documented range is not always an enforced one: Set-OMEConfiguration accepted values far below the documented 1-730 day minimum for ExternalMailExpiryInDays, storing them precisely, without the enforcement layer honoring them the same way.
4. Revocation failed on a backend authentication error unrelated to tenant configuration or permissions, a reminder that not every failure in these tools is something an admin can resolve alone.

Between this post and the previous one, the practical takeaway is the same: Microsoft Purview’s encryption capabilities work largely as documented for the core scenario, detecting and encrypting sensitive data automatically, but the more advanced controls are worth testing directly in a non-production tenant before relying on them, rather than assuming the documentation’s stated limits are the actual behavior.

A finance employee needs to email a client’s Burgerservicenummer (the Dutch equivalent of a U.S. Social Security Number) to confirm a contract detail. They type it straight into the body of a normal email and hit send. Depending on how the tenant is configured, that email either gets encrypted and access-restricted automatically before it leaves the mailbox, or it goes out in plain text, readable by anyone who intercepts, forwards, or accidentally receives it.

This is exactly the gap Microsoft Purview Message Encryption, combined with Data Loss Prevention (DLP), is built to close. Rather than relying on a person remembering to manually encrypt a sensitive email, Microsoft Purview can detect the sensitive data itself and apply protection automatically, before the message ever reaches the recipient. In this post, I will walk through the full setup, the two protection options and the difference between them, and what actually happens on the recipient’s side, including a few things that went wrong along the way.

Table of Contents

1. The Building Blocks
2. Activating the Underlying Encryption Service
3. Building the DLP Policy
4. Testing the Detection
5. What the Recipient Actually Sees
6. It Still Shows Up as an Incident in Defender
7. Conclusion

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first and consult official Microsoft documentation before implementing security features in production.

The Building Blocks

Three Microsoft Purview components work together to make this happen:

• A DLP policy that scans outgoing email for a specific sensitive information type, in this case the built-in Netherlands Citizen’s Service (BSN) Number type, which validates both the digit pattern and its checksum.
• Message encryption, applied automatically once the DLP rule finds a match. Depending on the tenant, this dropdown can include several templates, including custom ones derived from existing sensitivity labels, but two options are always available: Encrypt protects the message, but the recipient can still forward, print, or copy it. Do Not Forward applies the same encryption plus blocks forwarding, printing, and copying. For this scenario, Do Not Forward is the better fit, since it does not require choosing between the two, Do Not Forward already includes the encryption.
• A custom branding template (optional), which controls what the encrypted message looks like and, with Microsoft 365 E5 or the E5 Compliance add-on, enables expiration and revocation of already-sent messages.

Activating the Underlying Encryption Service

Before any of this works, connect to Exchange Online PowerShell and check whether internal licensing is enabled:

Connect-ExchangeOnline -UserPrincipalName you@yourdomain.com
Get-IRMConfiguration | Select-Object InternalLicensingEnabled

This is where it is easy to get stuck: InternalLicensingEnabled = True only confirms that Exchange is allowed to use IRM. It does not confirm that the underlying Azure Rights Management service is active. Running Get-RMSTemplate and getting nothing back, not even the default Encrypt and Do Not Forward templates, means Rights Management itself is disabled tenant-wide. That is fixed through a separate module:

Install-Module -Name AIPService
Connect-AipService
Get-AipService
Enable-AipService

Once enabled, Get-RMSTemplate returns the default templates plus any custom ones created afterward.

If expiration or revocation is needed, a custom branding template can be created with:

New-OMEConfiguration -Identity "BSN-Template" -ExternalMailExpiryInDays 7

If a custom branding template is needed later, for example to enable expiration or revocation, it is worth knowing that it does not appear as a protection option in the same dropdown as Encrypt and Do Not Forward. It requires a second, separate DLP action called Apply branding to encrypted messages, added alongside the encryption action rather than instead of it.

Building the DLP Policy

In the Microsoft Purview compliance portal, under Data loss prevention, Policies, a custom policy scoped to Exchange email needs the following:

• Condition: content contains sensitive info type, Netherlands Citizen’s Service (BSN) Number
• Action 1: Restrict access or encrypt the content in Microsoft 365 locations, Encrypt email messages, Do Not Forward
• Action 2 (optional): Apply branding to encrypted messages, selecting the custom template

Naming both the policy and the rule descriptively pays off later, once there are several DLP policies running. Something like Encrypt Email - NL BSN Detection for the policy and Encrypt with DNF - NL BSN Detected for the rule is enough to trace a match back to its source in Activity Explorer without guessing.

Starting the policy in test mode with notifications, rather than full enforcement, logs every match, including the sensitive info type, policy, rule, and action that would have been taken, without actually encrypting anything yet.

Testing the Detection

A few details matter before sending a test email:

• DLP only scans new outgoing mail. Nothing already sent gets scanned retroactively, and a newly enabled or changed policy typically takes about an hour to fully propagate.
• A fake but checksum-valid BSN is enough for testing. The number 111222333 passes the BSN checksum (the elfproef: multiply each digit by weights 9, 8, 7, 6, 5, 4, 3, 2, -1, sum the results, and the total must be divisible by 11) without belonging to a real person. On its own it may not trigger detection though; the sensitive info type also looks for a nearby keyword such as “BSN” within roughly 300 characters, so pairing both in the test email is what reliably triggers a match.
• Activity Explorer, not Content Explorer, shows rule matches. Content Explorer reports where sensitive content exists across the environment; Activity Explorer confirms whether a specific email actually matched a DLP rule, using the filter “DLP policy rules that detected activities.”

Once a “DLP rule matched” event shows the correct sensitive info type, policy, and rule name, the policy can move from test mode to enforce. After another hour of propagation, a genuinely fresh test email confirms the real behavior.

What the Recipient Actually Sees

Sending the same encrypted, Do Not Forward email to different types of recipients produces two distinct experiences:

• A Microsoft account recipient (Outlook.com, Hotmail, or a Microsoft 365 mailbox) gets a native experience. The message opens normally, with only a small “Do Not Forward” label at the top, no login prompt or portal. Decryption happens transparently because the recipient is already signed in with Microsoft; the restriction itself, blocking forwarding, is still fully enforced.
• A non-Microsoft recipient (tested with Gmail and iCloud) gets the classic wrapped portal experience: an email with a “Read the message” link, requiring identity verification through a one-time passcode or a Microsoft sign-in before the content becomes visible.

Both are the exact same underlying protection. The difference is only in how Microsoft verifies who is opening the message, which is worth knowing before assuming that a smooth, login-free reading experience means something was not encrypted.

It Still Shows Up as an Incident in Defender

Encrypting the message does not make the action invisible to security monitoring. Because the email still left the organization to an external recipient, Microsoft Defender correlated the DLP match into an incident tagged “External user risk” under the Exfiltration category, at Low severity. The data itself stayed protected, but the event was still flagged for a SOC team to review if needed, a reminder that Purview and Defender are complementary layers, not substitutes for each other.

Conclusion

1. Classification drives everything: without a sensitive information type detecting the BSN, there is nothing for a DLP action to encrypt in the first place.
2. Do Not Forward, not Encrypt plus Do Not Forward: the two are alternatives, not additive actions, and Do Not Forward already includes the encryption.
3. Test mode before enforce: confirming a detection match in Activity Explorer first avoids surprises once the policy actually starts encrypting live mail.
4. The recipient experience varies, the protection does not: a native, login-free read for Microsoft account holders and a portal-based read for everyone else are the same encryption underneath.

Given how safely this can be tested, a made-up but checksum-valid number sent to your own test mailboxes, there is little reason not to set this up before something sensitive slips through in plain text.

A finance employee applies a Confidential label to a spreadsheet, works on it for a few days, and then shares it with an external consultant through a link in Teams. Depending on how the tenant is configured, that share attempt is either stopped in real time, or it goes through completely unnoticed until someone reviews it weeks later. Which of those two outcomes happens depends entirely on which Microsoft security tool is doing the watching, and at what point in the document’s lifecycle it gets involved.

This is exactly where Microsoft Purview and Microsoft Defender for Cloud Apps get confused as doing “the same thing” for data protection. They do not. One prevents an action before it happens. The other cleans up after data has already moved. In this post, I will walk through both sides with concrete policy examples, and explain why most mature environments end up running both rather than picking one over the other.

Table of Contents

1. Two Different Moments of Control
2. Microsoft Purview DLP: Blocking Data After Classification
3. Microsoft Defender for Cloud Apps: Revoking Access on Already-Shared Files
4. Why You Need Both
5. Conclusion

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first and consult official Microsoft documentation before implementing security features in production.

Two Different Moments of Control

A question I get regularly: “We have Microsoft Purview, so why do we also need Defender for Cloud Apps for data protection?” The short answer is that they intervene at two different moments in a document’s lifecycle. Purview prevents sensitive data from going down the wrong path in the first place. Defender for Cloud Apps cleans up what has already been shared. Neither one replaces the other; they cover different gaps.

Microsoft Purview DLP: Blocking Data After Classification

Microsoft Purview Data Loss Prevention (DLP) intervenes at the moment a user tries to do something with a document: sending it by email, uploading it to a cloud app, pasting it into a browser, or sharing it outside the organization.

That intervention depends entirely on classification. Before a DLP rule can block anything, Purview first needs to know that a document is sensitive. This is done through:

• Sensitive information types (SITs): pattern-based detection such as credit card numbers, national identification numbers, or customer IDs
• Sensitivity labels: applied manually by users or automatically based on content, for example Confidential or Internal
• Trainable classifiers: machine-learning-based recognition of content types such as contracts or financial statements

Once content is classified as sensitive, a DLP policy can act on it. A common example: a user tries to share a document labeled Confidential with someone outside the organization. The DLP policy recognizes the label and the action is immediate: block, optionally with a business justification override, or block without that option. Every attempt is logged in Activity Explorer, so you can see exactly who tried what and whether the policy intervened.

The strength of this approach is that it is preventive, and it applies across the locations Purview has visibility into: endpoints, email, Teams chats, SharePoint/OneDrive, and even prompts sent to Microsoft 365 Copilot and external generative AI tools.

Microsoft Defender for Cloud Apps: Revoking Access on Already-Shared Files

Where Purview DLP is about preventing an action, Defender for Cloud Apps is about correcting a situation that already exists. Think of a document that was shared externally before a label was ever applied, or a file that ended up in a cloud app outside your visibility through a route DLP never inspected.

With a file policy in Defender for Cloud Apps, you can continuously scan for files matching specific conditions, for example an access level of External or Public combined with a sensitivity label or a sensitive information type detected through the Data Classification Service. Once a file matches those conditions, automated governance actions can follow, including:

• Remove external users: removes all collaborators outside the internal domains configured in your settings
• Remove public access / remove direct shared link: revokes a shared link or restricts access to named collaborators
• Make private: removes all shares, leaving access to site administrators only
• Remove a collaborator: revokes access for one specific person without affecting the rest

This works across connected apps such as SharePoint, OneDrive, Google Workspace, and Box, which makes it particularly valuable as a backstop for content that was already shared before it was classified, or for gaps that fall outside Purview DLP’s preventive reach.

Why You Need Both

Microsoft Purview DLP intervenes before or during the action (preventive), triggered by classification detected during an activity, typically blocking sharing, copying, pasting, or uploading, across endpoints, email, Teams, SharePoint/OneDrive, Copilot, and browsers.

Microsoft Defender for Cloud Apps intervenes after the action, on data at rest (corrective), triggered by a continuous scan of files against conditions such as access level and label, typically revoking permissions, undoing sharing, or quarantining/making files private, across connected cloud apps such as SharePoint, OneDrive, Google Workspace, and Box.

This is where the combination earns its value. Purview DLP prevents a large share of risky actions from happening at all. But no preventive layer is airtight: files shared before a label was applied, or content that leaked out through an unmanaged path, will slip through. Defender for Cloud Apps acts as the safety net, continuously scanning what is already out there and revoking access the moment it should not have been granted.

Conclusion

Data protection is not a single control, it is a layered model:

1. Classify first: sensitivity labels and sensitive information types are the foundation both solutions depend on. Neither Purview DLP nor Defender for Cloud Apps has anything to act on without classification.
2. Microsoft Purview DLP: prevents risky actions on sensitive content at the moment they happen, across endpoints, email, Teams, and browsers.
3. Microsoft Defender for Cloud Apps: continuously scans already-shared content in connected cloud apps and revokes access when it violates policy.

Prevent where you can, correct where you must. Together, these two layers close the gap that either one would leave open on its own.