Forward Microsoft 365 support email to Supportbench and resolve blocked forwarding

Forwarding lets customers keep using a familiar Microsoft 365 support address while agents manage the resulting work in Supportbench. It has three distinct parts: a receiving Supportbench route, Microsoft’s permission to forward externally, and the mailbox’s actual forwarding destination. Completing only one part leaves a gap. Use this guide to coordinate the mailbox administrator and support operations owner, then verify that a complete customer conversation works.

Know which address belongs in which field  ·  Prepare a controlled mailbox transition  ·  Allow the intended mailbox to forward externally  ·  Configure the forwarding destination for the mailbox type  ·  Verify a new case and the entire reply path  ·  Understand a 5.7.520 external-forwarding failure  ·  Diagnose the stage that failed  ·  Keep the channel reliable after launch

Know which address belongs in which field

A successful policy change does not populate the forwarding destination. A correct destination does not override a blocking provider policy. Keep these facts separate when troubleshooting rather than repeatedly recreating the route.

Prepare a controlled mailbox transition

1. Identify whether the support address is a shared mailbox or a licensed user mailbox. Use the provider procedure for that type, with the appropriate Exchange and security-policy permissions.
2. Choose the exact mailbox and intended Supportbench queue/division. Confirm who will monitor new work and handle messages that remain in the old mailbox.
3. Create or review the Supportbench route under Settings → Email configuration → Routes (inbound email). Confirm Active route, case defaults, contact handling and matching rules. Save and copy its generated Forwarding address.
4. Record existing forwarding rules and destinations. Check for duplicate rules or a path that sends messages back to the original mailbox. Plan how to reverse the intended forwarding change if acceptance fails.
5. Agree whether a mailbox copy is needed during transition and which system agents should answer from. A retained copy can help reconciliation, but two teams replying independently can confuse the customer.
6. Prepare harmless external test messages from an approved contact, including one reply and an attachment when relevant. Do not use the entire historical inbox as a test batch.

Allow the intended mailbox to forward externally

Microsoft exposes On - Forwarding is enabled, Off - Forwarding is disabled and Automatic - System-controlled. The Automatic behavior can differ between organizations. A blocking mail-flow rule or remote-domain control can still prevent forwarding when another setting allows it. Have the administrator inspect the effective combination, rather than assuming one saved dropdown guarantees delivery. See Microsoft’s external-forwarding controls.

1. In Microsoft Defender, open Email & collaboration → Policies & rules → Threat policies → Anti-spam, or its Anti-spam policies page.
2. Select Create policy → Outbound. Give the policy a descriptive name.
3. On Users, groups, and domains, select the intended internal mailbox under Users. Review the scope and exceptions.
4. On Protection settings, find Forwarding rules → Automatic forwarding rules and choose the approved forwarding setting. Preserve unrelated protection choices.
5. Review, select Create, and verify the policy is enabled with appropriate priority. An administrator maintaining an existing policy should inspect its scope and effective precedence before editing it.

Use a narrowly scoped policy for the support mailbox when it meets your organization’s requirements. Do not turn on external forwarding across all mailboxes merely to connect one support channel. Follow Microsoft’s current outbound-policy procedure for permissions and policy management.

Configure the forwarding destination for the mailbox type

After the forwarding policy is appropriate, set the actual destination. These are provider-side changes; the Supportbench route cannot make them for you.

User-mailbox forwarding applies to new mail and has licensing requirements. Do not delete the forwarding account or remove its required license as part of this setup. Use Microsoft’s user-mailbox forwarding instructions or shared-mailbox instructions for the actual mailbox type. Provider references checked on 28 October 2026.

If a reseller manages the environment or the documented controls are unavailable, have that provider’s authorized administrator configure the equivalent approved destination and policy. Do not substitute a personal inbox rule or broaden access simply because it is easier to find.

Verify a new case and the entire reply path

1. Send a new message from an approved external mailbox to the ordinary customer-facing support address. Use a unique harmless subject and note the send time and time zone.
2. Verify the message reaches the Microsoft 365 mailbox and that forwarding occurs. If it is blocked, have the mail administrator inspect provider delivery evidence before changing Supportbench settings.
3. Find the resulting Supportbench case or activity. Confirm the Contact, Company association, division, queue, priority, body and intended attachment. Review the final result after applicable workflows, not only route defaults.
4. Have an authorized agent reply from that case using the intended Reply Address. Verify the external mailbox receives it with the correct identity and useful content.
5. Reply normally from the external mailbox. Confirm the new message joins the intended case and the support team can see and act on it.
6. Repeat with a second approved sender or the new-contact path when it is part of your intake process. Check for duplicates, loops and unexpected contact attribution.
7. Record the actual case IDs and results. Start routine use only after the team agrees which system owns responses and who will watch for failures.

A manual message sent directly to the generated route is a narrower test: it can establish that the route accepts that message, but it does not test forwarding from the Microsoft 365 mailbox. A message received in the old mailbox alone does not establish that Supportbench received it.

Understand a 5.7.520 external-forwarding failure

A provider error containing 5.7.520 and a statement that the organization does not allow external forwarding points to the Microsoft forwarding policy boundary. Ask the Microsoft 365 administrator to review the effective policy, mailbox scope, remote-domain controls and mail-flow rules. Do not treat this specific rejection as proof that a Supportbench route must be replaced.

Keep the full error available to the authorized administrator along with the forwarding mailbox, destination and message time. Other errors can have different causes; preserve the code and context instead of reducing every delivery failure to “external forwarding is off.”

Diagnose the stage that failed

Keep the channel reliable after launch

For a B2B team, email intake is a customer commitment. Assign a mailbox/integration owner, monitor a first-conversation test after material changes, and keep route names recognizable to supervisors. When a customer says “we already emailed you,” locate the message across the mailbox, forward and case stages before asking them to send private information again.

Recheck after mailbox renaming, license changes, security-policy changes, new routing, or a change of provider administration. If reversing forwarding, review new work already created in Supportbench and tell the operating team which system to use; reverting a provider setting does not move case history back into the mailbox.

Continue learning

• Create the Supportbench inbound route and plan cutover
• Reference email route fields
• Configure outbound reply addresses
• Authenticate and test outbound email
• Select the correct case reply identity