Microsoft 365 email forwarding blocked: how to fix the 5.7.520 error

You set up a rule to forward work email to another address, and suddenly people get bounces. Or a supplier tells you their message to you "failed" with an error about external forwarding. Both are the same Microsoft 365 control at work. This guide explains how to tell which control blocked the forward, how to allow it for one person without opening it for everyone, and when you shouldn't allow it at all.

What does error 5.7.520 mean?

Error 5.7.520 means Microsoft 365 detected a message being automatically forwarded to a recipient outside your organization and blocked it because an outbound spam policy doesn't allow external forwarding. Microsoft Learn gives the bounce text as:

5.7.520 Access denied, Your organization does not allow external forwarding.
Please contact your administrator for further assistance. AS(7555)

Microsoft's article gives only the enhanced status code, 5.7.520, which many people search for as "550 5.7.520", the form our reference page uses. The message itself wasn't spam. "Automatic forwarding" means one of two things in Microsoft 365:

• an Inbox rule a user created (in Outlook or Outlook on the web) that forwards or redirects mail outside, or
• mailbox forwarding, also called SMTP forwarding, which an admin sets on a mailbox in the Exchange admin center.

Forwarding a message by hand with the Forward button isn't automatic forwarding and isn't affected. Neither is automatic forwarding between users inside the same organization. Our 550 5.7.520 reference page summarizes the code; this guide is the full troubleshooting path.

Why did forwarding suddenly stop working?

Forwarding usually "suddenly" stops because the setting nobody touched has a confusing default. The control is Automatic forwarding rules in the outbound spam policy, with three values. Microsoft's outbound spam policy documentation describes them:

Microsoft says that because the behavior of the Automatic value "can differ by organization," you should configure On or Off explicitly. So the usual triggers are a new tenant, a migration into a new tenant, or a security review that set the default policy to Off. Each is working as designed. The full set of outbound settings is in our outbound spam policy guide.

Who sees the bounce?

The bounce goes back to the person who sent the original message, not to the person whose mailbox forwards it. That confuses everyone. Microsoft's configuration article adds a twist: when forwarding is blocked, NDRs are generated for:

• Messages from external senders, for all forwarding methods.
• Messages from internal senders only if the method is mailbox forwarding. "If the forwarding method is an Inbox rule, an NDR isn't generated for internal senders."

In practice, the user who set up the rule often has no idea it's failing. Colleagues get nothing back. Customers and suppliers get a bounce that looks as if their email failed, even though the original message was delivered to the mailbox. If you received a 5.7.520 bounce as an outside sender, your message probably arrived; tell the recipient by phone or another address, and forward them the bounce.

If you're the admin and an outside sender reports the bounce, reply with something short and specific. For example: "Thanks for letting us know. Your message reached our colleague's mailbox, but a forwarding rule on it tried to copy your email to an outside address, which our policy blocks. We're fixing the rule. You don't need to resend." Then fix or remove the rule the same day, because every message to that mailbox will keep bouncing for external senders until you do.

Which control blocked the forward?

Microsoft 365 has three separate controls that can stop automatic forwarding, and each leaves a different trace. Microsoft's rule for combining them is: "When one setting allows external forwarding, but another setting blocks external forwarding, the block typically wins."

The silent case is the hardest to spot. Microsoft's remote domains article says if you turn off automatic forwarding on the default remote domain, users "can change their settings or create the Inbox rule, but their messages won't be forwarded," and "No error message is sent." It also notes a gap: remote domain settings don't affect mailbox forwarding set by an admin or forwarding done by mail flow rules.

The last row matters too. When forwarding works, the forwarded copy often fails SPF at the destination, so it lands in spam. That isn't a Microsoft 365 block; see why email forwarding breaks SPF and DMARC.

How do you find the mailbox that's forwarding?

The mailbox that's forwarding is the one the sender originally emailed. The NDR goes to that sender, so ask them for the full bounce and the address they wrote to; the rule or forwarding setting lives in that recipient's mailbox. Then check the mailbox in Exchange Online PowerShell:

# Admin-set mailbox (SMTP) forwarding
Get-Mailbox -Identity user@example.com | Format-List ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward

# Inbox rules that forward or redirect, including hidden ones
Get-InboxRule -Mailbox user@example.com -IncludeHidden | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo } | Format-List Name,ForwardTo,ForwardAsAttachmentTo,RedirectTo

In the Exchange admin center, mailbox forwarding is under Recipients > Mailboxes: select the user, then under Mailbox > Email forwarding select Manage email forwarding. If neither command finds anything, the forward may come from a mail flow rule, so check the Auto forwarded messages report described below, which names transport rules by ID.

Is the forwarding rule legitimate?

Check before you allow anything. Microsoft notes users can set up forwarding rules "deliberately or as a result of a compromised account," and an unknown rule forwarding to a personal or random address is a classic sign of account takeover. In that case the 5.7.520 block is the policy doing its job.

1. Ask the user whether they created the rule, and why. A person who didn't create it needs compromised account remediation, not an exception.
2. Look at the rule itself: forwarding all mail, deleting or hiding the original, or matching words such as "invoice" and "payment" are red flags. Malicious inbox rules and auto-forwarding shows how to list hidden rules with Get-InboxRule -IncludeHidden.
3. Open the Auto forwarded messages report in the new Exchange admin center (https://admin.exchange.microsoft.com, Reports > Mail flow). It shows the forwarding type (mail flow rules, Inbox rules or SMTP forwarding), the recipient domain and the forwarding user. Its insights flag "New domains being forwarded email" and "New users forwarding email". By default it shows the last 7 days; Microsoft says the summary page can query up to 90 days, so widen the range if the rule is older.
4. Check sign-in logs for that user for unfamiliar locations, and signs your email account is compromised.

How do you allow forwarding for just one user?

Allow forwarding for specific users with a custom outbound spam policy set to On, and leave the default policy Off. Custom policies apply to the senders you name, so everyone else stays blocked.

In the Microsoft Defender portal

1. Go to Email & collaboration > Policies & rules > Threat policies > Anti-spam, or https://security.microsoft.com/antispam.
2. Select Create policy > Outbound.
3. Name it, for example "External forwarding allowed - approved users".
4. On Users, groups, and domains, add the user or a mail-enabled security group. A group is easier to audit later. For a Microsoft 365 Group whose own Inbox rules forward, Microsoft says to add the group in Users, because the forward uses the group's address as the sender.
5. On Protection settings, set Automatic forwarding rules to On - Forwarding is enabled. Leave the message limits at their current values.
6. Review and select Create. Then open Anti-spam outbound policy (Default) and confirm it is set to Off - Forwarding is disabled, so the exception is the only route.
7. Send a test message from an outside address to the user, and confirm the forward arrives with no bounce.

With PowerShell

The same result in Exchange Online PowerShell, using Microsoft's cmdlets (the group name is an example):

New-HostedOutboundSpamFilterPolicy -Name "Forwarding allowed" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "Forwarding allowed" -HostedOutboundSpamFilterPolicy "Forwarding allowed" -FromMemberOf "Approved forwarders"
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode Off

-From targets individual users and -SenderDomainIs a whole domain, which is rarely what you want here.

Limit where they can forward to

An exception for a user still lets them forward anywhere. To restrict destinations, Microsoft suggests a pattern: allow automatic forwarding in the outbound policy, "but use remote domains to control the external domains that users can forward messages to." Turn off automatic forwarding on the Default remote domain, then add a remote domain for each approved destination, such as your accounting system's inbound address domain, with automatic forwarding allowed. In PowerShell the setting is Set-RemoteDomain -AutoForwardEnabled. The Set-RemoteDomain reference says $true is the default for the built-in Default remote domain in Exchange Online and for new remote domains you create, so nothing is restricted here until you change it. Remember that this tenant-wide change also silently stops Inbox-rule forwarding to every other domain, and doesn't apply to mailbox forwarding set by an admin.

What are the common scenarios, and the right fix for each?

Most forwarding requests fall into a few patterns. These are our recommendations, not Microsoft settings, and the right answer is often not forwarding at all.

• A person wants work mail on a personal address. Usually the answer is no. Offer the Outlook mobile app instead, so mail stays in the tenant.
• A shared inbox, such as accounts@, must reach a business app that processes invoices or support tickets. This is a legitimate case. Add the forwarding mailbox to the custom policy and allow only the app's domain through remote domains.
• A staged migration to or from Google Workspace forwards mail for users not yet moved. Allow it for the migrating group only, and remove the exception when the move ends; see our Microsoft 365 to Google Workspace migration guide.
• A leaver's mail should reach their manager. That's internal forwarding, which the policy doesn't block. Convert the mailbox to a shared mailbox or forward internally.
• On-premises mailboxes in a hybrid setup. Microsoft says users who forward from on-premises systems through Microsoft 365 "are subject to the same policy controls as cloud mailboxes." The Auto forwarded messages report covers cloud accounts only. To see on-premises forwarders, Microsoft suggests a mail flow rule that matches any value in the X-MS-Exchange-Inbox-Rules-Loop header, sets a header such as X-Forwarded: True, and has a severity level so the hits appear in the Exchange transport rule report.

Next steps

• Look up the exact bounce text in the SMTP Error Code Lookup and confirm it is 5.7.520 and not another policy block.
• Run the Auto forwarded messages report and review every forwarding user and destination domain before granting exceptions.
• Set the default outbound policy to Off explicitly, and put approved forwarders in a custom policy set to On.
• If you must forward to outside systems, restrict destinations with remote domains, and recheck the list every quarter.
• If you're comparing how much of this your mail filter can handle for you, see how iBlockSpam fits in front of Microsoft 365.