Why Does an Outlook Public Folder Reject Emails With Multiple Recipients?

Short answer: A mail-enabled public folder has its own delivery permissions, separate from any user mailbox, and those permissions are checked per recipient, not per message. When a message goes to a public folder along with other people, Exchange evaluates the public folder's copy against its own rules independently, so it's entirely possible for every other recipient to receive the message normally while the public folder alone rejects it.

• If the rejection only happens when other recipients are on the message: it isn't really about the other recipients - it's the public folder's own delivery restriction or permissions being evaluated for the first time in that scenario.
• If you got a bounce citing STOREDRV.AuthenticationRequiredForPublicFolder: this is a permissions problem, and the fix is a specific permission grant, covered below.
• If external senders are rejected but internal ones aren't: check the "require that all senders are authenticated" setting first.
• If nobody received the message at all, including other recipients: that's a different problem entirely - a recipient-count limit on the whole message, not the public folder specifically.

A Genuinely Different Kind of Rejection

Most Outlook delivery problems trace back to reputation, authentication, or a spam filter. Public folder rejections are different - they're almost always a permissions and configuration question, specific to how mail-enabled public folders are set up, and they show up in a distinctive way: a message with several recipients where every human being on it receives it fine, and only the public folder bounces.

That pattern - works for everyone except the shared folder - is what sends people searching for why a public folder specifically rejects multi-recipient mail, as if adding people to the message is what caused the problem. It generally isn't. Adding other recipients is what exposes a restriction that was already there; the public folder would likely have rejected the same sender even as the sole recipient, but nobody happened to test that exact combination until it showed up as part of a bigger message.

It's also a topic search engines and generic troubleshooting articles handle badly, because most deliverability advice assumes the recipient is a person's mailbox with a spam filter, not a shared folder with its own permission model entirely. The fixes below come from how mail-enabled public folders are actually documented and actually configured, not from generic spam-filtering advice applied to a folder it was never written for.

This is a niche, admin-facing topic, and it deserves genuinely specific treatment rather than a generic filtering checklist. If your problem is closer to ordinary inbox filtering or tenant-wide blocking of a normal user mailbox, how to check if Outlook is auto-rejecting your email covers that broader diagnostic path. This page is specifically about public folders.

What a Mail-Enabled Public Folder Actually Is

A public folder is a shared storage location inside an Exchange organization, commonly used for shared calendars, shared document collections, or a shared inbox-style address a team monitors together. Mail-enabling one gives it its own email address, so people can send it messages the way they would send to any mailbox, and those messages land as items inside the folder rather than in anyone's personal inbox.

The important distinction from a regular mailbox: a public folder isn't a full mailbox with its own independent identity in every system. It has a narrower set of properties, a different permission model, and - critically for this guide - it doesn't participate in some of the same directory-based checks a real user mailbox does. That gap is directly responsible for several of the specific failure modes below.

Admins manage mail-enabled public folders in the Exchange admin center, under Public folders, or through Exchange Online PowerShell for anything the web interface doesn't expose directly.

How a folder becomes mail-enabled in the first place

Public folders themselves live inside one or more public folder mailboxes, a separate storage layer from the folders' own addresses and permissions. Mail-enabling a specific folder is a deliberate, one-time step an admin takes - it doesn't happen automatically just because a folder exists - and it's what actually creates the folder's email address and activates everything covered in this guide: delivery restrictions, client permissions, and the option to configure moderation. A public folder that was never mail-enabled can't receive email at all, so if a folder seems to have no delivery settings whatsoever rather than restrictive ones, confirm it was actually mail-enabled before troubleshooting anything else.

The Permission Model: Delivery Restrictions Explained

Every mail-enabled public folder has its own delivery restriction settings, found under the folder's mail flow settings, in a section usually labeled Message Delivery Restrictions. This is where most rejections actually originate.

This will look familiar to anyone who has configured delivery restrictions on a regular user mailbox - Exchange uses a similar accept-from and reject-from model there too. The difference that matters here is the default posture: a newly mail-enabled public folder is far more likely to have been left with restrictive defaults or an authentication requirement nobody revisited, simply because folders tend to be set up once during a migration or a reorganization and then left alone for years, long after the person who configured them has moved on.

Beyond delivery restrictions, a public folder also has client permissions that separately control who can actually write items into it - covered in the error-codes section below, because a permissions gap here produces its own distinct, well-documented bounce.

Why Adding Other Recipients Exposes the Problem

Here's the mechanism worth understanding properly, because it explains the entire pattern people search for.

A message with several recipients isn't really one delivery - it's several independent delivery attempts bundled into a single conversation between mail servers. Each recipient is resolved and evaluated on its own. A colleague's mailbox has one set of rules; a distribution list has another; the public folder has its own delivery restrictions and permissions, entirely separate from everyone else on the message. Exchange can deliver successfully to every human recipient and, in the same breath, reject the public folder's copy, because nothing about the other recipients' successful delivery has any bearing on whether the public folder's own restrictions were satisfied.

In practice, this is why the failure looks tied to "multiple recipients" specifically: a sender who has direct Send As access to the folder, or who is explicitly listed under Selected senders, may never have hit the restriction when addressing the folder directly and alone. The moment the same sender - or, more often, a different sender entirely - includes the public folder alongside other people, replying-all to a thread, forwarding to a small group, the folder's restriction gets evaluated for the first time in that context, and it fails on its own terms, independent of everyone else on the message succeeding right next to it.

The practical implication for troubleshooting: don't chase "why does adding people break it." Chase "what does this specific sender's copy, addressed to this specific folder, actually satisfy" - the delivery restrictions, the authentication requirement, and the client permissions below, in that order.

A concrete example

A sales rep emails a prospect and, wanting the team to see the reply, adds a shared "deals" public folder as a Cc alongside two colleagues. The prospect and both colleagues receive the message normally within seconds. The public folder bounces with a permissions error, because nobody had ever actually tested sending to that folder directly - everyone on the team simply assumed it worked, since items were already sitting inside it from whenever it was first set up months earlier, most likely added directly rather than mailed in. The folder's restriction was there the entire time; this was just the first message that happened to try mailing into it from outside.

The Authentication Requirement Trap

The "Require that all senders are authenticated" checkbox is responsible for a large share of "why won't my public folder accept external mail" cases, and it's easy to overlook because its effect isn't obvious from its label.

With Accept messages from set to All senders, it looks like anyone should be able to send to the folder. But if Require that all senders are authenticated is also checked, that broader setting is overridden for anyone who isn't authenticated - which includes every external sender, since mail arriving from outside your organization doesn't carry the internal authentication an Exchange user's own send does. The practical effect: the folder silently rejects all external mail while continuing to accept internal mail perfectly normally, and unless someone knows to check this specific checkbox, it looks like a mysterious, inconsistent filtering problem rather than the one deliberate setting it actually is.

This also interacts with the multiple-recipient pattern from the previous section: a message forwarded internally first, then relayed onward, can pick up or lose authentication context depending on the path it takes, which is part of why the same public folder can accept a message in one flow and reject an apparently identical one arriving a different way.

To confirm this is the actual cause rather than a guess, have the same external sender try addressing the folder as the only recipient. If that single-recipient message also bounces with the same error, the authentication requirement - or a plain missing-permission problem covered next - is confirmed as the cause, independent of anything about the other recipients on the original message.

The Error Codes You'll Actually See

Two distinct, well-documented codes cover most real public folder rejections, and they point at different fixes.

The first code is specifically about who is allowed to write into the folder at all. The second is more often about the address itself resolving incorrectly - a legacy artifact of a public folder that was migrated from an on-premises environment and never fully re-pointed at the tenant's real accepted domain, sometimes compounded by an email address policy silently regenerating the wrong address whenever it runs.

Both are checked directly in Exchange Online PowerShell: the Get-PublicFolderClientPermission cmdlet for permissions, and Get-AcceptedDomain for the domain question - genuinely two different diagnoses that happen to produce superficially similar-looking bounces.

A general 550 5.7.1 policy rejection can also appear if the folder's delivery restrictions explicitly name a Reject messages from list that matches the sender, rather than simply omitting them from an allow list - functionally similar to the two codes above, but worth recognizing as a third, more deliberate variant: someone specifically added that sender or their domain to the folder's own reject list at some point, rather than the sender simply never having been granted access.

Moderation: A Second Way One Recipient Can Fail Alone

Public folders can be configured as moderated recipients, meaning a message addressed to the folder is held for a designated moderator's approval before it's actually delivered into the folder. This is a completely separate mechanism from delivery restrictions, and it produces its own version of the same "everyone else got it, the folder didn't" pattern.

When a message has multiple recipients and one of them is moderated, Exchange automatically creates a separate copy specifically for the approval workflow - the moderated recipient's delivery is contingent on that approval, entirely independent of whether the message reached every other recipient instantly and normally. If the assigned moderator has since left the organization, and no moderation bypass list has been configured to cover that gap, the message has no realistic path to ever being approved - it simply sits waiting for a decision nobody is in a position to make.

If a public folder is set up with moderation, check who the moderator actually is before assuming a delivery restriction is the cause. A moderator who left the company months ago is a surprisingly common, and easy to miss, explanation for a folder that used to accept mail and now quietly doesn't.

An admin can confirm this directly in Exchange Online PowerShell by checking the folder's ModerationEnabled and ModeratedBy properties, rather than guessing from behavior alone. If ModerationEnabled is true and the listed moderator no longer has an active mailbox, that mismatch is the entire explanation, and correcting it is as simple as assigning a moderator who's actually still there.

Recipient and Volume Limits That Look Similar But Aren't

Two more limits are worth naming, mainly so you don't misdiagnose them as the public-folder-specific problem this guide is otherwise about, because both of these affect the entire message, not just the folder.

Recipients per message

Exchange Online enforces a default limit of 500 recipients on a single message, adjustable by an admin up to 1,000. Exceed it, and the bounce - 550 5.5.3, citing too many recipients - applies to the whole send. Nobody gets it, not just the public folder. If a public folder is one address among a very large distribution, and the message fails for absolutely everyone, this is a different problem than anything else on this page.

Receiving volume limits

Public folders share the same general Exchange Online receiving limit as any mailbox or group - up to 3,600 messages an hour. This is a volume ceiling on the folder itself over time, not a property of any single message, and it only matters for a public folder that's genuinely high-traffic. It's worth ruling out for a heavily-used shared folder, but it's rarely the explanation for one specific message with a handful of recipients failing.

The practical test that separates all of these from a folder-specific permissions problem is simple: did anyone else on the message receive it. If yes, look at the folder's own restrictions and permissions. If no - if the entire send failed for every recipient - the cause sits with the message itself or the folder's total volume, not with anything about the folder's individual configuration.

Admin-Side Fixes, Step by Step

Work through these in order - each one rules out a specific cause before you move to the next.

1. Check delivery restrictions first. Open the public folder's mail flow settings and read Accept messages from, and specifically whether Require that all senders are authenticated is checked. If the failing sender is external, this single checkbox explains most cases on its own.
2. Check client permissions. Run Get-PublicFolderClientPermission against the folder and confirm the Default or Anonymous permission, whichever applies to your scenario, includes CreateItems. If it doesn't, that's your 5.7.13 bounce, and granting the right fixes it directly.
3. Check the folder's accepted domain. If the bounce is 5.4.1 rather than 5.7.13, confirm the folder's primary SMTP address uses a domain that Get-AcceptedDomain actually lists as accepted for the tenant, particularly if this folder was ever migrated from an on-premises environment.
4. Check for moderation. Confirm whether the folder is a moderated recipient, and if so, confirm the moderator is still a valid, active account with no gap in a bypass list.
5. Rule out the whole-message limits last. If literally nobody on the message received it, the cause is the recipient-per-message limit or the folder's hourly receiving ceiling, not anything specific to the folder's own permissions.
6. Test with the exact sender and exact recipient combination that failed - not just the public folder alone, and not just a different sender - since, as the mechanism above explains, the specific combination is often what exposes the restriction in the first place.

Keep a short record of what you found and changed, especially for a shared folder with more than one person capable of administering it. A folder's delivery restrictions get revisited during reorganizations, migrations, and security reviews, and without a note explaining why a restriction exists, the next admin who finds it has no way to tell a deliberate security decision from a leftover default - which is exactly how these problems get reintroduced after being fixed once already.

Where WarmySender Fits (and Where It Doesn't)

Worth being straightforward here: none of this is something WarmySender can fix, configure, or see. Public folder delivery restrictions, client permissions, and moderation settings live entirely inside the recipient organization's own Exchange tenant, and no outside sending platform - WarmySender included - has any visibility into another company's public folder configuration, let alone the ability to change it. If this is genuinely a public folder issue, the fix has to come from the recipient's own IT team working through the steps above.

Where a sending platform is relevant is upstream of this problem, in a narrower way: when B2B cold outreach lands on a shared, public-folder-backed address rather than a named person's inbox, and mail seems to be going nowhere, it's genuinely useful to be able to rule out your own side quickly. A verified list, a properly warmed mailbox, and paced sending mean you can be confident the silence isn't a reputation problem on your end before spending time asking a prospect's IT team to check their public folder settings. WarmySender's cold email campaigns, warmup, and mailbox health monitoring exist for exactly that - ruling out your own sending as the cause, not fixing anyone else's mail server. See how WarmySender works.