Summary
The error message '550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance' indicates that the issue primarily stems from the sending organization's Office 365 (O365) security policies, rather than the recipient's G Workspace DMARC configuration. This O365 error means that the sender's Microsoft 365 environment is preventing emails from being automatically forwarded to external domains, a common default security measure to prevent spam and data exfiltration. While a DMARC policy set to 'reject' on the receiving G Workspace domain can lead to delivery issues for forwarded emails if authentication breaks, the initial bounce points directly to an O365 outbound policy restriction.
Key findings
- O365 internal rejection: The '550 5.7.520' error is an internal O365 rejection, meaning the email isn't even leaving the Microsoft 365 environment to be subjected to the recipient's DMARC policy.
- Security setting: This specific error is typically due to a security setting in the client's O365 instance that restricts automatic external forwarding, often part of an anti-spam outbound policy.
- DMARC interaction: While a DMARC 'p=reject' policy on the receiving domain (G Workspace) can cause issues with forwarded mail due to authentication failures, it's not the root cause of this O365-specific rejection. However, once O365 forwarding is enabled, DMARC alignment issues for forwarded mail may still arise.
- Administrator action required: Resolving this error requires the O365 administrator to modify their organization's outbound anti-spam policy to allow external forwarding. More details on this can be found on Office365Concepts.com.
Key considerations
- Client-side configuration: The primary solution lies with the O365 client's IT administrator adjusting their outbound anti-spam policy. This policy can be found in the Microsoft 365 Defender portal.
- Custom policy recommendation: It is often recommended to create a new custom outbound policy to allow automatic forwarding for specific users or domains rather than modifying the default policy. This approach helps maintain broader security settings while providing necessary exceptions.
- DMARC alignment after forwarding: Even after enabling forwarding, emails might still fail DMARC checks on the receiving end if the forwarding process breaks SPF or DKIM alignment. For more on this, review how stricter DMARC policies impact forwarded emails.
- Alternative forwarding methods: If direct forwarding cannot be enabled, clients might consider sending forwarded emails to a domain alias that does not have a DMARC reject policy, or exploring other methods that preserve authentication. Troubleshooting Office 365 DKIM and SPF failures can be a related step.
What email marketers say
Email marketers often encounter the 'external forwarding not allowed' error when setting up email flows involving different email providers. Their initial reactions might lean towards issues with DMARC or other authentication protocols on the receiving end. However, through discussion and troubleshooting, they often realize the core problem lies with the sender's O365 configuration. This highlights a common challenge in email deliverability: pinpointing the exact cause of a bounce when multiple authentication and security layers are at play.
Key opinions
- Initial DMARC suspicion: Many marketers first suspect their own domain's DMARC policy, especially if set to 'reject', as the cause of bounce backs when emails are forwarded. This is a common misconception.
- Focus on recipient domain: There's often an initial focus on how the recipient domain (e.g., G Workspace) is configured, including its DMARC, SPF, or DKIM settings, rather than the sending environment's outbound rules.
- Forwarding breaking authentication: Marketers are aware that email forwarding can often break authentication signatures like DKIM, leading to DMARC failures and subsequent rejections or spam filtering. This can be complex when mailbox providers forward emails to a single Gmail account.
- Seeking administrator involvement: Recognizing that the error points to the client's O365 configuration, marketers understand the need to involve the client's IT or O365 administrator for resolution.
Key considerations
- Communicating the issue: Clearly communicating to the client that the 'external forwarding not allowed' error is an O365 security policy issue, not a problem with the receiving domain's DMARC, is crucial for efficient troubleshooting.
- Providing context: Marketers should be prepared to explain that this is a common security feature in O365 to prevent unauthorized forwarding and ensure their clients understand the administrative steps required.
- Exploring alternatives: If O365 forwarding is not feasible due to strict client policies, marketers may consider suggesting alternative methods for receiving emails, such as direct sending to a different email address or using a CRM integration.
- Impact on deliverability: Even after O365 forwarding is enabled, marketers should monitor deliverability for emails that have been forwarded, as DMARC failures or low Gmail domain reputation could still impact inbox placement. Tools can help diagnose specific deliverability issues from Microsoft.
Marketer view
Marketer from Email Geeks initially believed the problem was related to their DMARC 'p=reject' policy. They thought this policy was preventing the forwarded emails from being verified, leading to the bounce. This perspective is common when first implementing DMARC, as its impact on forwarded mail can be confusing.
Marketer view
Marketer from Spiceworks Community notes that changing the new policy's priority to 0 or something with a higher priority than the default policy might be necessary. This suggests that even with a custom policy, its order of application can affect its effectiveness in allowing external forwarding.
What the experts say
Email experts consistently emphasize that the 'external forwarding not allowed' error originates from Microsoft 365's internal security configurations, not the DMARC policy of the recipient domain. They highlight that O365's anti-spam outbound policies are designed to prevent automatic external forwarding by default. Experts also note the potential for forwarded emails to break authentication headers (like DKIM) which can lead to DMARC failures, but reiterate that the initial O365 bounce is distinct from such downstream issues.
Key opinions
- O365 internal rejection: Experts confirm that the '550 5.7.520' error is specifically from O365, indicating an internal rejection before the email even attempts to reach the external domain.
- Security policy cause: The error is primarily a result of the O365 instance's security settings, specifically its configuration regarding automatic external forwarding, which is often disabled by default for security reasons.
- DMARC vs. O365 policy: While DMARC can cause problems with forwarded emails, it's generally not the direct cause of this specific O365 'external forwarding not allowed' error. The O365 policy blocks the forwarding itself.
- DKIM breaking on forwarding: Experts acknowledge that Outlook (and other systems) can have issues with certain types of forwarding that break DKIM signatures, which would then lead to DMARC failures on the receiving end if forwarding is allowed. This is a separate, subsequent issue to the initial O365 rejection.
- Previous M365 client history: An interesting point raised is that if the sending organization was previously an M365 client and email hosting is still active, it could contribute to this issue on multiple M365 domains.
Key considerations
- Client administrator action: The recommended course of action is for the client to contact their O365 administrator to review and adjust their anti-spam outbound policies. Information on how to fix this error is widely available.
- Diagnosing specific messages: While the O365 policy is the likely culprit, further diagnosis with exact message details and headers can help rule out any subtle issues where O365 might be flagging the message as spam for other reasons.
- DMARC and forwarding nuances: Even after O365 forwarding is permitted, organizations must understand that DMARC policies, especially 'p=reject', can still cause issues for forwarded mail. Reviewing common DMARC issues in Microsoft 365 and Google Workspace is important.
- Domain configuration review: If the rejected mail's 'From' address does not match the recipient's domain, then the problem is almost certainly unrelated to the recipient's domain configuration. However, ensuring proper DMARC, SPF, and DKIM setup is always a best practice.
Expert view
Expert UDEFP1J3B from Email Geeks states that the error message clearly indicates that O365 is configured not to allow automatic external forwarding. This is a direct interpretation of the error code, pinpointing the exact policy causing the bounce.
Expert view
Expert from SpamResource.com advises checking the anti-spam outbound policy in Microsoft 365 Defender to resolve forwarding issues. This is a fundamental step for anyone managing O365 email security settings.
What the documentation says
Microsoft 365 documentation confirms that the '550 5.7.520' error is related to an organization's outbound anti-spam policy. By default, automatic external forwarding is often disabled for security purposes to prevent unauthorized data exfiltration or spam propagation. The documentation outlines the necessary steps within the Microsoft 365 Defender portal to modify these policies, either by creating exceptions for specific users or by globally enabling forwarding with caution. Google Workspace documentation, on the other hand, focuses on how to configure G Workspace for receiving mail, including considerations for DMARC and how it interacts with forwarded messages, often recommending methods that preserve authentication or advising on specific routing for domains with strict DMARC policies.
Key findings
- Default O365 security: Microsoft 365 (O365) by default restricts automatic external forwarding as part of its outbound spam protection to mitigate security risks such as unauthorized data forwarding and spam campaigns.
- Policy location: The settings to control external forwarding are located within the Microsoft 365 Defender portal, under Anti-spam outbound policy.
- Specific error code: The error '550 5.7.520 Access denied, Your organization does not allow external forwarding' explicitly indicates this policy restriction.
- Google Workspace forwarding: Google Workspace documentation outlines how to configure email routing and aliases, but these settings primarily govern how G Workspace receives mail, not how O365 sends or forwards it externally. For example, SMTP relaying through Google Workspace may have specific port requirements.
Key considerations
- Modifying outbound policies: Administrators can enable external forwarding by editing the protection settings in the anti-spam outbound policy, typically by changing 'Automatic forwarding' to 'On - Forwarding is enabled'.
- Creating custom policies: Microsoft documentation often recommends creating a new, custom outbound policy with a higher priority (e.g., 0) instead of modifying the default one. This allows for granular control over who can forward emails externally.
- Security implications: Enabling external forwarding should be done with caution, as it can increase the risk of internal accounts being compromised and used to send spam or exfiltrate data. Microsoft advises understanding these risks before making changes.
- DMARC and forwarded mail: While O365 allows forwarding, it's crucial for the recipient's G Workspace domain to be prepared for DMARC authentication challenges, as forwarded emails may fail SPF or DKIM alignment. For general information on configuring Microsoft 365 for inbound and outbound mail, refer to official documentation, such as on Barracuda Campus.
Technical article
Documentation from Office365Concepts.com states that the 550 5.7.520 error typically indicates that the organization's anti-spam outbound policy does not allow external forwarding. This resource provides a clear diagnosis of the Non-Delivery Report (NDR).
Technical article
Documentation from MSDigest.net recommends that the best practice for allowing automatic forwarding is to create a new custom outbound policy rather than updating the default policy. This ensures more controlled management of forwarding exceptions.
Related resources
15 resources
Related pages
Will a stricter DMARC policy impact internal email deliverability when using G Suite aliases and email forwarding?
Troubleshooting Office 365 DKIM and SPF email authentication failures
How to resolve email blocking issues with Microsoft domains?
Why do mailbox providers forward emails to a single Gmail account, causing DMARC failures?
How to fix common DMARC issues in Microsoft 365 and Google Workspace
Why Your Emails Fail: Expert Guide to Improve Email Deliverability [2025]
A simple guide to DMARC, SPF, and DKIM
Why your emails fail at Microsoft: the hidden SPF DNS timeout
