What does the 'External Forwarding is not allowed' error specifically mean?

The error "550 5.7.520 Access denied, Your organization does not allow external forwarding" indicates that the Microsoft 365 organization's internal anti-spam outbound policy is blocking the email from being forwarded to an external address. This is a security feature within O365 itself.

Is this error related to my domain's DMARC policy on Google Workspace?

No, this specific error is usually an internal policy block within the Microsoft 365 environment of the sender. It means the email is being stopped before it even attempts to leave O365. DMARC issues would typically occur on the receiving server's end after the email has been forwarded.

How can the O365 client resolve this external forwarding error?

The O365 administrator needs to modify their Microsoft 365 outbound anti-spam policy. They should navigate to the Microsoft 365 Defender portal, go to Anti-spam settings, and adjust the 'Automatic forwarding rules' to 'On - Forwarding is enabled', ideally by creating a custom policy for specific users or groups.

Are there any workarounds if the O365 client cannot change their forwarding settings?

If changing O365 policies isn't feasible, you could ask your clients to forward emails to a domain alias on your Google Workspace that doesn't have a strict DMARC policy. This would allow the emails to be received, but it's a workaround that sacrifices some security benefits.

How to resolve O365 'External Forwarding is not allowed' error when clients forward to G Workspace? - Troubleshooting - Email deliverability - Knowledge base

Q: Should the O365 administrator modify the default policy or create a new one?

While it's possible to change the default policy, it's recommended to create a custom outbound anti-spam policy. This allows the administrator to apply specific forwarding rules to only those users or groups who require external forwarding, maintaining a higher level of security for the rest of the organization.

Dealing with email forwarding issues can be a significant headache, especially when different email providers are involved. A common scenario I encounter involves Microsoft 365 (O365) users attempting to forward emails to Google Workspace (G Workspace) accounts, only to be met with a frustrating bounce-back error: "Remote Server returned '550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555)'."

My initial thought when seeing this type of error often leans towards Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies, particularly when a domain has a p=reject policy in place. It's a reasonable assumption, as forwarding can indeed break the authentication checks like Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) alignment, leading to rejections. However, for this specific error message originating from O365, the root cause is typically different.

This bounce message explicitly states that the sending organization (the O365 client) does not allow external forwarding. This points to an internal security setting within the Microsoft 365 environment itself, rather than a DMARC policy on the receiving Google Workspace domain. Understanding this distinction is the first critical step towards a resolution.

Understanding the error message

The error message, "550 5.7.520 Access denied, Your organization does not allow external forwarding," is a clear indicator that the issue lies with the O365 sender’s configuration. This isn't a rejection from the recipient's Google Workspace, but rather an internal block by Microsoft 365 before the email even attempts to leave its environment to be forwarded.

Microsoft 365 implements robust security measures to protect its users and prevent abuse. By default, automatic external forwarding is often restricted to mitigate risks such as compromised accounts being used to funnel spam, phishing emails, or sensitive data outside the organization. This policy acts as a crucial barrier against unauthorized data exfiltration.

While this security feature is beneficial, it can inadvertently disrupt legitimate workflows for users who need to forward emails to external addresses. When this error occurs, it means the email never actually reached the point where it would be evaluated by your Google Workspace's DMARC policy. The problem is squarely on the O365 side.

Security by default

Microsoft 365 has a default anti-spam outbound policy that often blocks automatic external forwarding. This is a security feature designed to prevent bad actors from compromising email accounts and setting up forwarding rules to exfiltrate data or send spam through your organization’s infrastructure. Your client's administrator will need to adjust this policy to allow forwarding.

Adjusting Microsoft 365 outbound spam policies

To resolve the "External Forwarding is not allowed" error, the O365 client's administrator needs to modify their Microsoft 365 outbound spam filter policy. This is typically done within the

Microsoft 365 Defender portal or the Exchange Admin Center (EAC).

The general steps involve navigating to the Anti-spam settings, locating the outbound policy, and editing the 'Automatic forwarding rules'. There are usually options to turn forwarding on, off, or set it to automatic (which defaults to blocking in many cases).

Navigating to automatic forwarding settings

1. Go to the Microsoft 365 Defender portal at security.microsoft.com.
2. In the left navigation, go to Email & collaboration > Policies & rules > Threat policies > Anti-spam.
3. On the Anti-spam policies page, select Anti-spam outbound policy (Default).
4. Click Edit protection settings.
5. Under Automatic forwarding rules, select On - Forwarding is enabled.
6. Save your changes.

While changing the default policy can resolve the issue quickly, the recommended approach for better security and control is to create a new custom outbound policy. This allows the administrator to apply specific forwarding rules to individual users or groups who require it, without exposing the entire organization to unnecessary risks. Remember to save all changes after modification to ensure they take effect.

Option	Description	Impact
On - Forwarding is enabled	Allows all automatic external email forwarding from the organization.	Highest risk, least secure for general use.
Off - Forwarding is disabled	Blocks all automatic external email forwarding.	Most secure, but can disrupt legitimate workflows.
Automatic - System controlled	Allows or blocks forwarding based on Microsoft 365’s internal spam detection. Often blocks perceived risky forwarding.	Default setting, moderate security, prone to blocking legitimate traffic.

DMARC and forwarding nuances

It’s important to clarify the distinction between the O365 external forwarding error and general DMARC issues. My initial thought about DMARC was valid in a different context. When an email is forwarded, especially from a system not configured to preserve authentication headers, the original SPF and DKIM signatures can be invalidated. This break in email authentication can lead to DMARC failures on the receiving server, particularly if the DMARC policy is set to p=reject. This is a common challenge, and you can learn more about handling DMARC failures with forwarded emails.

However, the "External Forwarding is not allowed" error is distinct. It occurs before the email leaves the Microsoft 365 environment. The O365 server itself is refusing to send the email to the external forwarding address (your Google Workspace) due to its internal security settings, not because your DMARC policy is rejecting an unauthenticated email. This means the problem isn't about how your domain handles incoming forwarded mail, but how the O365 domain is allowed to send it.

O365 internal forwarding error

This error signifies that the Microsoft 365 organization's internal policies are blocking the forwarding. The email is not leaving the O365 environment, meaning it's not subject to your domain's DMARC policy yet. The fix requires an administrator to change outbound anti-spam settings within O365.

DMARC forwarding issues

When an email is forwarded, the original SPF and DKIM authentication can break. If your domain has a strong DMARC policy (e.g., p=reject), the receiving server might reject the email due to failed authentication. This happens after the email has left the sender's environment and is being processed by the recipient's mail system. You can learn more about redundant email forwarding problems.

Best practices and alternative solutions

To maintain optimal security while allowing necessary external forwarding, the O365 administrator should consider creating a custom outbound anti-spam policy. This approach allows granular control, enabling forwarding only for specific users or groups who require it, rather than broadly opening up forwarding for the entire organization through the default policy.

For situations where strict DMARC policies on the recipient's side are an issue, one alternative is to ask the O365 client to forward emails to a domain alias that isn’t subject to such stringent DMARC verification. This can be a workaround for critical communications that must be forwarded, though it bypasses some security benefits.

Also, it's crucial to understand that even if forwarding is enabled, excessive or improper forwarding can negatively impact sender reputation, potentially leading to emails being flagged as spam or even getting your domain added to a blocklist (or blacklist). This is why regular monitoring of your domain's reputation and email deliverability is a continuous effort.

Monitoring email deliverability

Beyond addressing specific errors, maintaining strong email deliverability requires ongoing vigilance. Regularly check your blocklist (blacklist) status and DMARC reports. This proactive approach helps identify and fix issues before they escalate into widespread delivery problems, such as emails going to quarantine or being rejected entirely by recipient mailboxes.

Ensuring smooth email communication

Successfully navigating email deliverability requires a clear understanding of the nuances involved, especially when different platforms like Microsoft 365 and Google Workspace interact. The error "External Forwarding is not allowed" from O365 is a prime example of an internal security measure, separate from typical DMARC authentication failures that might occur once an email is actually forwarded.

The resolution lies in the O365 administrator adjusting their outbound anti-spam policies to explicitly allow external forwarding, preferably through a custom policy for targeted control. This ensures that legitimate email flows are not interrupted while maintaining a strong security posture against unauthorized activities, such as those that might lead to your domain being put on an email blocklist (or blacklist).

By understanding the precise origin of such errors and implementing targeted solutions, you can ensure smoother email communication between different platforms and maintain robust deliverability for your organization. Proactive monitoring of your email health remains key to long-term success.

Views from the trenches

Best practices

Always recommend that clients contact their Microsoft 365 administrator to review and adjust their outbound anti-spam policies for external forwarding.

Encourage O365 administrators to create custom outbound policies for specific users or groups requiring external forwarding, rather than modifying the default global policy.

Educate clients on the security reasons behind O365’s default external forwarding restrictions to help them understand the importance of careful policy management.

Common pitfalls

Misdiagnosing the O365 'External Forwarding is not allowed' error as a DMARC failure on the recipient's side, leading to incorrect troubleshooting steps.

Making broad, organizational-wide changes to external forwarding policies in Microsoft 365, which can increase security risks.

Failing to inform clients about the need to adjust their O365 settings, causing ongoing communication issues and frustration.

Expert tips

For specific forwarding needs, consider setting up a mail flow rule in Exchange Online that redirects mail rather than using a simple forwarding rule.

If DMARC is causing issues for legitimately forwarded mail, consider a DMARC policy of p=quarantine for a period to gather data before moving to p=reject.

Regularly review mail flow logs within both O365 and Google Workspace to identify the precise point of failure for email delivery issues.

Expert view

Expert from Email Geeks says that the '550 5.7.520 Access denied' error message indicates that O365 is configured to prevent automatic external forwarding.

2020-12-01 - Email Geeks

Expert view

Expert from Email Geeks states that the error is likely a security setting on the client's O365 instance, not related to the recipient's domain configuration.

2020-12-01 - Email Geeks