550 5.7.520 Access denied, Your organization does not allow external forwarding
Last updated 2026-09-02
Microsoft 365 refused an automatic forward, and it named the policy in the bounce. The
line reads 550 5.7.520 Access denied, Your organization does not allow external
forwarding. Exchange Online is not judging your SPF, DKIM or DMARC records. A
tenant outbound spam policy blocked a mailbox or Inbox rule that was sending a copy
outside the organisation. The admin who runs that tenant owns the fix. The last section
of this page is the message to send them.
What it means. Microsoft's Defender article for this code gives one cause: automatic external forwarding hit an outbound spam filter policy that blocks it. The documented bounce is 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555).
What to change. Read the words after 5.7.520. The forwarding sentence is a policy on the tenant that tried to send the copy out. Only an admin there can allow the forward or remove the rule. A second live string, Message blocked because it contains content identified as spam, is a content filter. Microsoft's public NDR table has no row for either string.
When it clears. The next automatic forward goes through once that tenant allows it, or once the Inbox rule or mailbox forwarding is removed. Until then Exchange Online returns the same 5.7.520. Your mail server will not retry a 5xx on its own.
550 5.7.520 in the bounce, and the AS suffix
Microsoft's Defender article for this code, updated 2026-08-18, prints the bounce under the heading Blocked email forwarding messages.
A live NDR usually prefixes 550.
That is the string Microsoft documents, character for character, including the capital Y
after the comma. The
Exchange Online NDR table has no row for 5.7.520. The Defender article
is the page that names the cause. The AS(7555) suffix is Microsoft's
internal tag on that NDR. Read the words beside it.
Outlook wraps the whole report under
Your message couldn't be
delivered. The generating host sits under prod.outlook.com. That names
the service that refused the forward. It does not name your DNS.
Outbound spam policy blocked the forward
Microsoft lists two ways a copy leaves the tenant on its own. A user writes an Inbox rule that forwards to an address outside the organisation. An admin sets mailbox forwarding, also called SMTP forwarding, on the mailbox itself. Both trip the same outbound check.
Microsoft's article says the check lives in outbound spam filter policies. Three values sit on the Automatic forwarding rules dropdown.
- Automatic - System-controlled. The default label. Microsoft says this value used to match On, and that in 2021 it started matching Off for new organisations and for tenants that were not already using it. Existing tenants that already used it can still match On. Microsoft's own instruction is to pick On or Off instead, because Automatic does not mean the same thing in every tenant.
- On - Forwarding is enabled. Automatic external forwarding is allowed.
- Off - Forwarding is disabled. Automatic external forwarding is disabled, and the sender of the original message gets an NDR.
Microsoft's wording for that NDR is the sentence quoted above. Internal forwards stay up. On-premises mailboxes that forward through Microsoft 365 sit under the same policy. Compromised mailboxes are why the Off setting exists: Microsoft says attackers use automatic forwarding to send internal mail outside the tenant.
Two other controls can also stop a forward: a remote domain with automatic forwarding
turned off, and a mail flow rule that matches forwarded mail. Microsoft's table on that
page says the block typically wins when one control allows the forward and another
refuses it. The exception is the Automatic - System-controlled row:
Microsoft says the result then depends on how that setting works in the organisation.
The Defender article prints 5.7.520 for the outbound spam policy, not for a
remote domain or a mail flow rule. The documented AS(7555) string is the
outbound spam policy.
Your organization is the forwarding tenant
The bounce says Your organization. That phrase names the tenant whose
mailbox tried to send the copy out, not the person who wrote the original message.
Exchange Online generates the NDR and sends it to the original sender. From outside, the
wording reads as if your own company blocked you. It did not.
You write to bob@contoso.com. Bob's mailbox, or an Inbox rule on it,
forwards to an address at another domain. Contoso's outbound policy refuses that second
hop. You receive 5.7.520. Bob may already have the original in his inbox. Microsoft's
configure page states when that NDR is generated: messages from external senders, for
every forwarding method. Messages from internal senders get an NDR only when the method
is mailbox forwarding. An Inbox rule that forwards an internal message does not produce
one.
A receiving tenant's mail flow rule that rejects on attachment type is a different
bounce. Exchange prints
550 5.7.1 TRANSPORT.RULES.RejectMessage; the message was rejected by organization
policy, or a custom 5.7.900 through 5.7.999 the admin
chose.
554 5.7.1 covers that family.
550 5.4.1 Recipient address rejected: Access denied
is Directory-Based Edge Blocking, a missing recipient, not a forward.
Senders own a short checklist
- The words after 5.7.520. Save the full sentence from the NDR. The forwarding sentence and the content-identified-as-spam sentence share the digits and none of the work.
- Whether the mailbox forwards. Ask the person, by phone or through a colleague, whether mail to that address is forwarded off the tenant. The bounce often lands with you while the original sits in their inbox.
- One recipient or many. One Microsoft 365 domain bouncing, and every other domain going through, points at that tenant's outbound policy. Every Microsoft 365 address bouncing with the content-identified-as-spam sentence points at what you sent, or at the Microsoft account you sent from.
- Stop resending the original. A status code that starts with 5 is permanent. 550 permanent failure covers what that first digit commits your own server to. The same forward, or the same attachment, draws the same refusal.
After those four, the remaining work sits inside the tenant that tried to send the copy out. Publishing a record on your domain does not move it.
Forwarding admins: the controls that clear it
If you run mail for the tenant in the bounce, you are the one who can end this. The people writing to that mailbox have not seen your outbound policy. Microsoft's outbound spam policy page is the click path.
- Read the current value. In the Microsoft Defender portal, open Email & collaboration > Policies & rules > Threat policies > Anti-spam. Or go directly to security.microsoft.com/antispam. Open Anti-spam outbound policy (Default). The dropdown is Automatic forwarding rules.
- Pick On or Off, not Automatic. Microsoft says Automatic - System-controlled does not mean the same thing in every tenant. If the company wants no external forwarding, set Off - Forwarding is disabled and remove the Inbox rule or mailbox forwarding that is still trying. If the company wants the forward, set On - Forwarding is enabled, or create a custom outbound policy scoped to the mailboxes that need it and leave the default on Off.
-
Find who is forwarding. Microsoft points at the
Auto forwarded messages report
for cloud mailboxes. Mailbox forwarding sits on the mailbox in the Exchange admin
center. Inbox rules on another mailbox are listed from Exchange Online PowerShell:
Get-InboxRule -Mailbox <user>
- If On still bounces, check the other two controls. A remote domain can refuse automatic forwarding to some or all external domains. A mail flow rule can match forwarded mail and reject it. Microsoft's table says the block typically wins. The Automatic - System-controlled value is the row that is not deterministic: Microsoft says the result depends on how that setting works in the organisation. The Defender article prints 5.7.520 for the outbound spam policy, not for those two, so read the bounce again before you chase them.
PowerShell reads the same setting. Swap nothing; the default policy is named Default in some tenants and Anti-spam outbound policy (Default) in the portal.
AutoForwardingMode is Off, On, or Automatic. Microsoft's cmdlet reference
for
Set-HostedOutboundSpamFilterPolicy
is the page that names those values.
Message blocked because it contains content identified as spam
Live NDRs, especially from Outlook.com and Hotmail, reuse 5.7.520 for a different sentence. Microsoft Q&A threads quote this one with the NDR still attached.
A wrapped form also shows up. Outlook's DSN wrap puts 554 5.7.0 on the front and keeps 5.7.520 inside the brackets.
I found no Microsoft Learn page that documents that sentence or the
AS(4810) suffix. Microsoft's Defender article for 5.7.520 never prints it.
The public NDR table has no row for it either. Microsoft Q&A staff have treated it
as Microsoft's own outbound content filter, often on HTML mail with a PDF attached, and
they have told senders to retry as plain text, to send a OneDrive link instead of the
file, or to zip the attachment. Those are staff replies on threads, not a published
click path.
Work it as a content filter. Retry once as a text-only message, no logo, no tracking
pixel, no attached file. A copy that lands means the filter matched the original body or
attachment. A copy that still returns AS(4810) means stop rewriting the
message. A consumer
Outlook.com account has no tenant admin to flip a forwarding dropdown; Microsoft support
is the remaining path.
550 5.7.350 is the wrap Microsoft uses when a server
past Exchange Online refuses you as spam, and it is the wrong page unless your bounce
actually reads Remote server returned.
Send the forwarding admin this
The people who can allow the forward have not seen the bounce. Paste this, with the address filled in.
Leave does not allow external forwarding in the paste. A bare 5.7.520
sends an admin into a content filter, and a bare Access denied sends them into
Directory-Based Edge Blocking.
SPF, DKIM and DMARC did not cause this
The documented 5.7.520 check reads whether the tenant allows automatic external forwarding. It does not read a record you publish. A new DMARC record does not create an exception in someone else's outbound spam policy.
Rejections that do come from broken records name them in the text. 550 5.7.515 names the required authentication level, and 550 5.7.23 names SPF. Microsoft's page for 5.7.520 never mentions either check.
You fixed this sender. Tomorrow the reports name the other hosts still sending as you, and we turn a day of XML into one email with a verdict per sender. On the paid plans, the day a report first names a new sender failing, you hear about it. Get the weekly digest. The first domain is free.
Reports about your own domain
DomainCanary is our product, and this paragraph sells the paid plan. A tenant forwarding policy never reaches our parser. Receivers already send aggregate reports about your own domain: which hosts sent as you, and which of them failed alignment. On a paid plan we mail you the day a report first names a failing source with no history on your domain. Pro costs $19 a month for 5 domains. One weekly digest covers every domain that shares a digest address. History on every plan, including free, runs 12 months or more. Free for your first domain.
Alert me on a new failing sourceNo card · 12+ months of history · The free plan does not expire
Questions
What does 550 5.7.520 mean?
Microsoft's documented cause is an outbound spam policy that blocks automatic external forwarding. A mailbox or Inbox rule tried to send a copy outside the tenant, and Exchange Online refused that copy. The leading 5 makes the refusal permanent, so the same forward bounces again until an admin changes the policy or removes the rule.
Can the sender fix 550 5.7.520?
Usually not. If the bounce names external forwarding, only an admin in the tenant that tried to send the copy out can allow the forward or delete the rule. A sender who wrote to that mailbox cannot change the policy. The exception is the other live string, Message blocked because it contains content identified as spam, where the sender can try a plainer copy.
Does 550 5.7.520 mean my SPF or DMARC is broken?
No. Microsoft's page for this code never mentions SPF, DKIM or DMARC. The documented bounce is a tenant forwarding policy, not an authentication failure. Editing a DNS record on your domain cannot allow someone else's mailbox to forward, and it cannot clear a Microsoft content filter either.
The person I wrote to says they got the mail. Why did I get a bounce?
The original message can land in the mailbox, and the copy that a rule then tries to send outside the tenant is what bounces. Microsoft returns that NDR to you, the external sender, for every forwarding method. Phone the person and ask whether they forward mail off the tenant.
I have 5.7.520 Message blocked because it contains content identified as spam. Same page?
The digits match and the job does not. Microsoft's Defender article for 5.7.520 documents only the external-forwarding sentence. Treat that variant as a content filter, and work the section below that quotes it.