550 5.7.520 external forwarding blocked: why a forward bounces
550 5.7.520 means Microsoft 365 blocked an automatic forward to an outside address because your outbound spam policy has forwarding off. Confirm and fix it.
On this page(9 sections)
- What does 550 5.7.520 mean?
- What counts as automatic forwarding?
- Why is forwarding blocked in the first place?
- How do you confirm the block is in your tenant?
- Which setting do you change?
- How do you allow forwarding without opening it for everyone?
- What can you do instead of forwarding?
- What do you tell the sender whose forward bounced?
- Bottom line
The bounce "550 5.7.520 Access denied, Your organization does not allow external forwarding" means a Microsoft 365 mailbox tried to automatically forward a message to an outside address and the tenant's outbound spam filter policy refused. The rejection happens inside your own tenant, so the recipient's server never saw the message.
Most people meet this error when a user's rule or an admin's mailbox forwarding quietly stops working, or when a customer says "your reply never reached my other address". This guide covers what the code means, how to prove where the block is, which setting to change, and how to do it without opening forwarding for everyone.
What does 550 5.7.520 mean?
It is a permanent rejection, generated by Exchange Online, for a message that was detected as automatically forwarded to an external recipient. The reply code 550 and the enhanced status 5.7.x (a security or policy failure, see SMTP enhanced status codes, decoded) are standard. The full text Microsoft documents is 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555).
Per Microsoft's page on controlling external email forwarding, the sender gets this NDR when the outbound spam filter policy blocks the activity. Automatic forwarding between internal users is not affected by that setting.
What counts as automatic forwarding?
Automatic forwarding is mail that a rule or setting redirects without a person pressing Forward. Microsoft lists two kinds:
- Inbox rules a user created to forward messages to an outside address, on purpose or because an account was compromised.
- Mailbox forwarding (also called SMTP forwarding) that an admin set on a mailbox, with or without keeping a copy.
A person who opens a message and forwards it by hand is not automatic forwarding, and is not what this setting blocks. Mail forwarded from an on-premises system through Microsoft 365 is subject to the same policy as cloud mailboxes.
Why is forwarding blocked in the first place?
Forwarding is a favorite tool of attackers who take over an account: one hidden rule copies every new message to an outside address. Microsoft's own documentation names this risk, which is why new tenants block it. Per Microsoft, the outbound spam policy has three values for automatic forwarding:
| Setting | What it does |
|---|---|
| Automatic - System-controlled | The default. Since 2021 it behaves as Off for new organizations and for existing ones not actively using this value. Some older tenants still behave as On. |
| On - Forwarding is enabled | External automatic forwarding is allowed. |
| Off - Forwarding is disabled | External automatic forwarding is blocked and the sender receives the 5.7.520 NDR. |
Because "Automatic" behaves differently from tenant to tenant, Microsoft recommends setting On or Off explicitly. This is also why the same rule can work in one company and bounce in another.
How do you confirm the block is in your tenant?
Run a message trace and read the event, rather than guessing from the wording. A short checklist:
- In the Exchange admin center, run a message trace for the sender and recipient around the time of the failure.
- Open the details. The failure event shows the 5.7.520 text, which proves your tenant generated it.
- Check who forwards. Look for an Inbox rule on the source mailbox and for forwarding set by an admin. Microsoft's Auto forwarded messages report lists users who forward automatically.
- Note whether the mailbox is cloud or on-premises, since policy applies to both.
If the bounce text names a remote domain instead, or arrives from the recipient's server, you have a different problem. Compare it with the other 5.7.x rejections before changing anything.
Which setting do you change?
Change the outbound spam filter policy, then check two other controls that can override it. Microsoft says that when one setting allows forwarding and another blocks it, the block typically wins.
| Scenario | Result (per Microsoft) |
|---|---|
| Remote domain allows forwarding, outbound policy is Off | Forwards to those domains are blocked |
| Outbound policy is On, but a mail flow rule or remote domain blocks forwarding | Forwards to the affected recipients are blocked by the rule or remote domain |
So after you set the policy to On, also look at remote domains (the "Allow automatic forwarding" option) and any mail flow rules that detect forwarded mail. Microsoft notes that the rule-based check can use the X-MS-Exchange-Inbox-Rules-Loop header to spot messages forwarded by Inbox rules.
How do you allow forwarding without opening it for everyone?
Scope it. The default policy applies to everyone, so a narrow fix is safer than flipping the default to On.
- Create a custom outbound spam filter policy that sets automatic forwarding to On, and apply it only to the users who need it.
- Leave the default policy at Off.
- Use remote domains to list which outside domains may receive forwarded mail, which Microsoft describes as a way to allow forwarding in the policy while still controlling the destination.
- Write down the reason for each exception and review the list on a schedule. An unreviewed list of forwarders is the same risk you started with.
This is a security decision as well as a mail one, so a person who owns the tenant should make it. Where a team is moving mail to a shared mailbox anyway, a delegated or shared mailbox usually removes the need for an external forward.
What can you do instead of forwarding?
Forwarding to a personal address is also fragile for other reasons: copies lose authentication, land in spam and have no owner. Our guide on why forwarding to personal inboxes breaks and the one on forwarding rules gone wrong cover that side. Safer patterns include:
- Give the second person access to the original mailbox, as a delegate or through a shared mailbox.
- Use a shared inbox for addresses like support@ so the team reads and answers in one place.
- Use a rule that forwards inside the tenant only, which the setting does not block.
- Keep the data where it started and share a link or a note rather than copying whole threads out.
What do you tell the sender whose forward bounced?
Tell the person plainly that their organization blocks automatic forwarding, that the message did not reach the outside address, and that they should resend it directly or ask their admin. If the sender is your own customer, a short note helps: the message was received, but forwarding on their side is turned off. For wording on bounces, see explaining a bounced email to a customer in plain words.
Bottom line
550 5.7.520 is Microsoft 365 refusing an automatic external forward under the outbound spam filter policy. Confirm it with a message trace, set the policy explicitly instead of leaving "Automatic", check remote domains and mail flow rules because the block wins, and scope any exception to the users who need it. Where you can, replace external forwarding with shared access.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
