As an app publisher, how do we get a customer tenant unblocked from 550 5.7.708 on Graph sends, when Outlook itself sends fine?

What our app does

We run a SaaS product for small trade businesses. A customer signs up, then connects their Microsoft 365 work account to our app through the normal OAuth consent flow. Our app is a multi-tenant Entra app registration with delegated permissions (Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, offline_access).

Once connected, the app reads the customer's inbox and sends email as the customer, from their own mailbox, through Microsoft Graph:

1. POST /me/messages to create a draft (subject, HTML body, one toRecipients entry)
2. POST /me/messages/{id}/send

No from or sender override, no SMTP, no connector, no shared mailbox. Every call uses the customer's own delegated token. Hundreds of customers use this today without problems.

What happens for one customer

A customer connected a Microsoft 365 account created a few days ago (Australian region, licensed mailbox). For this tenant every email our app sends is accepted by Graph (202 Accepted, the message lands in Sent Items with a Message-ID) and then bounced a few seconds later by Exchange Online:

550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP.
For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653
AS(7230) [ME6P282MB6270.AUSP282.PROD.OUTLOOK.COM 2026-11-11T01:19:03.030Z 08DF3F4057E7A24B]

The NDR's original headers show the message was submitted inside the mailbox server (Received: from SYDP282MB258296... by SYDP282MB258296... with mapi id) and refused by the next Exchange Online hop. It bounces to every external domain we tried (Google, iCloud, a .com.au business). 6 of 6 sends over two days bounced.

The same mailbox sends fine from Outlook on the web to the same recipients at the same time. The customer therefore believes our app is at fault.

What we checked

• Our app has not changed. Other customer tenants send through the same code path on the same days with no bounce.
• The NDR article for 5.7.703/705/708/750 says 5.7.708 is a low-reputation sending IP, "more likely to affect new customers", and that only the tenant's email admin can fix it by contacting Microsoft Support.
• Existing Q&A threads (2120130, 2109339) show Microsoft staff answering the same symptom with "the tenant needs a sending exclusion for 60 days, raise a support case".

What we ask

Microsoft staff answered the same symptom in Q&A 2120130 and 2109339 with "the tenant needs a sending exclusion, raise a support case".

As the app publisher, how do we request that unblock for a customer's tenant ourselves? Asking the customer to open a case is not an option for us. Our own tenant has no Azure support plan, so the Entra portal offers only Billing and Subscription issue types. We can share the tenant, mailbox and full NDR privately with a Microsoft engineer.