Microsoft has quietly started rolling out a new Exchange Online policy that lets administrators set a tenant-wide default for whether commas act as recipient separators in Outlook. The policy, tracked under Microsoft 365 Roadmap ID 557676, is now live for the Worldwide Standard multi-tenant cloud and applies to Outlook on the web and the new Outlook for Windows. While it won’t force users into a single behavior—they can still override the setting—it gives IT teams a long-awaited way to align Outlook’s parsing logic with how their organization names people.

The Policy: What It Does and Doesn’t Do

The new control introduces a single Boolean parameter inside Exchange Online’s organization configuration: RecipientDelimiters. When an admin sets it to $true, commas become the default way to separate multiple email addresses in the To, Cc, and Bcc fields. Set it to $false, and commas are treated as just another character in a display name, which is critical for organizations that format directory entries as “Last name, First name.”

Microsoft’s Message Center notification (MC1239176) is explicit about three guardrails. First, no change happens automatically—the feature requires active admin configuration. Second, the setting is a default, not an enforcement; users can still flip the switch inside their own Outlook settings after the tenant default takes effect. Third, it touches only the modern Outlook experiences: the web client and new Outlook for Windows, not classic Outlook or third-party apps.

Two configuration commands underpin the feature. To enable comma separation by default:

Set-OrganizationConfig -RecipientDelimiters $true

To disable it, preserving commas as part of names:

Set-OrganizationConfig -RecipientDelimiters $false

To read back the current value:

Get-OrganizationConfig | Format-List RecipientDelimiters

Note the parameter name: Microsoft’s PowerShell reference uses “Delimiters” with a second ‘i’, though the Message Center text briefly showed “Delimeters” (a typo). Stick with RecipientDelimiters. And in some tenants, especially those that have never run organization-level customizations, you might need to first run Enable-OrganizationCustomization before Set-OrganizationConfig will accept the change.

Who This Affects

For home users and Microsoft 365 subscribers without an Exchange Online admin, nothing changes. The comma preference will still be a personal Outlook setting—no admin will force a default on you.

For IT administrators, the value is immediate but measured. If your global address list uses a “Surname, Given name” format, or if your finance, HR, or customer-service teams routinely paste contact lists from external systems that embed commas, setting RecipientDelimiters to $false can prevent Outlook from splitting names into phantom recipients. One admin quoted in internal channels put it bluntly: “We’ve been training users to avoid commas for years. Now we can finally make the tool match the directory.”

For end users in a managed tenant, expect a hands-off experience—until it isn’t. If your admin enables the comma-separator default, you’ll see commas start splitting recipients as you type. If you prefer the old behavior, you can still toggle it off in Outlook’s settings (under Mail > Compose and reply). The policy just changes what you get out of the box. The upshot: you retain autonomy, but the organization gains consistency for new hires and shared workflows.

Why This Matters: A Decades-Old Parsing Friction

Outlook’s address fields look simple, but they hide a parsing engine that decides in real time where one recipient ends and another begins. For years, the default separator differed between clients and even between versions of the same client. Classic Outlook used semicolons; Outlook on the web often accepted commas. Users learned to adapt—or, more often, hit send and then discover they’d invited “Jordan” and “Chen” instead of “Chen, Jordan.”

Microsoft’s own documentation now acknowledges the core conflict: organizations that store names with a comma (as in “Smith, Jane”) create a collision when the same keystroke means both “part of a name” and “next recipient.” The new policy sidesteps that collision by letting the business decide which meaning should win by default.

The pain is not theoretical. Helpdesk tickets about split recipients are common, and the volume spikes after directory updates or mergers, when name formats shift. Microsoft’s Message Center note explicitly calls out companies using the “Last name, First name” convention as key beneficiaries. For them, a single tenant-level toggle can make the compose experience feel native rather than hostile.

How to Test and Deploy the Policy

Don’t flip the switch without a pilot. The behavior seems trivial until you paste a spreadsheet of client names or reply to a thread where someone’s display name contains a comma. A structured test plan should include:

  • Realistic names with commas: Create test contacts named “Adams, Jordan,” “O’Connor, Riley,” and “Chen, Mei.” Type each into a new message. With RecipientDelimiters set to $false, Outlook should treat the whole string as one search term. With $true, it may try to resolve two separate names.
  • Multiple recipients: Enter Alex Kim, Priya Shah, Morgan Lee and verify that Outlook respects the chosen delimiter.
  • Pasted lists: Copy content from Excel, CRM apps, HR directories, Teams chats, and web pages. These are the real-world sources that trigger misparsing.
  • User override behavior: After setting the tenant default, manually change the setting inside Outlook on the web and new Outlook for Windows. Check whether the change sticks across browser restarts, and document where the toggle lives so support staff can guide users.

Only after these validations should you move to a broader rollout. Microsoft’s own recommendation: review existing recipient-formatting conventions, update helpdesk scripts, and communicate the change in plain language. A sample note: “To improve how Outlook handles names that include commas (like those in our directory), we’ve updated the default setting. You can still adjust your own preference at any time in Outlook’s settings.”

The Rollout: What Went Wrong and When It’s Ready

The roadmap entry marks the feature as generally available, but the path wasn’t clean. On June 2, 2026, Microsoft posted a notice on the roadmap that it was correcting an issue with setting the policy, and that work would complete by mid-June. A related Message Center update pushed the timeline further, estimating early July completion after earlier delays.

The takeaway: the policy is now live, but you should verify actual availability in your tenant before publishing a change plan. Run the Get-OrganizationConfig check; if the parameter doesn’t appear, the rollout may not have reached your region yet. Once it’s visible, the setting is safe to use, but treat the historical hiccup as a reminder to test in your own environment rather than relying solely on the roadmap status.

What’s Next

For now, the policy is scoped to Outlook on the web and new Outlook for Windows. Microsoft hasn’t confirmed whether classic Outlook or mobile clients will eventually respect the tenant default. That omission means mixed-client environments should communicate the setting’s boundaries clearly—don’t promise uniform behavior everywhere.

Also watch for further refinement of the Set-OrganizationConfig cmdlet. As Microsoft adds more user-facing compose defaults under administrative control, the same configuration surface may grow. For today, this one parameter solves a concrete, long-standing irritant. If your tenant struggles with comma-related recipient errors, it’s one of the simplest, lowest-risk configuration changes you can make.