Cross-tenant recall: Exchange Online lets another company delete mail from your mailboxes

In mid-August Microsoft starts rolling out one of Exchange Online's most requested features of recent years: recalling an email you already sent to another company. Read from the sender's side, it sounds like a safety net. Read it from the other end of the wire, which is where most of us sit: from now on, somebody in another organisation will be able to make a message vanish from your people's mailboxes after delivery. And you do not switch that setting on to recover your own emails. You switch it on so other people can recover theirs from your mailboxes.

We are writing this from the side of the people who run other companies' tenants. We manage Microsoft 365 environments for businesses, and we know how this kind of news arrives: hardly ever from an administrator. It comes from a user who read a headline, or from head office. When it lands — and it will — it pays to have the answer ready, because the official notice is short and the consequences are not.

What recall already does today (and almost nobody has re-read)

Plenty of people still picture the recall of fifteen years ago: that message politely asking the recipient's Outlook to withdraw the mail, and failing almost every time. That one is gone. With cloud-based recall, the request is intercepted by an agent inside the service itself, and the word Microsoft's documentation uses for what it does to the original is hard-delete. It does not ask the mail client's permission, it does not depend on the recipient having Outlook open and, per the same page, the system keeps trying for up to 24 hours.

One detail on that page deserves reading twice. Outlook's dialog still says only unread messages are recalled, and the documentation contradicts it in as many words: "this statement is no longer accurate". There is an organisation-level setting deciding whether messages the recipient had already read can be recalled, RecallReadMessagesEnabled, and its default — blank — means enabled. Translation: today, inside your own organisation, a colleague can make an email you had already read disappear from your mailbox, while the prompt on screen says the opposite of what the system does.

The two switches governing all of this have been there for years, in a single command:

Set-OrganizationConfig -MessageRecallEnabled $true -RecallReadMessagesEnabled $true
# default value: blank, equivalent to $true for both

None of that is new. What changes in August is not how powerful recall is: it is who the order can come from.

What changes: MC1423106

Message Center post MC1423106 (roadmap ID 561330) announces cross-tenant message recall: until now recall only worked between mailboxes in the same organisation — in fact, as of today the Exchange Online documentation still lists as a limitation that "you can't recall messages over the internet, or across organizations", alongside mail heading to on-premises Exchange in hybrid setups: anyone going to the official page will read the opposite of what the notice announces — and from this rollout on it will cross the boundary between Microsoft 365 tenants. It starts in mid-August 2026 and completes in early September, for worldwide customers plus GCC, GCC High and DoD. Some coverage places general availability slightly later; the date that counts is the one in your Message Center, not the one in a news article.

The part they got right, and it deserves credit: it ships disabled and the receiving side decides. No external sender can pull anything out of your mailboxes unless you have enabled the feature and put their tenant ID on an allow list. You do it from Exchange Online PowerShell:

# 1) enable the feature in YOUR tenant (the receiving one)Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true

# 2) authorise specific tenants to withdraw mail from your mailboxesSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId1>","<tenantId2>"}

# 3) remove one from the list when the relationship endsSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Remove="<tenantId1>"}

If your console does not recognise the cmdlet when you run the first command, do not look for the fault in the tenant: update the Exchange Online Management module, because it is new and absent from earlier versions. If the sender's tenant is not on the list, their attempt fails and they get told cross-organisation recall is unavailable. The notice adds another detail worth keeping in mind: if you have recipient recall notifications switched on, they apply to recalls coming from outside as well. Which means your users will start receiving odd notifications from other companies, and somebody will have to explain them.

The asymmetry: that setting is not for you

Here is the point almost no coverage says out loud, and it changes the whole conversation. Enabling the feature in your tenant does nothing for you as a sender. For your salesperson to withdraw the price-list PDF they just sent to the wrong customer, the one who has to enable the setting and add your tenant ID to their allow list is the customer. By enabling it, you gain no capability whatsoever: you only grant one.

That makes this something other than a feature: it is a favour. And favours are not assessed by asking "how do I turn it on?", but "for whom, why, and what happens the day the holder of the favour is not who I thought it was?". It is exactly the question we ask about any permission granted to a third party inside a tenant; a few days ago we wrote about connected-app tokens that never ask for MFA again, and the mental pattern is identical: what gets granted one afternoon is still granted two years later, when nobody remembers why.

The problem is not a stranger: the allow list is already written

Think for a moment about who you would put on that list. Not strangers: head office, subsidiaries, the accountancy firm, the practice that runs payroll, the supplier you have used for years. Which is to say, exactly the same senders that show up in CEO fraud and invoice fraud, because that fraud does not live off tricking anyone with an odd domain — it lives off the trust that already exists between two companies that have been writing to each other for years.

It is worth not dramatising, because alarmism lies too. Whoever controls your supplier's tenant already has far better moves available than deleting mail: they can send mail as them, read the threads, change an IBAN in a template. This opens no new door for them. What it adds is one specific capability they did not have: withdrawing the message afterwards. And that is precisely the part that hurts when you have to reconstruct an incident, because an email carrying a doctored invoice that vanishes from the mailbox the day the payment has already gone out is not the same as one still sitting there, headers and all, for somebody to read calmly.

One brake works in your favour and appears in the same documentation: messages forwarded manually by the recipient, and those forwarded or redirected by an inbox rule, are not recalled. Automatic forwarding within the organisation is. Put another way: the copy your user sent to their boss by hitting "forward" survives the deletion. It is a small consolation and it depends on luck, but it explains rather well why recall is not a time machine.

A hard delete is not the end of the world either (for 14 days)

A hard delete in Exchange Online is not a shredder. Hard-deleted items land in the Purges subfolder of Recoverable Items when the mailbox has single item recovery or litigation hold enabled, and for the two cases it names the documentation states that putting a mailbox on in-place hold or litigation hold stops the automatic purging performed by the Managed Folder Assistant in the DiscoveryHolds, Deletions and Purges subfolders. With a Microsoft 365 retention policy the effect is equivalent but the folder differs: there, hard-deleted items are kept in DiscoveryHolds. And the recall page itself closes the loop in its FAQ: for mailboxes on litigation or in-place hold, the recalled message still shows up in eDiscovery.

A note of honesty before going on: the recall page does not say where the recalled original ends up. That comes from cross-reading it with the Recoverable Items page, and it is our reading, not a quote. With that said, the operational conclusion of this article carries a nuance worth not giving away: there is a net fitted as standard, but it runs on a clock. Single item recovery is enabled by default on every new Exchange Online mailbox, so a hard-deleted message stays in Recoverable Items and an administrator can pull it back during the deleted item retention period: 14 days by default, 30 at most. After that, nothing is left. Which yields the one practical instruction we give a service desk about this: when somebody says "an email has vanished", the search happens this week, not next month. And it also explains what retention or a hold is really for: they do not add the net, they remove the clock. Mind you, that does not turn retention into a backup — we already wrote about why a Purview retention policy is not a backup — but it is the difference between answering "I have it" and having to say "I don't know". It is also why Microsoft 365 backup stops being a theoretical debate the day a third party can trigger deletions in your mailboxes without going through you.

The gap that bothers us most: the logging

In that same FAQ there is a five-word answer that ought to be in bold in the notice and is not. Asked whether recalls show up in mailbox audit logs, the documentation replies: "No, not at this time." The place an administrator will look when a user says "an email has vanished" is exactly the place where this leaves no record.

There is a trail, but it sits elsewhere and it is more awkward: message trace records the recall message, and the detail of the Drop event is where you read whether the deletion succeeded — with the deeply counter-intuitive wrinkle that the status shown in the trace is Failed both when recall works and when it times out, and you have to open the detail to find the Result:Success. That is a rushed admin check at nine in the evening, not a dashboard. And when the recall comes from outside, the question "who deleted this?" will have an answer that does not live in your tenant.

How we will handle this in the tenants we manage

And one question we deliberately leave open, because we could not verify it: it is unclear whether the receiving tenant's RecallReadMessagesEnabled setting also governs recalls arriving from outside. If it does, setting it to $false is a decent middle brake for anyone who wants the feature only for messages not yet read. If it does not, that brake does not exist. It is one of the things we will ask before switching this on in a client tenant, and one of the things we will not assume.

When we would not switch it on

And to be fair to the feature, the case where we would enable it without argument: corporate groups dragging several tenants behind them from acquisitions, where "another organisation" is really the same company with a different domain and a different Microsoft agreement. There, cross-tenant recall is not a favour to a third party, it is fixing an artificial boundary that should never have existed. That scenario is more common than it looks and is probably the real reason Microsoft built this.

Three things we still do not know

We have not tested it, and we are saying so before anybody asks: the rollout starts now. Everything above comes from the Message Center notice, the Exchange Online documentation and the Recoverable Items documentation — not from a lab. Some things remain publicly undocumented: how many tenants the list accepts, exactly what the recipient sees if notifications are off, and whether the already-read limit applies in the external case. When we have it in front of us in a real tenant and can check, we will report it just as plainly, whichever way it goes.

The question to ask before saying yes

Almost every security decision in a tenant gets taken the same way: a new feature arrives, somebody asks whether it can be enabled, and the fast answer is "sure, it's Microsoft". The slow answer is asking who you are handing a key to, what that key opens, and who will hold it in two years. With cross-tenant recall the key opens one specific drawer — your people's mailboxes — and whoever uses it does not work for you. It does not need to be feared; it needs to be treated as what it is: a mail governance decision, not a setting. And governance decisions get taken with retention in place, a short list, and a date to look at it again. If you happen to be reviewing Exchange Online changes this week, by the way, the other open deadline falls on 31 August.

Sources (verified 8 August 2026): Message Center post MC1423106 "Introducing cross-tenant message recall in Exchange Online" (roadmap ID 561330; rollout mid-August – early September 2026; disabled by default; Set-CrossTenantRecallConfiguration cmdlet) — Microsoft 365 Message Center, reproduced by m365admin.handsontek.net and Petri; cloud-based recall mechanics, Set-OrganizationConfig -MessageRecallEnabled / -RecallReadMessagesEnabled, hard delete, retries for up to 24 hours, forwarding limitations and the answers on eDiscovery and audit logs — Microsoft Learn, "Work with Cloud-based Message Recall"; Recoverable Items folder and hold behaviour — Microsoft Learn, "Recoverable Items folder in Exchange Online". Social image: photograph "Shredded" by Mike Haw (Flickr), via Wikimedia Commons, CC BY 2.0.