How do I contact Microsoft about email deliverability issues for B2B clients?
Updated on 6 Oct 2026: We clarified Microsoft 365 support routes, false-positive submissions and the evidence needed for B2B email delivery cases.
For B2B mail sent to Microsoft 365, external senders without a Microsoft 365 business subscription generally need the recipient's admin to open a Microsoft support case. If an NDR identifies a Microsoft 365 IP block and points to sender.office.com, use that portal. For error 5.7.511, follow the NDR and email the full NDR plus the blocked source IP to delist@microsoft.com. If mail is going to Junk or failing only inside a Microsoft 365 tenant, ask the recipient's Microsoft 365 admin to submit the message to Microsoft and open a support ticket with the evidence you provide.
That distinction matters. The sender portal is useful for the IP blocks named in the NDR. It is not a diagnostic conversation for intermittent B2B spam placement. For Microsoft 365 business mail, the receiving tenant has the message trace, quarantine data, SCL (spam confidence level), BCL (bulk complaint level), Defender verdicts, transport rules, allow and block entries, and mailbox-level signals. Without that data, the sender side is guessing.
- 5.7.606-649 IP block: Use sender.office.com when the NDR directs you to Microsoft's Anti-Spam IP Delist Portal.
- 5.7.511 block: Follow the NDR and send the full rejection plus source IP to delist@microsoft.com.
- Spam placement: Ask the recipient admin to submit the message to Microsoft, then open a Microsoft 365 support case if needed.
- Intermittent failures: Collect multiple examples across tenants, dates, IPs, and message types before asking for escalation.
- No bounce: Check the sender's SMTP logs and delivery queue, then ask the recipient admin for a trace to locate the message.
- Temporary throttling: For a 4xx response, preserve the SMTP error and retry history; persistent delays need a support case rather than an IP-delisting request.
Microsoft 365 sender support and recipient support
Separate public Microsoft 365 IP-delisting requests from recipient-tenant support. Technical proof supports both routes. Public sender support is narrow, while recipient-tenant support has more useful telemetry. The evidence keeps the case from becoming a vague complaint about spam placement. Microsoft's external sender support guidance recommends asking the recipient to open a ticket on your behalf.
|
|
|
|---|---|---|
SMTP IP block | NDR-directed delist route | Full NDR, IP, UTC time, code |
Junk folder | Recipient admin submission | Original message, trace, verdict |
Tenant-only issue | Tenant support | Network Message ID, SCL, policy |
5.7.513 customer IP block | Recipient admin's blocklist review | Full NDR, source IP, affected tenant |
451 4.7.550 temporary throttling | SMTP retry review, then tenant support | Exact response, queue age, retry history |
550 5.1.8 bad outbound sender | Sending organization's Microsoft 365 admin | Full NDR, account, Restricted entities status |
Match the support route to the rejection or delivery symptom.
For a Microsoft 365 IP-delisting request, enter the email address that received the NDR and the blocked source IP at sender.office.com. Submit one IP per request, follow the confirmation email, then select Delist IP. For 5.7.511, email the full NDR and IP to delist@microsoft.com instead. Follow Microsoft's IP-delisting instructions. Delisting removes that IP block; spam filtering and tenant policies still apply.
A 5.7.513 error identifies a recipient-managed IP blocklist (blacklist), so ask that tenant's admin to review it. Microsoft's NDR reference distinguishes this from a service-wide IP block. If your own Microsoft 365 account returns 550 5.1.8, your sending admin must check Restricted entities and investigate account compromise before unblocking it.
Do not frame every Microsoft issue as delisting
If the IP is not blocked and mail is intermittently placed in Junk, a delist request has weak fit. In that case, the receiving tenant's Microsoft 365 admin has the better support path because the admin can expose the filtering verdict and policy context.
Build the evidence before you contact Microsoft
Before contacting Microsoft, build a packet that answers one question: why should Microsoft treat this as a deliverability fault rather than normal filtering? A single statement like "our mail is going to spam" is too thin. A packet with matching headers, message trace data, authentication results, and a clear affected pattern has a better chance.
Start with a controlled test using Suped's email tester so you have headers, authentication results, and content warnings from a real send. Keep the affected recipient's original message too, because the test does not reproduce that tenant's filtering. Then run Suped's domain health check to confirm SPF, DKIM, DMARC, DNS, and related signals before asking another team to escalate.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For B2B clients, collect multiple real recipient examples when available, including different Microsoft 365 tenants if the issue affects several customers. A single well-documented tenant incident is enough to open a support case. Several examples with the same sending IP, domain, content class, and date range show a repeatable pattern.
- Message proof: Collect full headers or the original EML, not forwarded copies, because forwarding changes key header data.
- Sending proof: Record the sending IP, envelope sender (MAIL FROM), visible From domain, DKIM signing domain and selector, and exact UTC send time.
- Recipient proof: Ask the admin for message trace, Network Message ID, quarantine status, SCL, BCL, and policy matches.
- Pattern proof: Show whether the issue affects one tenant, one geography, one content type, or all Microsoft recipients.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's DMARC platform supports this workflow by turning authentication and reputation findings into a short fix list. Monitor DMARC, SPF, DKIM, and blocklist (blacklist) status, then use the results as evidence instead of manually stitching reports together. Aggregate DMARC reports summarize source-level authentication, while the recipient's trace and original EML provide message-specific evidence. Microsoft's DMARC reporting guidance explains that distinction.
Case evidence templatetext
Issue type: B2B Microsoft 365 spam placement or intermittent block Sending domain: example.com Sending IP: 203.0.113.10 Envelope sender (MAIL FROM): returns@bounce.example.com Visible From domain: example.com DKIM signing domain and selector: example.com, selector1 Authentication: SPF pass, DKIM pass, DMARC pass Affected recipients: tenant-a.com, tenant-b.com First observed: record the first affected UTC timestamp SMTP response and receiving host: include exact acceptance or rejection Send times: 2026-05-20 14:15 UTC, 2026-05-20 16:40 UTC Message IDs: include full values from headers Network Message IDs: ask each recipient admin for the matching value Recipient verdicts: ask for SCL, BCL, quarantine, and policy match Submission ID: include after the admin submits the message to Microsoft Business impact: transactional mail delayed or placed in Junk
Distinguish IP blocks, throttling and spam placement
A common mistake is treating every Microsoft complaint the same way. A Microsoft 365 5.7.606-649 IP rejection, a 5.7.511 rejection, and a message that lands in Junk are different problems. The evidence and contact route change with the symptom. Check the responding SMTP host and recipient's MX records to establish which system handled the failure.
Microsoft 365 service IP block
- Signal: The SMTP rejection or NDR names a Microsoft delisting route.
- Route: Use sender.office.com for 5.7.606-649, or email delist@microsoft.com for 5.7.511.
- Goal: Request delisting or reputation review for the blocked source IP.
Spam placement
- Signal: Mail is accepted at SMTP but lands in Junk or quarantine.
- Route: Ask the recipient admin to submit it as legitimate mail, then use Microsoft 365 support if needed.
- Goal: Find the tenant verdict, policy match, or content classification.
A 451 4.7.550 response is a temporary restriction, not proof of a permanent IP block. Microsoft's throttling guidance describes this response. Keep the exact SMTP logs and queue age, let the sending server retry with backoff, and avoid immediate repeated resends. If delays persist, include that retry history in the tenant's support case.
When Microsoft accepts the message but filters it later, the answer is often inside Exchange Online Protection or Microsoft Defender for Office 365. The sender cannot see those details directly. If you need a deeper path through this type of case, the Outlook troubleshooting steps cover the filtering checks that matter most.
Microsoft Defender message details with authentication results and filtering policy data for a Microsoft 365 email delivery investigation.
Example hard-block evidencetext
SMTP response: 550 5.7.606 Access denied, banned sending IP Remote system: contoso-com.mail.protection.outlook.com Sending IP: 203.0.113.10 Recipient domain: contoso.com Timestamp: 2026-05-20 14:15 UTC Action: submit the IP through sender.office.com For 5.7.511 instead: Action: email the full NDR and source IP to delist@microsoft.com
What to send the recipient admin
When the recipient is a B2B customer, keep the ask short. The recipient admin does not need a long theory about Microsoft filtering. They need the exact message, the exact time, and the exact data to pull from their tenant.
Recipient admin packet
- Submit: Ask the admin to submit the legitimate message to Microsoft for analysis.
- Trace: Ask for delivery action, policy match, SCL, BCL, Network Message ID, and quarantine status.
- Sample: Send the original message as an EML attachment, not a forwarded copy.
- Escalate: If the submission does not resolve the issue, open a support case with the Submission ID and evidence packet.
Full headers matter because ordinary forwarding changes the message. Microsoft's admin submission guidance accepts the original .eml or .msg file, or the Network Message ID. Ask the recipient admin to check the full delivery path if a gateway handles mail before Microsoft 365. An [External] label alone is not a spam verdict, as Microsoft's Customer Insights guidance explains.
Short note to the recipient admintext
Subject: Microsoft 365 deliverability review request We are investigating a Microsoft 365 delivery issue affecting mail from example.com to your tenant. The message was accepted by Microsoft but reached Junk or quarantine. For a message in Junk, report it as Not junk. For quarantined mail, ask the admin to submit the original sample directly. Confirm that the message was submitted to Microsoft and record the Submission ID. If the issue continues, please open a Microsoft 365 support case with the original EML, Submission ID, message trace result, SCL, BCL, quarantine status, policy matches, and Network Message ID. Sending IP: 203.0.113.10 Sender domain: example.com Send time: 2026-05-20 14:15 UTC Message ID: include value from the message headers
Ask the admin to submit a false positive
For legitimate mail in Junk, the recipient can use Outlook's Report action and select Not junk. The Microsoft 365 admin can then review the report or submit the original message through the Submissions page in the Microsoft Defender portal. Check the tenant's user-reported message settings: reports go to Microsoft, a tenant reporting mailbox, or both. Reports sent only to the tenant mailbox still need an admin submission to reach Microsoft. See Microsoft's user reporting settings.
- The recipient reports the affected message as Not junk in Outlook.
- Within 30 days, while the message remains in the mailbox, the admin opens Actions & submissions > Submissions > Emails in Microsoft Defender. Submit the original file or Network Message ID, specify an affected recipient, and select "I've confirmed it's clean" after verifying the message is legitimate.
- The admin records the Submission ID, result, original verdict, and detection reason.
- If legitimate mail is still filtered, the admin opens Microsoft 365 support with the Submission ID and matching trace evidence.
Use allow entries as temporary containment
A tenant allow entry can restore delivery while Microsoft reviews a false positive, but it only changes that tenant's handling and can bypass useful filtering. Use the narrowest entry for the shortest practical period, then remove it after Microsoft corrects the verdict or the sender fixes the cause. Submitting a false positive alone does not override user or domain impersonation protection; the admin must review the anti-phishing policy that detected it.
How the recipient admin opens a Microsoft 365 support case
With the NDR or message evidence, the recipient's Microsoft 365 admin can open a service request for the affected tenant. Use the Exchange Online mail flow symptom and business impact to describe the issue.
- Check the Microsoft 365 admin center's Service health dashboard for an Exchange Online incident that matches the symptoms.
- Open Help & support in the admin center and describe the email delivery issue. If the suggested results do not resolve it, select Contact Support.
- Choose phone or email, confirm contact details, and select Contact me. Include the original NDR or message, UTC timestamps, trace details and any Submission ID.
- Record the support case number and add fresh examples to the same case if the problem continues.
These support methods require an admin for a business subscription. If all subscriptions were purchased through a partner, contact that partner for support. Microsoft's business support instructions explain eligibility and the contact process.
Check authentication and sending practices before escalation
Check the basics while collecting evidence for Microsoft. A dedicated IP with little sending history gives Microsoft fewer sender reputation signals; low volume alone does not establish the cause of a delivery problem. If the issue is new, check what changed: content, traffic mix, sending cadence, authentication, DNS, complaint rate, and recipient interaction.
Microsoft's enforced high-volume authentication requirements apply to domains sending at least 5,000 messages per day to Outlook.com consumer services, including Hotmail, Live and MSN. Both SPF and DKIM must pass, and messages must pass DMARC with a published policy of p=none or stricter. Microsoft's Outlook.com authentication requirements explain error 550 5.7.515. These consumer requirements do not define the support route for custom domains hosted on Microsoft 365. Once a domain reaches the high-volume threshold, it should continue meeting those requirements even if its daily traffic drops.
Case evidence completeness before escalation
An editorial checklist for evidence completeness. One well-documented tenant incident is enough to open a support case.
Weak
Missing evidence
One complaint, no headers, no trace
Usable
Trace available
Original message and one tenant trace
Strong
Scope documented
Original message, trace, verdict and affected scope
Confirm SPF, DKIM, and DMARC pass on real mail, not only that the DNS records exist. Suped's DMARC monitoring helps catch source-level failures and policy drift before those failures become a Microsoft case. Check IP and domain reputation with blocklist monitoring to identify issues that need investigation. External blocklist (blacklist) results are supporting evidence; the NDR or tenant verdict identifies the Microsoft action.
- Authentication: Check SPF and DKIM on real sends and confirm DMARC passes. DMARC needs one passing mechanism with the required From-domain match.
- Domain match: Compare the visible From domain with MAIL FROM for SPF and the DKIM signing domain for DKIM, using DMARC's domain-matching rules.
- IP behavior: Volume should be steady enough for Microsoft to build confidence in the stream.
- Recipient quality: Remove invalid addresses and hard bounces. Send marketing mail to consenting recipients and investigate complaint spikes.
- DNS hygiene: PTR, HELO, SPF includes, DKIM selectors, and DMARC rua reporting should be clean.
- Message practices: Use valid From and Reply-To addresses that accept replies. Keep subject lines accurate and include a visible, working unsubscribe link in marketing mail.
Where Suped fits in the Microsoft workflow
Suped does not replace Microsoft support. Suped's DMARC platform helps you reach Microsoft or the recipient admin with better proof. The sender needs to show that authentication is clean, sources are known, reputation is being watched, and the issue is isolated to Microsoft or specific tenants.
Suped workflow
- Monitor: Track DMARC, SPF, DKIM, sending sources, and policy movement in one place.
- Detect: Use automated issue detection and fix steps before opening a support case.
- Alert: Get automated alerts when incoming DMARC reports show authentication failures or changes in sending sources.
- Control: Use Hosted DMARC or Hosted SPF when the evidence points to an authentication record problem.
- Scale: Use the MSP and multi-tenancy dashboard when one team manages many client domains.
The workflow keeps the case tied to evidence: which sources sent mail, which sources passed authentication, what changed, and what needs repair. Microsoft or the recipient admin can use that evidence when the problem is intermittent.
Views from the trenches
Best practices
Open the sender form only for true blocks; use tenant support for Junk placement.
Build cases with headers, trace details, SCL, BCL, and exact UTC send times for proof.
Separate Microsoft-specific symptoms from general authentication or list quality issues.
Common pitfalls
Treating spam placement as a delisting case wastes time and weakens the ask badly.
Forwarded samples remove headers, which makes Defender and trace review much harder.
Limited sending history on dedicated IPs makes reputation assessment harder during a case.
Expert tips
Ask affected recipients to escalate through their tenant because they see the verdicts.
Track the first bad date closely; Microsoft cases improve when the pattern is time-bound.
Keep a standard evidence packet ready so each new incident adds proof, not confusion.
Marketer view
Marketer from Email Geeks says the sender support form is the main public route, but it fits hard blocks better than vague B2B spam placement.
2024-04-25 - Email Geeks
Marketer view
Marketer from Email Geeks says intermittent Microsoft 365 filtering needs tenant-side data because the sender cannot see Defender verdicts.
2024-04-25 - Email Geeks
