Exchange Online address book policies (ABPs) let you give different groups of users different views of the Global Address List (GAL) inside one Microsoft 365 tenant. Microsoft describes the result as virtual separation, which means ABPs customize what people see in the directory and do not create a legal, security, or compliance boundary.
That distinction matters the moment a business unit asks for its own directory. A subsidiary wants its staff to stop seeing the parent company’s entire org. A newly acquired team needs to stay hidden until integration is finished. Meanwhile, shared executives, contractors, and conference rooms still have to show up in the right places. This guide walks Exchange administrators, messaging architects, and IT governance teams through designing, validating, and maintaining multi-department GAL segmentation, including what happens when directory data is copied to mobile contacts.
TL;DR
- ABPs customize directory views. They do not block email, revoke permissions, or satisfy a regulatory requirement.
- Each policy bundles four components. One GAL, one offline address book (OAB), one room address list, and one or more address lists.
- Filter quality decides success. Clean, consistently owned recipient attributes make segmentation reliable. Messy attributes make it unpredictable.
- ABP routing is a separate decision. Review the business impact before enabling the tenant-level setting.
- Pilot first. Test shared executives, new starters, transfers, external contacts, and unassigned mailboxes before a staged rollout.
- Mobile contacts need their own review. Saved contact copies on phones follow the rules of whatever distributes them, not the ABP.
What an address book policy controls
An address book policy assigns a mailbox user a specific set of directory views. A user with an ABP assigned sees the address lists, GAL, OAB, and room list defined in that policy when they browse or search the directory in supported clients.
Common business uses include:
- Subsidiaries and brands that share a tenant but want separate directories.
- Regional business units where staff only need colleagues in their own country or division.
- Post-acquisition environments where the acquired team stays in its own view until integration is complete.
- Departments with a legitimate need for a smaller directory, such as a clinical or trading group.
What an ABP does not establish matters just as much. A hidden entry in the directory can still receive email, appear in a user’s contacts if copied there, and be reached by anyone who knows the address. Reduced directory visibility is not the same as blocking communication, revoking permissions, or meeting a regulatory requirement. Treat an ABP as a usability and organization tool, and use mailbox permissions, transport rules, and your compliance tooling for anything that needs enforcement.
The four ABP building blocks
Every address book policy combines the same four components. Build them in this order, because the policy references the others.
| Component | What it does | Design note |
| One or more address lists | Filtered lists of recipients that users can browse | Filters rely on recipient attributes, so attribute quality drives accuracy |
| One GAL | The searchable directory the policy’s users see | A policy points to a single GAL, usually filtered per business unit |
| One OAB | The offline address book that Outlook downloads | Build it from the same GAL so offline and online views match |
| One room address list | The list of rooms users see when they book a space | Separate from a RoomList distribution group |
The last row trips people up. The ABP room list is an address list of room mailboxes that controls what users see in the directory. A RoomList distribution group is a different object that Outlook’s Room Finder uses. A room can appear in one and be missing from the other, so check both when a booking view looks wrong.
Component diagram specification
Hand this to whoever draws the diagram for your design review:
- Place one box per ABP in a row, labeled with the business unit name.
- Under each ABP, stack four boxes: GAL, OAB, room list, and address lists.
- Draw a single arrow from each ABP to its GAL and OAB.
- Draw a dotted arrow from a shared executives list into every ABP’s address lists.
- Add a separate box for the RoomList distribution group used by Room Finder, with no connection to the ABP boxes, to show the two are independent.
Design department and subsidiary boundaries
Consider a fictional company, Harbor Group, with two business units in one Microsoft 365 tenant: Harbor Advisory and Harbor Logistics. A central IT team supports both, and three executives work for the whole group. Each business unit wants a directory that shows its own people first.
Before you write a single filter, settle these design questions:
- Attribute ownership. Decide who maintains the attribute that drives each filter, such as Company or Department. If HR owns it, document the handoff to IT.
- Filter quality. A filter is only as good as the data behind it. Audit for blanks, typos, and inconsistent spellings first.
- Shared services. Central IT, finance, and HR serve both units, so they belong in both directories.
- Contractors. Decide which unit’s directory each contractor appears in, and which attribute marks them.
- Rooms. Decide whether each unit sees only its own rooms or also shared spaces.
- External mail contacts. Decide which units see which vendor and partner contacts.
The matrix below captures the expected visibility for Harbor Group. It uses fictional data and is the artifact to review with business stakeholders before you build anything.
| Directory entry | Advisory view | Logistics view | Central IT view |
| Advisory employees | Visible | Hidden | Visible |
| Logistics employees | Hidden | Visible | Visible |
| Shared executives | Visible | Visible | Visible |
| Central IT, finance, HR | Visible | Visible | Visible |
| Advisory contractors | Visible | Hidden | Visible |
| Advisory conference rooms | Visible | Hidden | Visible |
| Logistics conference rooms | Hidden | Visible | Visible |
| Shared vendor contacts | Visible | Visible | Visible |
Central IT gets the broadest view because administrators need to find every recipient. Remember that hidden does not mean unreachable. Anyone in Advisory can still email a Logistics colleague whose address they know.
Plan and implement the policy
Implementation follows four steps. Review Microsoft’s current procedures for each one, because cmdlet parameters and requirements change, and test everything in a pilot before it touches production mailboxes.
Inventory recipient attributes and administrative roles
List every recipient type you need to place: user mailboxes, shared mailboxes, room and equipment mailboxes, distribution groups, mail contacts, and mail users. Record which attribute each filter will use and who maintains it. Confirm that the administrators building the policy hold a role that allows managing address lists and assigning policies.
Construct and validate filtered lists
Build one address list per business unit, plus one for shared services. Before you save a filter, run the same recipient filter as a query and compare the results with your visibility matrix. Missing recipients and unexpected extras both show up here, and fixing them now is far cheaper than fixing them after assignment.
Create required components and the ABP
Create the GAL, OAB, and room list for each business unit, then create the policy that ties them to the address lists. Microsoft’s documentation covers the cmdlets for each component, including New-AddressList, New-GlobalAddressList, New-OfflineAddressBook, and New-AddressBookPolicy. Verify the syntax against the current procedure and test it in a non-production setting first.
Assign to pilot mailboxes and document onboarding
Assign the policy to a small pilot group first. Then write down how new starters and movers get the right policy. Manual assignment works at small scale, and automation based on the same attribute that drives your filters keeps the assignment correct as people join, move, and leave. Assignment requirements and unassigned-mailbox behavior are documented by Microsoft, so review them before you publish your internal runbook.
Decide whether ABP routing is needed
ABP routing is a separate tenant-level setting from the policies themselves. With standard ABPs, users see different directories, yet mail still flows between them as ordinary internal messages. ABP routing changes how mail between users in different virtual organizations is handled. Microsoft documents that recipients in another ABP can then appear with different contact-card and external-recipient behavior.
That difference carries real business impact. Users may see changed recipient details, external-style warnings, or altered handling of mail they previously treated as internal. Before you enable routing, review the following:
- Who sends to whom. Identify the cross-unit mail flows that your business depends on.
- Transport and compliance rules. Check whether any rule distinguishes internal from external senders.
- User communication. Decide how you will explain changes in recipient display.
- Rollback. Confirm how you would turn the setting off and what users would see afterward.
Read Microsoft’s current ABP routing documentation in full before you decide, and test the behavior with pilot mailboxes in two different policies.
Validate before a staged rollout
Run a pilot with real mailboxes before you assign the policy broadly. Confirm client behavior against Microsoft’s documentation for each client your users run, because ABPs do not behave identically everywhere, and some clients need a restart or reconnect before a new assignment shows. The OAB also needs time to regenerate, so offline views can lag behind the online directory.
Use this pilot checklist and record the result for each item:
- A pilot user in each business unit sees only the entries your matrix allows.
- Shared executives appear in every business unit’s directory.
- A new starter receives the correct policy through your onboarding process.
- A user who transfers between business units sees the new directory after the assignment changes.
- External contacts appear in the right directories and nowhere else.
- A mailbox with no assigned policy shows the behavior Microsoft documents, and you have decided whether that is acceptable.
- Room booking works in both the directory view and Room Finder.
- Outlook desktop, Outlook on the web, and mobile clients match expectations after reconnecting.
- Offline address book contents match the online view after regeneration.
- Monitoring is in place, and you know how to reassign pilot users to their previous policy if needed.
Stage the rollout by business unit, and keep the earlier assignment documented so a rollback takes minutes.
Keep mobile contact distribution aligned
Segmenting the directory in Exchange solves one problem. Getting contacts onto phones raises another. When a service account or application copies directory data into users’ mobile contacts, the copy follows the rules of the tool that made it. Do not assume an ABP automatically filters every sync product, or that it removes contact copies already saved on a device.
Treat mobile distribution as its own design review with four questions:
- Access. Which service account or application reads the directory, and what can it see?
- Source filters. Which contacts, groups, or lists feed each sync, and do they match your department boundaries?
- Destination users. Which users receive which set of contacts on their phones?
- Removal. What happens on a device when a contact leaves a source list or a user changes business units? Test this with a pilot phone, because the answer depends on the product.
A GAL sync approach puts the Global Address List on smartphones so staff can find colleagues without opening Outlook. In a segmented tenant, IT teams choose the approved contacts, groups, and calendars for each sync scope inside the sync tool itself. Our Directory to Phone solution page describes how that works for Microsoft 365 directories, and organizations that manage devices through MDM can read about MDM and CardDAV options.
We recommend confirming how your Exchange segmentation should map to each sync scope before launch. CiraSync sync scopes are configured separately from Exchange address book policies, so plan that mapping deliberately.
Maintain segmentation over time
A clean rollout drifts without upkeep. Schedule a recurring review, for example every quarter, that covers four areas:
- Assignments. Compare each mailbox’s assigned policy with its business unit, and look for mailboxes with no assignment.
- Attribute drift. Check the attributes that drive your filters for blanks, typos, and new values that no filter captures.
- Organizational change. Reorganizations, acquisitions, and divestitures change the boundaries, so update filters before the change takes effect.
- Exceptions. Keep a written list of every exception, such as a shared executive or a cross-unit project team, with an owner and a review date.
This review also catches the mobile side. When a business unit changes, check the sync scopes that feed phones as well as the Exchange policy.
See how this fits your environment
Planning departmental directories and wondering how phones fit in? Talk to our team about aligning a contact sync rollout with your departmental contact policies. We will map your Exchange segmentation to your sync scopes and show you where automation saves your team the most time.
FAQ
Are address book policies a security or compliance boundary?
No, Microsoft describes ABPs as virtual separation. They customize what users see in the directory and do not block email, revoke permissions, or satisfy a legal or regulatory separation requirement. Use permissions, transport rules, and compliance tooling for anything that needs enforcement.
Can one Microsoft 365 tenant have multiple GALs?
Yes. Address book policies let you define multiple GALs in one tenant and assign each to the users who should see it. Each policy references a single GAL, usually filtered for one business unit or region.
What happens when a mailbox has no assigned ABP?
Behavior for unassigned mailboxes is documented in Microsoft’s ABP assignment guidance. Review it before you roll out, decide whether that behavior is acceptable, and include an unassigned test mailbox in your pilot.
What is the difference between an ABP and ABP routing?
An ABP controls which directory views a user sees. ABP routing is a separate tenant-level setting that changes how mail between users in different policies is handled, including contact-card and external-recipient behavior. Review the business impact before you enable it.
Do address book policies automatically control saved iPhone contacts?
No automatic control should be assumed. Contacts copied to a phone follow the rules of the tool that distributed them, so review service-account access, source filters, destination users, and removal behavior as a separate design question.
