The Microsoft 365 non-delivery report (NDR) 5.7.520 Access denied, Your organization does not allow external forwarding (AS(7555)) means Exchange Online blocked an automatic forward to an address outside your Microsoft 365 organization. The usual cause is the outbound spam filter policy set to Off – Forwarding is disabled, but a destination-specific remote-domain setting or a mail-flow rule can also deny the message.
Fix it by checking the controls in order: verify that the recipient is genuinely external, inspect the applicable outbound spam policy in Microsoft Defender, review Exchange Online remote domains, then check mail-flow rules. If the business needs forwarding to only one outside domain, make the exception narrow and test every layer; allowing forwarding tenant-wide creates a data-disclosure path.
As an Amazon Associate I earn from qualifying purchases.
What the 5.7.520 external-forwarding error means
Microsoft documents this NDR as: “5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555).” It is a policy decision, not an indication that the destination mailbox is full or that the recipient address is necessarily invalid.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe message is generated when an automatic forwarding action tries to send mail from an Exchange Online mailbox to a recipient outside the tenant. Automatic forwarding includes a user’s Inbox rule and mailbox-level forwarding configured by an administrator. A user may still be able to create or save a rule while delivery is later denied, because the blocking control is evaluated when Exchange processes the message.
#1 Best Overall
“External” means outside the Microsoft 365 organization, not merely outside a particular department. Forwarding between users in the same tenant is not affected by the outbound spam policy. A rule from one internal address to another can continue to work even while an external destination produces 5.7.520.
Which control is blocking the message?
Microsoft 365 can evaluate more than one forwarding control. Use the scope of each control to narrow the diagnosis rather than changing settings at random.
| Control | Scope | What it can do | Where to review it |
|---|---|---|---|
| Outbound spam filter policy | Tenant or policy scope | Allow or block automatic forwarding to external recipients | Microsoft Defender outbound spam policy, Automatic forwarding rules |
| Remote domain | Destination domain | Set whether automatic forwarding is enabled for a particular remote domain, including the default * domain |
Exchange Online remote-domain configuration |
| Mail-flow (transport) rule | Message-specific conditions | Detect, block, redirect or otherwise act on automatically forwarded messages | Exchange mail-flow rules |
If one layer allows the message and another blocks it, the denial normally wins. Therefore, changing only the user’s Inbox rule or only one policy may not resolve the NDR.
Check whether the destination is really external
Start with the recipient address shown in the forwarding rule or mailbox setting. Confirm the domain belongs to the same Microsoft 365 organization, including any accepted domain used by your tenant. An internal alias, shared mailbox or secondary address can look different while still being hosted internally.
If the destination is internal, outbound spam-policy controls should not be the cause. Look instead for a mail-flow rule or another Exchange restriction that targets the message. If the destination is a personal mailbox, a supplier, a customer domain or another company’s tenant, treat it as external and continue with the policy checks below.
Review the outbound spam filter policy
The outbound spam policy has an Automatic forwarding rules setting with three choices:
- On – Forwarding is enabled: permits automatic forwarding to external recipients, subject to other controls.
- Off – Forwarding is disabled: blocks automatic external forwarding and can generate the 5.7.520 NDR.
- Automatic – System-controlled: Microsoft has changed the behavior of this setting over time, and its result can differ between organizations.
Microsoft recommends choosing On or Off explicitly rather than relying on Automatic. An explicit value makes the tenant’s security decision visible and avoids a system-controlled change unexpectedly altering forwarding behavior.
How to inspect the setting
- Sign in to the Microsoft Defender portal with an account that can view or manage outbound spam policies.
- Open the applicable outbound spam policy and locate Automatic forwarding rules.
- Record whether the value is On – Forwarding is enabled, Off – Forwarding is disabled or Automatic – System-controlled.
- Check which users, groups or domains the policy applies to. A more specific policy may apply to the affected mailbox instead of the organization-wide default.
- If forwarding is an approved business requirement, select On, save the policy, and test with a controlled external address. If it is not required, keep Off and remove or replace the external forwarding workflow.
Do not enable the setting merely because one user received the NDR. Automatic external forwarding can disclose invoices, passwords, personal data, legal correspondence and messages containing malicious links. Approval should come from the organization’s data-owner or security process, not from the mailbox user alone.
Understand the effect of disabling external forwarding
Microsoft states that disabling automatic forwarding disables both Inbox rules created by users and mailbox forwarding configured by administrators when they redirect messages to external addresses. The rule may remain visible in the mailbox, but messages will not be delivered to the outside address while the blocking policy applies.
This restriction does not disable forwarding between internal users. It also does not prevent a user from manually composing a new message and choosing an external recipient; it governs automatic redirection mechanisms.
Review Exchange Online remote domains
Remote-domain settings are evaluated by destination domain. The default remote domain, written as *, provides broad behavior for external domains, while a specific remote domain can set AutoForwardEnabled for one destination.
Microsoft notes that remote-domain settings can block automatic forwards even when users are still able to create the forwarding rule. Review both the default * entry and any specific entry matching the target domain. A specific domain policy may explain why forwarding works to one outside organization but fails to another.
Rank #3
- The Microsoft Office 365 Bible: The Most Updated and Complete Guide to Excel, Word, PowerPoint, Outlook, OneNote, OneDrive, Teams, Access, and Publisher from Beginners to Advanced
- ABIS BOOK
Controlled domain-level configuration
Exchange Online PowerShell uses the Set-RemoteDomain cmdlet for this setting:
Set-RemoteDomain -Identity <Name> -AutoForwardEnabled $trueUse $false instead of $true to disable automatic forwarding for the selected remote domain:
Set-RemoteDomain -Identity <Name> -AutoForwardEnabled $falseReplace <Name> with the remote-domain identity used in your tenant. Apply the change only after confirming the outbound spam policy permits forwarding; a remote-domain allowance cannot make a message succeed if another layer still blocks it.
Free tools Windows power users keep installed
One-click scans. No signup required.
Check mail-flow (transport) rules
A transport rule can detect automatically forwarded messages and block or redirect them. Such a rule may have been created for data-loss prevention, a regulatory requirement, a migration, or a previous security incident.
Review rules whose conditions identify automatic forwarding, external recipients, particular sender groups or the destination domain. Check both the rule’s conditions and its action. A rule that silently redirects the message can be as relevant as one that returns an NDR. Also check rule order and exceptions: an exception that covers one trusted domain may not cover a newly added address.
Because a block at any layer can deny delivery, a successful test requires the outbound policy, remote-domain setting and mail-flow rules to agree. If you change one setting and the NDR persists, continue through all three layers before reverting the user’s rule.
Step-by-step remediation sequence
- Capture the exact failure. Save the NDR, sender, forwarding target, time and affected mailbox. Confirm the code is 5.7.520 and note whether every external domain fails or only one.
- Classify the target. Verify whether the destination is inside or outside the Microsoft 365 organization. Internal forwarding should not be diagnosed as outbound spam-policy failure.
- Identify the forwarding mechanism. Determine whether the redirect is an Inbox rule, administrator-configured mailbox forwarding or another automated workflow. This tells you what will be affected if the policy remains Off.
- Inspect the outbound spam policy. In Microsoft Defender, open the policy that applies to the mailbox and check Automatic forwarding rules. If it is Off, that setting alone explains the NDR. If it is Automatic, make an explicit On or Off decision based on the organization’s risk acceptance.
- Review remote domains. Check the default
*domain and the specific destination domain. Confirm the relevantAutoForwardEnabledvalue and change it only within an approved allow or deny design. - Review mail-flow rules. Look for rules that block, redirect or otherwise match automatic forwarding. Check exceptions and rule order, then retest with a controlled message.
- Verify the result and document it. Test an approved external address, an unapproved external address if your change plan permits, and an internal address. Record which tests should pass or fail so future administrators can distinguish intended blocking from an outage.
How to allow forwarding to only one trusted external domain
A tenant-wide “On” setting by itself allows a broad class of automatic forwards. If the requirement is one trusted outside domain, design the exception deliberately:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Set the outbound spam policy to an explicit value that permits the approved forwarding scenario; leaving it Off will block the exception before destination controls can help.
- Configure the trusted destination as a specific remote domain with
AutoForwardEnabled $true. - Set the default
*remote-domain behavior to deny automatic forwarding, unless another documented business requirement needs broad forwarding. - Review mail-flow rules for a blocking rule that still catches the trusted domain. Add a narrowly scoped exception only if security policy permits it.
- Test the trusted domain, a different external domain and an internal recipient. The expected result is allow, deny and allow respectively.
The exact interaction between your policy assignments, remote domains and transport rules should be validated in a test mailbox. A broad allow at one layer does not override a deny at another, and an apparently narrow exception can become broad if a wildcard domain or group scope is applied accidentally.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting cases that commonly cause confusion
The user can still see the Inbox rule
Visibility of the rule does not prove delivery is allowed. Microsoft 365 can accept the rule configuration and reject the outbound message during processing. Check the outbound policy and NDR rather than asking the user to recreate the rule repeatedly.
Forwarding worked before
An earlier success does not establish that the current policy is still permissive. The setting may have moved from an explicit value to Automatic – System-controlled, a new policy may now apply to the mailbox, or a remote-domain or mail-flow rule may have changed. Compare the current effective settings and the date of the last administrative change.
Only one outside domain fails
A destination-specific remote-domain setting or a transport-rule condition is more likely than a tenant-wide outbound block. Compare the failing domain with one that succeeds, then inspect the matching remote-domain entry and rule exceptions.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsInternal forwarding also fails
Outbound spam controls do not affect forwarding between internal users. If internal forwarding fails, investigate the Inbox rule itself, mailbox configuration, permissions, or a mail-flow rule that is not limited to external recipients.
Messages reach the outside mailbox but are unsafe
External forwarding does not prevent spam, phishing or high-confidence phishing messages from being forwarded. Microsoft warns that the recipient organization needs its own filtering. Confirm that the receiving organization has appropriate anti-spam and anti-phishing controls before approving the workflow.
Monitoring and governance
After enabling an exception, monitor who is forwarding externally and whether the behavior remains necessary. Microsoft provides an Auto forwarded messages report for cloud accounts that can identify external-forwarding activity.
For on-premises forwarding through Microsoft 365, Microsoft documents a header-based mail-flow rule approach for tracking those messages. Use that telemetry to identify unexpected forwarding, investigate compromised accounts and verify that an approved exception is being used only by its intended users.
Recommended Free Tools
Document the business owner, destination domain, permitted users, data classification, review date and removal procedure for every exception. Recheck the setting after tenant policy changes, mergers, domain changes and mailbox migrations. When the business need ends, turn off the exception and remove the forwarding rule rather than leaving a dormant external route.
Choosing the right policy outcome
| Requirement | Recommended posture | Trade-off |
|---|---|---|
| No business need for external automatic forwarding | Outbound forwarding Off; keep internal forwarding available | External Inbox rules and administrator mailbox forwarding stop working |
| Several departments require external forwarding | Explicitly enable forwarding only for the required policy scope, then review remote domains and transport rules | More data-disclosure exposure and more monitoring work |
| One trusted external domain is required | Use an explicit allow design with a specific remote domain and restrictive default or transport controls | Requires careful testing so a wildcard or broad policy does not expand the exception |
| Temporary migration or incident response | Use a time-bounded exception, document the owner and monitor the Auto forwarded messages report | Operational overhead, but less chance of a forgotten permanent route |
The immediate fix for 5.7.520 is not always to turn forwarding on. The correct result is the one that matches the organization’s data-sharing policy: keep external automatic forwarding blocked when it is unnecessary, or permit it explicitly and constrain the destinations and users when it is justified.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
