550 5.7.350 Remote Server Returned Message Detected as Spam

Problem

Your outbound mail bounces with 550 5.7.350 Remote server returned message detected as spam. You are almost certainly sending through Exchange Online or Microsoft 365, and the sequence is this: Microsoft accepted your message, tried to deliver it to the recipient’s server, and that server rejected it as spam. Microsoft wrapped the remote refusal in the 5.7.350 code and handed it back to you as a non-delivery report. The message never reached the inbox, and resending the same content the same way will bounce again.

Symptoms

• The NDR contains 550 5.7.350 and the phrase “Remote server returned message detected as spam.”
• A second line often follows with the receiver’s own verdict — frequently 554 5.7.1 and text like “rejected due to high probability of spam.”
• Mail to some domains delivers; mail to others (or to one large provider) bounces.
• It started or worsened after moving to a new mail platform, adding a marketing/transactional service, or a spike in volume.
• Messages with attachments (especially zipped ones) or link-heavy bodies bounce more than plain replies.

What 550 5.7.350 Actually Means

Split it into two facts. The 550 is a permanent rejection under RFC 5321 — the mail was refused, not deferred, so retrying unchanged accomplishes nothing. The 5.7.350 is Microsoft’s enhanced status code, and its exact wording is the important part: Remote server returned message detected as spam. The subject of that sentence is the remote server. Microsoft is not the one calling your message spam here; it is reporting that the destination did, and passing the rejection back up the chain to you.

That single detail redirects the whole investigation. People see a Microsoft code and go hunting through their own Microsoft 365 admin center for a switch to flip. But the decision was made by a mail server you don’t control, applying its own filters to your domain, your sending IP, and your content. What you can control is the set of signals that server uses to decide whether to trust you: whether your domain publishes SPF, DKIM, and DMARC; whether the message is actually signed by a domain that aligns with your From address; and whether the content and sending pattern look like the bulk, unsolicited mail these filters are tuned to catch.

The most common root cause is authentication that is missing or misaligned for the real sending path. A message from a new service or relay that isn’t covered by your SPF record, or isn’t DKIM-signed by an aligned domain, arrives looking unauthenticated — and unauthenticated mail from an IP with no reputation is the textbook spam profile. Fix the authentication and the sending hygiene, and the remote filters have far less reason to reject you.

Top 3 Causes

1. Missing or misaligned authentication for the sending source. The service actually sending your mail isn’t in your SPF record, or isn’t DKIM-signing with a domain aligned to your From — so the receiver sees no valid, aligned authentication and treats the message as untrusted. The tell: Authentication-Results in the bounced or received headers shows spf=fail/none or dkim=none, and the failing source is a recently added platform.
2. Poor sender or IP reputation. A new or shared sending IP, a domain with no track record, or a recent complaint spike lowers your standing, and reputation-based filters start rejecting outright rather than sorting to Junk. The tell: it’s intermittent and provider-specific — one large receiver rejects while others still accept — and correlates with a platform change or a volume increase.
3. Content and pattern that trip spam heuristics. Spammy wording, risky or zipped attachments, link-heavy or image-only bodies, and mail-merge blasts to cold recipients all raise the spam score. The tell: plain, personal replies get through while templated or attachment-bearing campaigns to the same domain bounce.

Diagnose with DechoNet

• Email Check pulls your sending domain’s SPF, DKIM, and DMARC records and evaluates them — so you can confirm the record ends the way you think, resolves within the 10-lookup SPF limit (RFC 7208 §4.6.4), and actually covers the service that’s sending. Gaps here are the most fixable cause of a spam rejection.
• Email Header Analyzer reads the Authentication-Results line from a bounced or delivered copy, showing whether the receiver saw spf=pass, dkim=pass, and DMARC alignment — the fastest way to prove whether this is an authentication failure or a pure reputation/content problem.

Resolution Checklist

• Read the full NDR and note both codes — 5.7.350 (Microsoft relaying a remote rejection) and any trailing 5.7.1/receiver verdict — so you know it’s a downstream spam refusal, not a tenant misconfiguration.
• Run Email Check on the domain in your From address and confirm SPF, DKIM, and DMARC all exist and are valid.
• Confirm the actual sending service is authorized: its SPF include: is present, and it DKIM-signs with a domain that aligns with your From — check a real message’s headers with Email Header Analyzer.
• If authentication is clean, treat it as reputation or content: warm up new IPs with gradual volume, remove risky/zipped attachments, and cut spam-trigger wording and cold-blast patterns.
• For a persistent block against one provider, use their postmaster/sender tools and, if offered, their delisting or feedback process — but only after your SPF/DKIM/DMARC are demonstrably passing.
• Send a test message and re-check the headers for spf=pass, dkim=pass, and dmarc=pass before resuming normal sending.

When to Escalate

• If your domain authenticates cleanly (aligned SPF and DKIM, DMARC passing) and a specific large receiver still returns 5.7.350, escalate to that receiver’s postmaster or sender support with the full bounce — the decision is theirs, and only they can explain a reputation or content block on their side.
• If the bounce points at Microsoft’s own outbound protection rather than a remote server (a different code, e.g. mail routed through a high-risk delivery pool), that’s a tenant-side deliverability issue — investigate compromised accounts, outbound spam policy, and the high-risk pool in your Microsoft 365 admin center.