Outlook 550 5.7.520 Message Blocked: Fixes

What 550 5.7.520 means

Your message did not land in Junk. Microsoft refused it before delivery.

The common bounce says: 550 5.7.520 Message blocked because it contains content identified as spam. You may also see an AS code after it. The 550 status means the receiving mail system rejected the message during SMTP. The 5.7.x part points to a policy or security block.

This error is usually about the message, the sender, or the sending setup. The Outlook desktop or mobile app is rarely the root cause. For Outlook.com, Hotmail, Live, and Microsoft-hosted recipients, check content, links, attachments, SPF, DKIM, DMARC, IP reputation, domain reputation, and any recipient-side policy.

Start with sender authentication

Microsoft and Google check authentication first, then weigh reputation, complaints, bounces, recipient behavior, and content.

• SPF: publish one SPF TXT record for the domain used in the envelope sender or HELO identity. Include every real sending service. Keep the record within the RFC 7208 limit of 10 DNS lookups. Use ~all while you are still testing, and use -all only when all real senders are known.
• DKIM: turn on DKIM signing in Microsoft 365 and every email platform that sends for the domain. Check the selector, public key, and header.d domain. A valid DKIM signature gives receivers a stable domain signal even when mail is forwarded.
• DMARC: publish a record at _dmarc. Start with p=none while you read reports. Move to quarantine or reject only after normal mail passes SPF or DKIM and aligns with the visible From domain, as described in RFC 7489.
• MX and basic DNS: MX is mainly for receiving mail, replies, and bounces. It does not authenticate outbound mail. Still, broken DNS, missing return paths, or dead reply handling can make a domain look neglected.
• Reputation: check the sending IP and domain. A new IP, a poor shared ESP pool, a complaint spike, high bounces, or a listed IP can trigger hard blocks.

A quick InboxRadar domain scorecard can show the SPF, DKIM, and DMARC state before you change DNS.

Fix the message before retrying

If authentication passes, test the content and sending pattern.

Send a plain text message to the same Microsoft recipient. If it works, add the real links and attachments back one at a time. Watch for URL shorteners, public file-share links, password-protected attachments, tracking-heavy templates, and wording that looks like a phishing lure.

For marketing or product mail, pause sends to old or cold lists until the block clears. High bounces, spam complaints, and low engagement hurt sender reputation. Send only to people who asked for the mail. Keep unsubscribe links easy to find. Do not keep retrying the same Microsoft recipients after a hard 550 response.

Microsoft has published sender rules for domains that send more than 5,000 messages per day to Outlook.com consumer addresses. Those senders need SPF, DKIM, and DMARC. Microsoft says non-compliant mail can be junked at first and later rejected. Use Microsoft's sender guidance for the current enforcement details.

Use DMARC reports to find the bad source

A 550 5.7.520 block can start with one service sending mail that your domain never authorized.

DMARC aggregate reports, also called RUA reports, show which IPs sent as your domain, whether SPF passed, whether DKIM passed, and whether either result aligned with the visible From domain. The reports are XML, so they are hard to read by hand. Use a DMARC report reader to find the service that fails while the rest of your mail passes.

Do not jump straight to p=reject if reports still show unknown senders. Start with p=none, fix each real sender, then move to quarantine and reject when normal mail passes. DMARC policy tells receivers what you want them to do with failing mail. Receivers still apply their own filters and reputation rules.

AI search crawlability is separate

Email delivery checks and AI search checks answer different questions, but both depend on readable public signals.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews use the normal Google Search index, and there is no separate opt-out crawler. Disallowing these crawlers in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

robots.txt is a site's stated policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so logs need care. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to the other AI crawlers, but that is an undocumented risk, not proof that a specific bot cannot run JavaScript. Use the AI visibility checker if AI answers matter for the same domain.