How to resolve O365 'External Forwarding is not allowed' error when clients forward to G Workspace?
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 May 2025
Updated 4 Jun 2026
7 min read
Summarize with
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 breaks SPF domain matching, and some forwarding methods change the message enough to break DKIM. But this exact O365 error is a Microsoft 365 outbound policy rejection, not a Google Workspace authentication rejection.
Direct answer
Ask the client's Microsoft 365 admin to allow automatic external forwarding for the affected mailbox or for your receiving domain. Keep the change narrow. Do not turn off DMARC, do not remove p=reject, and do not rely on a non-authenticated alias as the primary fix.
- 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. The important detail is that Automatic now behaves like Off for all customers, so many tenants block forwarding unless an admin has explicitly allowed it.
Microsoft Defender portal outbound anti-spam policy with automatic forwarding settings.
550 5.7.520 Access denied, Your organization does not allow external forwarding.
Microsoft 365 NDR
That wording tells me 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
- Error: The receiver accepts the connection, then evaluates SPF, DKIM, and DMARC.
- 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. I would ask the client to avoid a tenant-wide allow unless their security team has approved that risk. External forwarding is a common data loss path, so the safer pattern is to allow only the specific mailbox, group, or destination domain that needs the workflow.
- 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 transport rule.
- Allow: Create a scoped outbound anti-spam policy with automatic forwarding set to On for the approved mailbox.
- Check: Review remote domains and mail flow rules, because a block in either place wins over a broader allow.
- Retest: Send a fresh message through the same path and confirm the NDR no longer appears.
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
Do not make the fix wider than needed
If the client enables external forwarding for the whole tenant, any compromised mailbox with a forwarding rule can leak mail outside the organization. A custom policy for a named user or a known destination domain usually solves the business problem with less risk.
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 a 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; adkim=s; aspf=s
- 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: SPF often fails on classic forwarding because the forwarding server is not in the original domain's SPF record.
- DKIM survival: DKIM passes only when the signed content remains unchanged and the DKIM record lines up with the visible From domain.
- Reporting: Aggregate reports help with DMARC monitoring, but they do not show a message that Microsoft 365 rejected before delivery.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A separate inbound domain without DMARC is not a good fix for this problem. It avoids the wrong control, and it creates a weaker identity path for messages that still depend on a Microsoft 365 admin decision. If the client cannot enable external forwarding, ask for direct sends, a shared mailbox workflow, or an approved group address instead.
How to test the forwarding path
I like to 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. If you need a fast end-to-end check, send a message to an email tester and compare the results with the forwarded copy.
The result should tell you which system made the decision. A Microsoft 365 NDR points back to the client's policy. A delivered message with failed SPF or DKIM points to forwarding authentication behavior. A delivered message that lands in spam points to filtering and reputation signals after receipt.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
- Prepare: Use one 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 Authentication-Results and Received headers.
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, change the workflow instead of weakening authentication. The goal is to make the message originate or route through an approved path, not to hide the problem behind a domain alias.
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 or 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.
- Unprotected alias: A separate weak domain creates a new mail identity problem.
- Tenant-wide allow: Broad forwarding access increases data loss risk for every mailbox.
|
|
|
|---|---|---|
Allow user | M365 admin | Forward works |
Allow domain | M365 admin | Narrow rule |
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, and it is the best overall DMARC platform for most teams handling this kind of issue because it separates policy bounces from authentication failures. In practice, that means you can see whether the problem is your domain's SPF, DKIM, or DMARC setup, or whether the sender's Microsoft 365 tenant stopped the message before delivery.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a forwarding problem, Suped's product helps confirm the domain baseline first, then watch for real authentication failures after the client changes its Microsoft 365 policy. That avoids weakening DMARC because of a bounce that DMARC did not cause.
- Issue detection: Suped flags SPF, DKIM, DMARC, and forwarding-related authentication problems with steps to fix.
- Alerts: Real-time alerts show when failures spike after a policy or routing change.
- Hosted controls: Hosted DMARC, Hosted SPF, SPF Flattening, and Hosted MTA-STS reduce DNS maintenance.
- Reputation view: Blocklist (blacklist) monitoring adds reputation context when mail is delivered but filtered.
- Scale: The MSP and multi-tenancy dashboard keeps multiple client domains in one clean view.
Views from the trenches
Best practices
Treat 5.7.520 as a Microsoft 365 policy block before changing Google settings first.
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 a Microsoft forwarding policy rejection NDR.
Do not assume Google Workspace rejected mail when the 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 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 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
The clean fix
Resolve this by changing the client's Microsoft 365 forwarding policy or by changing the workflow so forwarding is no longer required. Keep your DMARC enforcement in place. A receiving-side Google Workspace change cannot allow a message that Microsoft 365 refuses to send.
- Best fix: The client's admin enables automatic external forwarding for the approved mailbox or domain.
- Best fallback: The client sends directly to your Google Workspace address or uses an approved shared process.
- Wrong fix: Relaxing DMARC or using a weak alias to work around the wrong control.
