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

What cross-tenant Message Recall actually is

Microsoft has documented a capability called Cross-Tenant Message Recall as part of the broader Cloud-based Message Recall feature in Exchange Online. According to Microsoft Learn, this feature allows a sender in one Microsoft 365 tenant to recall a message they previously sent to a recipient in a different Microsoft 365 tenant — something that wasn’t possible with the classic, client-side message recall model.

This matters for SMB administrators because many organizations regularly exchange email with partners, vendors, or affiliated companies that run their own separate Microsoft 365 tenants. Before this capability, a message sent to an external tenant could never be recalled once it left your organization’s boundary. Cross-tenant recall changes that — but only under specific, admin-controlled conditions.

It’s important to be precise about scope: this is not a general internet-wide recall capability. Based on the documented limitations, cross-tenant recall works only between two tenants that are both hosted in Exchange Online, and only when the receiving tenant has explicitly agreed to allow it.

How the feature is documented to work

Microsoft Learn describes the mechanism using an example of two fictional companies, Contoso and Fabrikam, to illustrate the flow:

1. A Contoso administrator adds Fabrikam’s tenant ID to Contoso’s cross-tenant recall allow list.
2. A sender at Fabrikam recalls a message they previously sent to a Contoso recipient.
3. Because Contoso has allow-listed Fabrikam, the recall is honored and processed the same way a standard intra-tenant recall would be.

The key design point here is who holds control. According to the documentation, control sits entirely with the receiving tenant — the organization whose users’ mailboxes would be affected by the recall. A sending tenant cannot force a recall into another organization’s mailboxes unless that receiving organization has explicitly opted in by adding the sender’s tenant to its allow list.

If the sending tenant is not on the receiving tenant’s allow list, the recall fails. The sender sees this reflected in their recall status report, which indicates that the message can’t be recalled across organizations.

This is a meaningful governance distinction worth repeating: each organization independently decides which external tenants it trusts to delete messages from its own users’ mailboxes. There’s no global or mutual opt-in — the permission only flows one direction, from the receiving tenant’s decision.

Configuration prerequisites and PowerShell setup

Based on the documented commands, cross-tenant recall is configured through Exchange Online PowerShell rather than a graphical toggle alone, and administrators should expect to perform the following documented steps.

Step 1: Enable cross-tenant recall on the receiving tenant

The receiving tenant must explicitly turn the capability on. Per Microsoft Learn, this feature is disabled by default ($False), and must be enabled using:

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled <$true | $false>

Step 2: Add trusted sender tenants to the allow list

Once enabled, the receiving tenant’s admin adds the tenant IDs of organizations it trusts to perform recalls:

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId 1>","<tenantId 2>"}; {Remove="<tenantId 1>","<tenantId 2>"}

Step 3: Obtain the sending tenant’s ID

The administrator of the sending organization retrieves their own tenant ID so it can be shared with the receiving tenant’s admin:

Get-ConnectionInformation | fl TenantID

Practical recommendation (not a Microsoft requirement): Since tenant IDs must be exchanged manually between organizations, it’s worth establishing a simple, documented process for requesting and verifying tenant IDs with partner organizations before adding them to your allow list — for example, confirming the ID through a trusted communication channel rather than an unsolicited email request.

How cross-tenant recall fits into overall message recall behaviour

Cross-tenant recall operates on top of the general cloud-based recall mechanics that Microsoft has documented for Exchange Online, so it’s useful to understand the surrounding behaviour:

• Recall can be triggered from Classic Outlook, New Outlook, Outlook on the web, Outlook for Mac, and Outlook for Android/iOS.
• Once a recall is initiated, a feature agent intercepts the recall request and attempts to hard-delete the original message from recipient mailboxes.
• A Message Recall Report is emailed to the sender, typically within a few minutes, with a link to check recall status per recipient. The system continues attempting the recall for up to 24 hours.
• Recall reports are sent from Office365Reports@microsoft.com. Microsoft Learn specifically notes that admins should ensure this address isn’t blocked, since blocked or quarantined reports can prevent senders from seeing recall status.
• Organizations can also configure a Maximum Recallable Message Age, which defaults to 365 days and can be set anywhere between 5 minutes and 10 years using Set-OrganizationConfig -MessageRecallMaxRecallableAge.

None of these general settings are specific to cross-tenant scenarios, but they apply to recalls regardless of whether the recipient is in the same tenant or an allow-listed external one.

Documented limitations administrators should know

Microsoft Learn is specific about where cross-tenant recall does and doesn’t apply:

• It only works between two tenants in Exchange Online. You cannot recall messages sent over the general internet or to organizations outside the Exchange Online boundary.
• Hybrid environments have a gap. For hybrid customers, messages sent from cloud mailboxes to an on-premises Exchange environment cannot be recalled.
• Distribution list recalls have a reporting gap. Recalls triggered for messages sent on behalf of a distribution list generate a recall report sent to all list members, but members currently cannot view the recall status report because doing so requires sign-in credentials the distribution list doesn’t have.
• Shared and delegated mailboxes have recall quirks. Messages sent from shared or delegated mailboxes can be recalled, but the recall report may not be viewable by the person who sent it, since viewing the report requires signing in as the mailbox owner.

These limitations apply generally to the cloud-based recall feature, and several of them are directly relevant to cross-tenant scenarios — particularly the hard boundary around Exchange Online-to-Exchange Online recall only.

Other documented behaviours worth noting

A few additional FAQ-level details from Microsoft Learn are useful context for admins evaluating this feature:

• eDiscovery: For mailboxes under Litigation Hold or In-Place Hold, recalled messages still appear in eDiscovery.
• Audit logs: Recalls do not currently appear in mailbox audit logs.
• Forwarded messages: Messages automatically forwarded within the same organization can be recalled; messages forwarded outside the organization, forwarded manually, or forwarded/redirected by an inbox rule cannot be recalled.
• Encrypted email: Recalling messages protected with Office 365 Message Encryption (OME) or Microsoft Purview Information Protection (MIP) labels is supported only if the sender has the Premium Encryption in Office 365 service plan and triggers the recall from Outlook on the web or new Outlook.
• Recipient scale: There’s no documented hard limit on how many recipients a single recall attempt can target, but the recall status report itself is capped at roughly 50,000 recipients.

Practical considerations for SMB administrators

The following points are practical recommendations based on the documented behaviour above, not Microsoft-stated requirements:

• Treat the allow list as a trust relationship, not just a technical setting. Because recall gives an external tenant’s senders the ability to delete messages from your users’ mailboxes, it’s reasonable to apply the same vetting rigor you’d use for any cross-organization access grant.
• Communicate the feature to end users carefully. Since recall still depends on normal Outlook recall triggers and the receiving tenant’s allow-list decision, users at partner organizations may not understand why some recalls succeed and others don’t.
• Review your organization’s hybrid topology before assuming full coverage. If any part of your mail flow still involves on-premises Exchange, recall won’t reach those mailboxes, which is worth documenting for your support team.
• Keep an eye on the Office365Reports sender address in your mail flow rules, since a blocked or quarantined recall report can make it look like a recall silently failed when it may have actually succeeded.

Conclusion

Cross-tenant Message Recall, as documented by Microsoft, extends Exchange Online’s recall capability beyond a single organization — but only within a tightly scoped, opt-in model. The receiving tenant always holds the decision-making power through an explicit allow list, and the feature remains bounded by Exchange Online’s service boundary, with no reach into on-premises hybrid mailboxes or external internet-based email systems. For SMB administrators working closely with partner organizations, this is a configuration-driven capability worth understanding clearly before enabling it — particularly the PowerShell-based setup and the trust implications of allow-listing another tenant. As with any inter-organizational control, it’s worth validating tenant IDs and documenting the decision internally before turning the feature on. This article is a draft and requires human review before publication.