Governing Exchange Distribution Lists with Entra ID (The No-Secrets Way)

Distribution Lists are one of those IT tools that have been around forever, and honestly, there is a good reason for that. They are simple, familiar, and they do exactly what you want them to do: you have a list of people, and you want to send them an email.

Company announcements, meeting invites, or team updates. You do not always need a SharePoint site, another shared calendar, a Microsoft Teams workspace, and seventeen other cloud resources just because you wanted to send an email to 200 people. Sometimes you literally just need a list of email addresses.

That is still a perfectly valid use case. The headaches only begin when you try to manage who actually belongs to that list over time.

When a Simple List Becomes an IT Lifespan Problem

In many organizations, keeping a Distribution List up to date is still an entirely manual service desk chore. Someone joins the company and needs to be added to ten different lists. Someone leaves and needs to be taken off. Someone changes jobs or departments, and their access needs to be reviewed. None of this is technically difficult. It is just another administrative task someone has to remember to do.

And that is exactly when human nature enters the room.

Someone forgets to submit the ticket. Someone at the helpdesk forgets to process it. Someone switches roles, and absolutely nobody remembers that their old Distribution List access should probably be removed. HR, managers, and the service desk all end up with another small piece of manual work. And manual IT work has a habit of multiplying when you aren’t looking.

Leavers are usually easy to catch because the offboarding process typically cuts access to everything at once. Movers, however, are where things get truly interesting. A user changes departments, but the Distribution Lists they belonged to in their old role do not magically change with them.

The user has moved on. The Distribution List membership has not.

The identity lifecycle says one thing, but the actual mailbox membership says another. Just like that, your simple email list has evolved into an identity governance problem.

Looking at the Built-in Options (And Why They Fail)

The logical next question is: why can we not just manage these memberships natively using Entra ID Governance?

Unfortunately, Exchange Distribution Groups are not supported as manageable resources in Entra Entitlement Management. Entra ID cannot natively modify their memberships, which means Entra ID Governance cannot use them as normal targets. Microsoft supports Entra security groups and Microsoft 365 Groups for this type of governance; Exchange Distribution Groups are simply left out in the cold.

At this point, the standard advice is usually: “Just upgrade them to a Microsoft 365 Group instead.”

But do we really need more cloud clutter? Microsoft 365 Groups are built for heavy collaboration. They come with a shared mailbox, a group calendar, and a whole SharePoint site. That is great if you actually need to collaborate. But if all you want is to blast an email to a group of people, you are just creating a lot of extra backend junk to clean up later. Plus, replacing existing lists means changing how users have been working for the last decade. Sometimes the simplest answer is still the old-school Distribution List.

What about Dynamic Distribution Lists? Instead of managing a fixed list of names, Exchange calculates the recipients on the fly based on user filters and directory attributes. This sounds perfect until you realize that real-world enterprise environments rarely have clean, pristine attributes just waiting to be used.

Those directory fields usually have day jobs already.

The CustomAttribute and extensionAttribute fields that look incredibly convenient when you first discover them are usually the graveyard where every other IT system stores its random data. I have seen them used for everything from local printer names to messy Intune targeting policies and the unforgettable hideFromGal in extensionAttribute1. Suddenly, those fifteen attributes do not feel like plenty anymore.

Furthermore, from a governance perspective, a Dynamic Group does not actually solve the Entitlement Management issue. Microsoft explicitly points out that they cannot be managed through Entra ID in the way governance packages require.

So we have looked at three different paths, and none of them quite works. The classic Distribution List works for the business but sits completely outside your identity governance strategy. M365 Groups bring the governance but add unwanted sprawl. Dynamic Distribution Groups automate the math but rely entirely on messy directory data.

So is identity governance just impossible here? Not if we build a bridge.

Architecture: Custom Extensions to the Rescue

Native governance does not work out of the box, but Custom Extensions give us a way to bridge the gap. Think of this as a way to tell Entra ID: “Hey, when you process this access request, let me handle the next step.”

The Access Package stays in control as the ultimate authority for the governance decision. Entra ID Governance tracks exactly when a user gains or loses access, and the Custom Extension triggers a Logic App as part of that event.

However, we hit one last physical roadblock: Exchange Distribution Group membership cannot be updated through Microsoft Graph. You can read them through the API, but modifying them is blocked. To get around this final hurdle, the Logic App passes the payload to an Azure Function running PowerShell, which handles the actual Exchange Online heavy lifting using a zero-secrets framework.

[Entra ID Access Package]

          │
          ▼
[Custom Workflow Extension]

          │
          ▼
[Logic App] (Identity A - Entra Scoped)

          │
          ▼
[Azure Function] (Identity B - Exchange Scoped)

          │
          ▼
[Exchange Online DL]

Behind the Code: Security & Deployment Governance

When taking a design like this from a whiteboard sketch and putting it into production, I wanted to avoid the classic internet tutorials that tell you to click around the portal, generate a Client Secret, and store it in Key Vault.

Secrets expire, people forget to rotate them, and things break.

To keep this solution clean and production-ready, it relies on three core design choices:

Idempotency (No Messy Update Scripts): The entire setup is run via a single .bicepparam parameter file. If the business changes their mind or you need to add new Access Package-to-DL mappings, you do not write a custom update script. You just edit the parameter file and rerun the Bicep template. The deployment engine figures out the differences and updates the cloud state automatically.

Declarative Identity Natively in Bicep: Instead of using separate scripts to create App Registrations, the entire identity layer—including the Entra ID Application and Service Principal—is written directly into our infrastructure templates using the Microsoft Graph Bicep extension. Everything deploys in a single pass without generating a single static password.

Split Identities (Least Privilege): The architecture uses two completely separate User-Assigned Managed Identities. The Logic App identity can only talk to the Entra catalog. The Azure Function identity is the only one that can touch Exchange Online, and it is locked down using the modern RBAC for Applications model. It is restricted to running exactly four cmdlets (Add/Remove/Get-DistributionGroupMember and Get-DistributionGroup). If someone somehow manages to hijack the Logic App workflow, they still do not get broad write access to your email system.

Summary

The Exchange Online complexity stays hidden inside a lightweight Azure Function, triggered through Custom Extensions. The Distribution List stays exactly what the business wanted in the first place: a simple list of people to email.. Meanwhile, the identity team gets the full auditing, approval steps, and lifecycle controls of Entra Entitlement Management.

I have open-sourced the entire project framework. The full repository includes the validated Bicep modules, the Exchange permission setup skripts, and the PowerShell function code. You can find it on GitHub under EntraGovernance-Scripts.

The project lives in the Logic Apps/ Distribution List Membership folder alongside my other governance automation tools, like the Manager Flag Sync and Password Reset pipelines. Take a look at the QUICKSTART.md inside the project directory to get it running in your own lab environment.