The change means a Mac user’s click on Send can trigger a pre-send DLP evaluation rather than allowing the message to depart immediately and applying policy action afterward. For compliance teams, that is the difference between detecting a policy match after delivery has begun and holding the message while Exchange Online evaluates sensitive content, labels, recipients, and other conditions in the organization’s Purview rules.
Microsoft’s roadmap entry is terse, but its Purview documentation for the already-supported new Outlook for Windows provides the important operational detail: wait-on-send is governed by centrally managed Exchange Online mailbox settings, rather than by a Mac-specific local preference. That should make the policy model more consistent across managed endpoints, but it also means administrators need to understand the timeout and override behavior before turning the feature on broadly.
A pre-send hold changes the DLP control point
Most email DLP deployments are familiar with policy tips: Outlook warns a sender that content or recipients match a policy, and the organization can decide whether users may override the warning. Wait-on-send adds a separate control: Outlook delays delivery while it waits for DLP evaluation to complete.
Microsoft describes the Windows implementation as a background evaluation experience. Users receive a temporary notice that Outlook has not sent their message because it is evaluating content, but the client remains usable. Assuming the Mac implementation follows that design, this is not intended to freeze Outlook during every send operation. It does, however, introduce a deliberate delay at the moment users expect email to leave their Outbox.
That delay has a practical security purpose. DLP policies can inspect whether a message contains sensitive information types, carries a sensitivity label, targets particular recipients or recipient domains, or includes matching attachments. A policy tip seen while composing is useful, but it is not the same as ensuring that evaluation has completed at the final Send action.
Organizations that have treated Outlook for Mac as the exception in a cross-platform mail control strategy should pay attention here. Mac users can already receive Purview DLP policy tips, according to Microsoft’s documentation for Outlook on macOS, iOS, and Android. The pending feature is the pre-send enforcement wait, which changes the risk posture for messages that need a server-backed assessment before outbound delivery.
The timeout is a security decision, not a cosmetic setting
Microsoft’s documentation for new Outlook for Windows identifies two Exchange Online controls: DLPWaitOnSendEnabled, which enables the experience, and DLPWaitOnSendTimeout, which determines how long Outlook waits before it can offer an override.
The published range is 0 through 10,000 seconds, with behavior that deserves more attention than the roadmap entry gives it. At zero, the user sees a Send Anyway option immediately; the organization has enabled the interface without establishing a meaningful pre-send wait. At 25 seconds, for example, Outlook waits up to 25 seconds for the evaluation before it can offer a bypass. At values of 9,999 seconds or more, Microsoft says the user cannot send until DLP evaluation is complete.
The significance is straightforward: a timeout does not stop evaluation when the timer expires. It changes whether the sender gets the opportunity to transmit before evaluation has returned a result. A short timeout is therefore a user-experience compromise, while a near-unlimited timeout turns wait-on-send into a stronger gate that can affect business workflows during service or connectivity delays.
This makes September’s Mac support more than a feature-parity item. An enterprise with strict outbound controls could enable a no-override configuration and, for the first time, impose the same basic pre-send rule on users who send from Outlook for Mac. Conversely, an organization that picks a low timeout to avoid complaints may create a policy that looks stringent in configuration review but still permits users to send messages before inspection finishes.
Microsoft has not yet published the Mac-specific documentation that confirms the exact UI, timeout semantics, client-version requirement, or whether there are Mac-only differences in how the settings are surfaced. Those are material deployment details, particularly for mixed fleets that run both legacy Outlook for Mac and the newer client experience.
Existing Purview policy design still determines what gets caught
Wait-on-send does not create a new DLP classification engine or repair weak mail rules. It gives the existing Purview evaluation more time to finish before delivery. Administrators should review the underlying policies now rather than treating the rollout as a switch that makes every outbound message safer by default.
Microsoft’s Purview guidance shows that Outlook DLP support varies by license, condition, and policy action. Microsoft 365 E3-equivalent licensing supports core sensitive-information and Microsoft 365-content scenarios, while several richer conditions—including sensitivity labels, recipient and recipient-domain conditions, subject keywords, unlabeled content, and file extensions—are associated with E5-equivalent licensing in Microsoft’s new Outlook documentation.
That licensing distinction can create an uncomfortable mismatch between what a security team believes its policy examines and what a particular mail client can actually enforce or show to the user. The arrival of wait-on-send on macOS does not remove those entitlement boundaries. It also does not make every Purview policy eligible for every Outlook policy-tip experience.
There are other scope limits. Microsoft’s documentation says policy tips are not supported for meeting invitations in its Outlook for Microsoft 365 guidance. Administrators should therefore avoid presenting wait-on-send as a blanket outbound-message control until Microsoft publishes the Mac feature’s final support matrix. Calendar workflows, shared-mailbox scenarios, encrypted mail, offline behavior, and messages with large or unusual attachments all warrant explicit pilot testing.
The roadmap also does not name a minimum Outlook for Mac version, a preferred update channel, or a phased rollout schedule within September. “General availability” on a Microsoft 365 Roadmap entry identifies the intended release phase, not a promise that every tenant and every managed Mac will receive the feature on the first day of the month.
Windows deployments offer a warning about testing
There is a useful lesson in the existing Windows implementation. Microsoft’s Office release notes acknowledge fixes for an issue in which users could not send mail while the dlpwaitonsendtimeout setting was enabled. Separately, a Microsoft Q&A thread described intermittent hangs during content evaluation in an environment using Purview oversharing pop-up policies and a wait-on-send setting. A community Q&A report is not confirmation of a Mac defect, but it illustrates why a pre-send hold must be tested under real network and policy conditions rather than only in a clean lab tenant.
The likely pressure points are predictable: devices on VPNs, corporate proxies, unstable Wi-Fi, high-latency networks, mailboxes subject to many DLP rules, and messages that contain sizable or complex attachments. Each may lengthen the interval between Send and completed classification. For a user, that can look indistinguishable from a stuck message unless Outlook’s notification clearly explains that the message is being evaluated.
IT teams should also test what their support desk will see. A blocked DLP result, a policy-tip warning, a permitted override after timeout, and a message still under evaluation are different states requiring different remediation. If staff are told only that “Mac DLP is now enabled,” they may escalate normal policy behavior as an Outlook outage—or, worse, teach users to retry, copy content into another client, or move work to unsanctioned channels.
A controlled rollout should include representative users from finance, HR, legal, sales, executive support, and any group that routinely sends externally. Those teams are more likely to encounter the recipient- and label-based rules that make wait-on-send consequential. It should also include Macs both on and off the corporate network, because the pre-send experience depends on a timely service evaluation rather than only a local client setting.
What administrators can do before September
There is no need to wait for Outlook for Mac support to begin the planning work. The feature is listed as in development as of August 24, 2026, so production rollout should not be assumed until Microsoft marks it available and publishes its final Mac guidance. But tenant administrators can use the time to validate the controls and policies that will govern it.
- Review Purview DLP rules that apply to Exchange email, with particular attention to rules that block external recipients, detect sensitivity labels, or allow user overrides.
- Decide whether the organization’s risk model calls for a finite timeout with a documented override path or a configuration that prevents sending until evaluation completes.
- Confirm which groups and mailboxes should be in the first deployment ring, and identify business processes where a delayed send could cause operational harm.
- Measure current DLP evaluation and policy-tip behavior on Windows and Outlook on the web, especially from remote networks, before using those observations to set a Mac timeout.
- Prepare help-desk guidance that distinguishes an evaluation delay from a hard DLP block and explains how users can resolve a legitimate policy match.
Microsoft has made clear that the Mac release will reach commercial and government cloud environments, including GCC High and DoD. What remains unannounced is the exact client prerequisite and the final operational documentation Mac administrators will need. The September rollout will give Purview administrators a stronger way to stop sensitive messages at the point of send on macOS—but only if their policies, timeout choices, and user support plans are ready for the hold that follows.