How to resolve O365 'External Forwarding is not allowed' error when clients forward to G Workspace?
Published 23 May 2025
Updated 18 Oct 2026
12 min read
Summarize with
Updated on 18 Oct 2026: We clarified Microsoft 365 forwarding defaults, policy priority, and destination restrictions, and added checks for forwards that still fail after approval.
The fix is on the client's Microsoft 365 side. The 550 5.7.520 "Your organization does not allow external forwarding" bounce means Microsoft 365 blocked an automatic external forward before the message reached Google Workspace. It is not caused by your Google Workspace mailbox, and it is not fixed by changing your DMARC record.
Your DMARC p=reject policy can still matter for other forwarding problems. Classic forwarding often causes SPF failures, and some forwarding methods change the message enough to break DKIM. This exact O365 error is a Microsoft 365 outbound policy rejection.
Direct answer
Ask the client's Microsoft 365 admin to allow automatic external forwarding for the affected mailbox. Set the matching outbound policy explicitly to On. For user-configured forwarding, Remote Domains can restrict destinations; verify restrictions separately for admin-configured forwarding. Do not turn off DMARC or remove p=reject, and do not use a destination alias as a policy bypass.
- Owner: The client's Microsoft 365 administrator owns the forwarding policy.
- Control: Outbound anti-spam policy, Remote Domains, and mail flow rules decide whether forwarding works.
- Validation: A new test forward should arrive with headers showing the forwarding path.
What the error means
Microsoft documents this as an automatic external forwarding block. Microsoft's forwarding guidance says outbound spam filter policies can set automatic forwarding to On, Off, or Automatic - System-controlled. Automatic blocks forwarding in newer tenants, but some existing tenants retain its earlier On behavior. Set On - Forwarding is enabled or Off - Forwarding is disabled explicitly instead of relying on Automatic.
Microsoft Defender outbound anti-spam policy with automatic forwarding settings for Microsoft 365.
550 5.7.520 Access denied, Your organization does not allow external forwarding.
Microsoft 365 NDR
That wording confirms the message did not fail because Google Workspace disliked the inbound authentication result. Microsoft 365 detected an automatic forward to an external recipient and returned the message. If the NDR is generated before delivery to Google, Google allowlists, aliases, and routing settings cannot override it.
Microsoft 365 block
- Error: The bounce includes 5.7.520 and AS(7555).
- Timing: The message is stopped before Google Workspace receives it.
- Fix: Change the client's outbound forwarding controls.
DMARC forwarding failure
- Signal: Google Workspace reports an authentication rejection or records dmarc=fail in the received message headers.
- Timing: The message reaches the destination system first.
- Fix: Preserve DKIM, use ARC where supported, or change the forwarding method.
Fix it in Microsoft 365
The clean fix is a targeted Microsoft 365 policy change. The client should avoid a tenant-wide allow unless its security team has approved that risk. External forwarding is a common data loss path, so scope the outbound policy to the specific mailbox or group that needs the workflow. For user-configured forwarding, Remote Domains can restrict destinations to an approved Google Workspace domain.
- Confirm: Get the full NDR, the sender, the forwarding mailbox, and the destination Google Workspace address.
- Identify: Find whether the user configured an inbox rule, mailbox forwarding, or a mail flow rule.
- Allow: In Microsoft Defender, go to Email & collaboration > Policies & rules > Threat policies > Anti-spam. Select Create policy > Outbound, scope it to the approved mailbox or group, and set Automatic forwarding rules to On - Forwarding is enabled. Review and create the policy.
- Restrict: For user-configured forwarding, go to Exchange admin center > Mail flow > Remote domains. Block automatic forwarding on Default and allow it on a specific entry for the domain after @ in the destination address, not google.com.
- Check: Confirm which enabled outbound policy applies, then review other forwarding controls. A lower-priority outbound policy does not override the first matching policy.
- Retest: Send a fresh message from an external sender through the same path and confirm delivery to Google Workspace.
Run the following read-only checks in a connected Exchange Online PowerShell session. Replace user@clientdomain.com with the mailbox doing the forwarding.
PowerShell checks for Microsoft 365POWERSHELL
Get-Mailbox -Identity user@clientdomain.com | Format-List ForwardingAddress,ForwardingSmtpAddress, DeliverToMailboxAndForward Get-InboxRule -Mailbox user@clientdomain.com | Where-Object {$_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo} Get-HostedOutboundSpamFilterPolicy | Format-Table Name,AutoForwardingMode Get-HostedOutboundSpamFilterRule | Sort-Object Priority | Format-Table Name,State,Priority,From,FromMemberOf,SenderDomainIs Get-RemoteDomain | Format-Table Name,DomainName,AutoForwardEnabled
Do not make the fix wider than needed
If the client enables external forwarding for the whole tenant, a compromised mailbox with a forwarding rule can leak mail outside the organization. Keep the outbound allow scoped to the approved mailbox or group. Check existing workflows before changing Default in Remote Domains because that change affects other destinations without a specific entry. Microsoft's remote domain guidance documents exceptions for admin-configured forwarding, so do not rely on AutoForwardEnabled alone to enforce every destination restriction. In an outbound policy, the Domains scope selects internal senders by accepted domain, not the external destination.
If forwarding is still blocked after enabling it
Check the effective policy before changing another setting. Microsoft's policy configuration guidance explains that only the first matching enabled outbound policy applies. Priority 0 is highest; the default policy applies last.
- Confirm scope: Include the forwarding mailbox, not the Google Workspace recipient. Users and Groups conditions use AND logic, so specifying both can unintentionally exclude a mailbox.
- Confirm the destination: Setting Automatic forwarding rules to On permits forwarding; it does not create an Inbox rule or configure a mailbox forwarding address.
- Check missing bounces: For Inbox-rule forwards of messages sent by internal users, the outbound policy can block forwarding without generating an NDR. Retest with an external sender.
- Check separate controls: Remote Domains and mail flow rules that apply to the forwarding method can still block the copy, even when the effective outbound policy permits it.
A disabled Save button or a permission error while configuring forwarding is a configuration problem, not a 5.7.520 delivery failure. Have the admin verify the destination and their permissions before testing mail flow.
Where Google Workspace and DMARC fit
Google Workspace receives what Microsoft 365 sends to it. If Microsoft 365 blocks the automatic forward, Google Workspace never sees the message. Adding the client's address as a Google forwarding address, creating an alias, or changing your SPF record will not resolve this exact NDR.
The confusion often starts because DMARC and forwarding really do interact. Use Suped's domain health check to confirm your own SPF, DKIM, and DMARC state, but keep that separate from the Microsoft 365 forwarding block.
DMARC policy exampleDNS
_dmarc.yourdomain.com. TXT v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Exchange Online uses Sender Rewriting Scheme (SRS) for applicable automatic forwards. SRS rewrites the envelope MAIL FROM address but leaves the visible From address unchanged. An SPF pass after SRS rewriting is not enough for DMARC; the authenticated domain must also satisfy DMARC domain matching with the visible From domain. A valid DKIM signature that satisfies DMARC domain matching can keep DMARC passing after forwarding. Authenticated Received Chain (ARC) carries earlier authentication results. A receiver that trusts the ARC chain can use them to accept a message despite a DMARC failure; ARC does not turn that failure into a DMARC pass.
- Original From: If the forwarded message uses your domain in the visible From header, your p=reject policy can matter at the receiver.
- SPF path: Classic forwarding often breaks SPF because the forwarding server is not in the original domain's SPF record. Microsoft 365 SRS can improve SPF for applicable forwards, but an SPF pass for the rewritten address does not by itself establish DMARC domain matching with the original visible From domain.
- DKIM survival: A DKIM signature can survive when the signed content remains unchanged. DMARC requires the signing domain to share the visible From domain's organizational domain under relaxed matching, or match it exactly under strict matching. Use Suped's DKIM checker to inspect the published key; the received message's headers show whether its DKIM signature passed verification.
- Reporting: Use Suped's DMARC monitoring to review receiver reports for domains you monitor. These contain aggregate authentication data, not per-message delivery logs for your Google Workspace inbox. Google cannot report on a forwarded copy that Microsoft 365 never sent to it.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A separate inbound domain without DMARC does not bypass this policy. The destination domain's DMARC policy does not govern messages using another domain in the visible From header. If the client cannot enable external forwarding, ask for direct delivery or an approved shared mailbox workflow instead.
How to test the forwarding path
Test forwarding as a routing problem first and an authentication problem second. Send one clean message, trigger the client's forward, and preserve the NDR or final headers. For an authentication comparison, send a direct copy to Suped's email tester and compare it with the headers of the copy delivered through the actual Microsoft 365 to Google Workspace path. A direct tester result does not validate that forwarding path.
The result should tell you which system made the decision. This Microsoft 365 forwarding NDR points back to the client's policy. Authentication failures in the delivered copy require comparison with the original message to distinguish sender problems from forwarding changes. A message that passes authentication but lands in spam needs a separate review of filtering and reputation. The client admin can also use the Microsoft 365 Auto forwarded messages report to identify cloud mailboxes that are forwarding externally and verify activity after the change.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
- Prepare: Use one external sender, one client mailbox, and one Google Workspace destination.
- Send: Create a new message instead of reusing an old forwarded thread.
- Forward: Let the same rule or mailbox forwarding setting handle the message.
- Read: If you get 5.7.520, send that NDR to the client's Microsoft 365 admin.
- Inspect: If the message arrives, review the receiving system's Authentication-Results, Received, and ARC headers. Compare header.from with smtp.mailfrom and the DKIM header.d domain.
If the copy is missing, use Exchange admin center > Mail flow > Message trace. Search the test time window and Google Workspace destination, then inspect the forwarded copy's events. Microsoft's message trace guidance explains how to distinguish rejected, deferred, and delivered messages. Delivery to the client mailbox alone does not prove the external forward succeeded.
Routing diagnosis signals
Use the strongest visible signal first, then move down the stack.
Microsoft 365 NDR
5.7.520
The client admin must change forwarding controls.
Delivered with auth fail
Header check
Review SPF, DKIM, DMARC, and forwarding changes.
Delivered and authenticated
Inbox test
Investigate spam placement, reputation, or user filtering.
If the test points to authentication after delivery, use the DKIM and SPF failures workflow to separate DNS mistakes from forwarding side effects.
Safer workarounds
If the client cannot allow external forwarding, ask for direct delivery or an approved shared workflow. A destination alias does not change Microsoft's forwarding policy.
Better options
- Direct send: Ask the client to send messages directly to your Google Workspace address.
- Scoped allow: Allow forwarding only for the approved mailbox and, when needed, the approved destination domain.
- Shared process: Use a shared mailbox, group, or ticketing address that both sides accept.
Avoid these fixes
- Relax DMARC: Changing p=reject does not remove a Microsoft 365 forwarding block.
- Alias-only workaround: Changing the recipient address does not authorize external forwarding.
- Tenant-wide allow: Broad forwarding access increases data loss risk for every mailbox.
|
|
|
|---|---|---|
Allow user | M365 admin | Permits forwarding in the matching outbound policy; other controls still apply. |
Allow destination | M365 admin | Controls destinations for user-configured forwarding. |
Direct send | Client | No forward |
Alias only | You | Doesn't fix |
Use the narrowest change that solves the workflow.
A domain alias can still be useful for mailbox organization, but it is not a policy bypass. If Microsoft 365 is configured to block automatic external forwarding, the forward fails before the destination address has a chance to accept or reject it.
How Suped fits
Suped is our DMARC and email authentication platform. Suped can check your sending domain's published authentication settings and collect receiver reports for domains you monitor. The Microsoft 365 forwarding policy bounce still requires investigation in the client's tenant.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
After the client changes its Microsoft 365 policy, use Suped to watch authentication results for your monitored domains. Use message trace and the received copy's headers to confirm the individual forward.
- Baseline: Confirm the published SPF, DKIM, and DMARC records before changing the forwarding workflow.
- Reports: Review available aggregate results for your monitored domains and compare them with the received copy's headers.
- Alerts: Watch for authentication failure spikes after the policy or routing change.
Views from the trenches
Best practices
Treat 5.7.520 as a Microsoft 365 forwarding policy block before changing Google settings.
Ask the client's admin for outbound spam policy and remote domain screenshots early.
Test with one mailbox and one recipient before enabling broader external forwarding access.
Common pitfalls
Do not weaken DMARC p=reject to solve an automatic forwarding policy rejection in Microsoft 365.
Do not assume Google Workspace rejected the message when its NDR came from Microsoft 365.
Do not allow tenant-wide forwarding when only one client workflow needs approved access.
Expert tips
Compare the original From domain with your domain before blaming your DMARC setting.
Preserve one full NDR and one successful header sample for the client's admin review.
Check mailbox rules, mailbox forwarding, remote domains, and outbound spam policy together.
Marketer view
Marketer from Email Geeks says the 5.7.520 bounce is generated inside Office 365 when automatic external forwarding is disabled, so the recipient's DMARC record is not the first place to look.
2020-12-01 - Email Geeks
Marketer view
Marketer from Email Geeks says if the rejected message is not From the recipient's own domain, the recipient domain configuration is unlikely to be the cause.
2020-12-01 - Email Geeks
