Bounce and error codes

550 5.7.350 Remote server returned message detected as spam

Last updated 2026-09-01

Exchange Online handed your message to a server past Microsoft's edge, and that server refused it. The bounce opens with 550 5.7.350 Remote server returned, then an arrow, then the other server's own words. Microsoft did not write that second sentence. Your SPF, DKIM and DMARC records did not write it either, unless those words name a failed check. Read the text after the arrow first. The last section of this page is the message to send the admin who runs that remote system.

The exact bounce, and the arrow

Microsoft's Exchange Online NDR table, updated 2026-08-11, has no row for 5.7.350. The strings below come from NDRs Exchange Online generates, quoted on Microsoft Q&A with the NDR still attached. I found no Microsoft Learn page that documents the wrap itself.

The arrow is part of the bounce. Everything to the left is Microsoft's wrapper. Everything to the right is the SMTP reply the remote server sent back. A live bounce to Gmail looks like this one, from a thread Google's own help community published.

A frequent tail after those two is a generic spam-probability line. Microsoft still wraps it as 5.7.350.

A Barracuda-style gateway prints a different tail, and Microsoft still wraps it as 5.7.350.

The NDR Microsoft generates for this code speaks to the sender in this paragraph, copied from those same reports: "When Office 365 tried to send the message to the recipient (outside Office 365), the recipient's email server (or email filtering service) suspected the sender's message is spam." The next paragraph tells you to contact the recipient's email admin and ask them to add your domain or address to their allowed senders list. It then says "it's likely that only the recipient's email admin can fix this problem."

Outlook wraps the whole thing in a report headed Your message couldn't be delivered. The generating host sits under prod.outlook.com. That names the service that wrapped the refusal. It does not name the service that made it.

Microsoft wraps a refusal it did not make

Exchange Online Protection accepted the message from you, then tried to hand it to the next hop. That hop said no. Microsoft's NDR anatomy page describes that split: if the remote mail server acknowledges the message and later rejects it, the remote server generates the NDR; if it never accepts the message, Exchange Online generates the NDR and prints the remote reply inside it. 5.7.350 is that second case, with Microsoft's own code stuck on the front.

The closest official article is Microsoft's page for 550 5.7.1, which says its steps also apply to codes 5.7.0 through 5.7.999. That page never names 5.7.350. Its opening cause list is a permission or routing problem, which is the wrong first guess for a wrap that says "detected as spam".

• The wrap is not a Microsoft spam verdict on inbound mail. You already got past Exchange Online. The refusal happened after that hop.
• The wrap is not Directory-Based Edge Blocking. DBEB prints 550 5.4.1 Recipient address rejected: Access denied and it runs on the way in, not on the way out.

Nearby codes that use the same wrap

5.7.350 is the code in most bounces, and live NDRs reuse the same "Remote server returned" prefix on nearby digits. Microsoft's public NDR table does not list 5.7.350 itself, and it does not list every nearby code either. The rows below are the codes that show up in live NDRs or in Microsoft's own articles.

5.7.367 is the exception that does name authentication. Microsoft's page for it says the error "occurs because of SPF or DKIM authentication failures in forwarded or relayed emails", and it shows up most on mail that passed through a non-Microsoft gateway. If your bounce is 5.7.367, work that article, not the spam steps below.

Read the text after the arrow

Keep the bounce open. The wrapper always says "Remote server returned". The diagnosis lives in the sentence after the arrow.

1. A named blocklist or SURBL check. The remote filter refused a URL or an IP it already lists. The admin who runs that filter can add an allow entry. You can also strip the URL or attachment that tripped it and send a cleaner copy. Changing a DNS record does not unlist you.
2. Gmail's low-reputation line. The remote server is Gmail, and the embedded 550 5.7.1 names the sending domain's reputation. Message blocked covers that Gmail family. Microsoft's wrap does not add a second cause.
3. 550 permanent failure, with :blocked. 550 permanent failure covers the Barracuda wording. The wrap means Exchange Online relayed into that appliance and the appliance said blocked.
4. Words that name SPF, DKIM or DMARC. The remote server ran a check and printed the failure. Then the wrap is a courier for an authentication rejection. 550 5.7.23 is Microsoft's own SPF refusal, and 550 5.7.515 is Microsoft's bulk-sender bar. A remote Gmail 5.7.26 inside the wrap is the same job on Google's side.

Steps 1 to 3 are the usual 5.7.350. Step 4 is real, and it is the minority. Start at the remote text, not at your zone file.

Four checks before you write to their admin

1. The remote words, copied in full. Paste them into a note before you close the NDR. The wrapper will look the same next time. The tail will not.
2. One recipient or many. Mail to other domains going through is a verdict about that one remote system. Mail to every domain bouncing with the same tail is a verdict about what you sent, or about the IP Microsoft used on the way out.
3. A cleaner copy, once. Microsoft's NDR says the sender may be able to alter the message. Send a plain-text test with no logo, no tracker and no attachment to the same address. If that copy lands, the filter tripped on content. If it bounces with the same tail, stop editing the message.
4. The IP Microsoft sent from. Read it from the Diagnostic information for administrators section inside the NDR, or from the last Received: header in the message source. Reverse-lookup that IP. Swap in the address from your bounce:
   dig +short -x 203.0.113.24
   If the tail named a DNS blocklist, query that list with the IP reversed octet by octet. A SURBL tail names a URL list, so check the links in the message rather than the IP. Microsoft 365 outbound IPs rotate, so a listing on one hop does not describe the next.

After those four, the remaining work sits inside the receiving organisation. Resending the original copy spends the same refusal again.

Send the receiving admin this

The people who can allow your domain have not seen the bounce. Paste this, with the address and the exact tail filled in.

Leave the remote tail in the paste. A bare 5.7.350 sends an admin into Microsoft's own anti-spam settings, which is the wrong tenant.

Your DNS records are not involved, unless the arrow says so

Publishing a DMARC record does not add you to someone else's allowed senders list. The wrap reports a decision the remote server already made. Microsoft's NDR for this code never mentions SPF, DKIM or DMARC.

The exception is the tail that names a failed check. Then the records on the From domain are the work, and the wrap is only how Exchange Online delivered the news. 554 5.7.1 covers other policy refusals that reuse 5.7.1 in the tail. 550 permanent failure covers what the leading 5 commits your own server to.

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.