Cross-Tenant Message Recall in Exchange Online: Setup and Limitations

What cross-tenant message recall actually does

Message recall in Exchange Online has traditionally been limited to a single organization: if you sent an email by mistake, you could only recall it if the recipient was in your own tenant. According to Microsoft Learn documentation, that boundary has now been extended through a feature called cross-tenant message recall, which allows a sender in one Microsoft 365 tenant to recall a message they sent to a recipient in a different Microsoft 365 tenant — but only under conditions the receiving organization controls.

For SMB administrators who regularly exchange email with partner organizations, vendors, or affiliated companies running separate Microsoft 365 tenants, this closes a long-standing gap: previously, a misdirected or sensitive email sent to an external partner simply couldn’t be recalled once it left your tenant boundary.

This article explains what is documented about cross-tenant message recall, how the allow-list model works, the PowerShell steps admins use to configure it, and the limitations admins should plan around.

How the allow-list model works

Cross-tenant recall is built around a simple principle, as described in Microsoft’s documentation: the receiving tenant is always in control.

A tenant admin can add other Microsoft 365 tenants to an allow list. Once a tenant is on that list, senders from the allow-listed tenant can recall messages they’ve sent to recipients in the receiving tenant, in the same way they would recall a message sent to a colleague inside their own organization. Crucially, a cross-tenant recall is only honored when the receiving tenant’s admin has explicitly allow-listed the sender’s tenant. There is no mechanism for a sending organization to force a recall into a tenant that hasn’t opted in.

A simplified example from Microsoft’s documentation illustrates the relationship:

• An admin at Organization A adds Organization B’s tenant to Organization A’s cross-tenant recall allow list.
• A sender at Organization B recalls a message they previously sent to a recipient at Organization A.
• Because Organization A allow-listed Organization B, the recall is honored and processed like a standard, same-tenant recall against the recipient’s mailbox at Organization A.

If Organization B had not been allow-listed, the recall would fail, and the sender would see in their recall status report that the message couldn’t be recalled across organizations. Each organization decides independently which external tenants it trusts to recall messages from its own users’ mailboxes — allow-listing is not mutual or automatic in both directions.

Admin configuration steps

Cross-tenant recall is configured using Exchange Online PowerShell, on the receiving tenant’s side. Connect to the receiving tenant with an account authorized to manage these settings before running the configuration commands. The examples below use explicit Boolean values; tenant ID placeholders must be replaced before execution.

1. Enable cross-tenant recall for your tenant

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true

According to Microsoft’s documentation, this setting is disabled by default ($False). An admin must explicitly set it to $True to allow any external tenant to recall messages, even after allow-listing a specific tenant.

2. Add or remove trusted sender tenants

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<trusted-sender-tenant-id>"}

Replace <trusted-sender-tenant-id> with the verified tenant ID of your partner organization before running the command. To remove that tenant later, run a separate command:

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Remove="<trusted-sender-tenant-id>"}

The Add and Remove examples are separate operations; run only the operation you intend.

3. Obtain the sending tenant’s ID

The documentation notes that the administrator of the sending tenant can retrieve their own tenant ID by running:

Get-ConnectionInformation | fl TenantID

That tenant ID is what gets shared with the receiving organization’s admin so it can be added to the allow list.

Practical recommendation: Because this is a trust relationship between two separate organizations, it’s worth treating allow-list entries the same way you’d treat any cross-organization access grant — document who requested it, why, and review the list periodically. This is a governance suggestion, not a documented Microsoft requirement.

Licensing and availability

The supplied Microsoft documentation describes the feature’s configuration and behavior in detail but does not specify a distinct license or subscription requirement specific to cross-tenant recall itself. Admins should not assume a particular licensing tier is required for cross-tenant recall based on this documentation alone; if your organization has specific licensing questions, confirm directly with Microsoft before relying on the feature for compliance-sensitive scenarios.

Separately, the documentation does note that recalling messages that were encrypted with Microsoft Purview Message Encryption or sensitivity labels requires the sender to be assigned the Premium Encryption in Office 365 service plan and to trigger the recall from Outlook on the web or new Outlook. This licensing detail applies to encrypted message recall generally, not specifically to the cross-tenant scenario, so treat it as a related but separate consideration.

Microsoft’s Exchange Team announcement gives a planned rollout window from mid-August to mid-September 2026, covering worldwide, GCC, GCC High, DoD, and Microsoft 365 operated by 21Vianet. This is the announced schedule, not confirmation that the feature is available in every individual tenant. Check your tenant’s current availability before relying on it.

Important limitations to plan around

Microsoft’s documentation calls out several boundaries that SMB admins should understand before relying on cross-tenant recall:

• Exchange Online boundary only. Cross-tenant recall works only between two tenants that are both in Exchange Online. You cannot recall a message that was sent over the general internet or to an organization outside the Exchange Online boundary.
• Hybrid environments are excluded for one direction. For hybrid customers, messages sent from cloud mailboxes to an on-premises Exchange environment cannot be recalled.
• Recall status is tenant-specific. If the receiving tenant hasn’t allow-listed the sender’s tenant, the sender’s recall status report will show that the message couldn’t be recalled across organizations — there’s no ambiguity about whether it worked.
• General recall limitations still apply. The broader limitations of Exchange Online message recall also apply to cross-tenant recalls. These include issues with Outlook in Online mode with multiple accounts configured, messages sent to mail-enabled public folders (which can never be recalled), and messages forwarded outside the organization or via inbox rules (which also can’t be recalled).

Verifying whether a cross-tenant recall succeeded

As with ordinary recalls, Microsoft’s documentation recommends using message trace to confirm recall outcomes if the automated Message Recall Report doesn’t arrive or doesn’t update as expected. The recall process runs for up to 24 hours, and a Failed status in message trace doesn’t necessarily mean the recall failed — it can also appear once a recall has succeeded and the system has finished processing it. To get a definitive answer, admins can pull the Drop event detail from message trace, which includes a Result value of Success or Failed once the Message Recall feature agent has finished processing the recall.

Start with the sending mailbox’s recall report. If you need to investigate further, use the message-trace guidance linked in the Microsoft Learn source and inspect the recall message’s Drop event.

Practical considerations for SMB admins

A few practical points worth keeping in mind, presented as recommendations rather than documented Microsoft guidance:

• Because allow-listing is one-directional and tenant-specific, if two partner organizations want to recall messages sent to each other in both directions, each organization’s admin needs to separately enable cross-tenant recall and allow-list the other’s tenant ID.
• Before relying on cross-tenant recall as a safety net for sensitive outbound email to partners, test the configuration with a non-sensitive message first to confirm the allow list and recall settings are working as expected in your environment.
• Keep a record of which external tenant IDs are allow-listed and why, since this is effectively a trust relationship that grants another organization’s senders a recall capability into your users’ mailboxes.

Conclusion

Cross-tenant message recall extends Exchange Online’s existing cloud-based recall capability beyond a single tenant, but it does so within a carefully controlled model: the receiving organization decides which external tenants are trusted, and nothing happens without that explicit allow-listing. For SMB admins who collaborate closely with partner organizations also on Microsoft 365, this is a meaningful addition to the mail flow admin toolkit — but it’s bounded by clear limitations, including the Exchange Online-only boundary and the exclusions around hybrid on-premises mailboxes.

Before enabling the feature with a partner, verify the tenant IDs, agree on the direction of trust, and test a recall with a non-sensitive message. Keep the allow list under review as partner relationships change.