Why are my emails to Microsoft domains being blocked and how can I resolve it?
Published 1 Jun 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified Microsoft rejection codes and the authentication evidence needed to resolve blocked email.
If Microsoft is blocking your email, read the SMTP error literally, then verify whether the identity named in the error is the one you checked. A Microsoft block can be caused by the sending IP, the HELO or EHLO hostname, reverse DNS, SPF, DKIM, DMARC, message content, recipient tenant policy, or Microsoft's internal reputation rules.
For the specific error 550 5.7.1 with HELO domain listed in Spamhaus, do not stop at checking the outbound IP. Check the HELO hostname, the visible domains in the message, the reverse DNS name, and any domain used in SPF or DKIM. If all of those are clean and the rejection happens only at Microsoft domains, the next step is a focused Microsoft escalation with evidence.
Fast answer
Do not rotate IPs or rewrite DNS in a panic. Preserve the failing headers and SMTP transcripts first, then document current blocklist (blacklist) results with lookup sources and timestamps for Microsoft's review.
- Check HELO: Find the hostname your mail server sends after EHLO and test that exact domain.
- Check scope: Separate Outlook.com, Hotmail, Live, MSN, and Microsoft 365 tenant failures.
- Escalate cleanly: Send one clear ask with timestamps, recipient hosts, sender IPs, and the exact error.
Why Microsoft rejects or filters your email
For policy rejections, Microsoft's inbound filtering has decided the connection or message violates policy. The fix is to identify which layer is failing, correct sender-side issues, then request a review if the rejection persists. Passing authentication and public blocklist checks does not guarantee acceptance.
- SMTP policy reject: A 550 response from the receiving Microsoft server means it rejected the message during SMTP, before inbox placement.
- HELO listing: The named host can be the EHLO name, not the IP address you looked up.
- Reputation block: Microsoft filters use IP reputation, domain reputation, complaints, content, and authentication signals.
- Tenant filter: For Microsoft 365 recipients, a recipient organization's policy can quarantine or reject messages.
- Internal reputation: A clean public blocklist result does not rule out Microsoft's own reputation filters or a recipient policy.
Who to contact
Use the affected destination and exact error to choose the support route.
Single tenant
Work with recipient admin
One Microsoft 365 customer blocks or quarantines your mail.
Consumer domains
Open sender support case
Outlook.com, Hotmail, Live, or MSN reject the same stream.
All Microsoft
Escalate with proof
Consumer and Microsoft 365 destinations reject the same sending stream.
For Outlook.com, Hotmail, Live, and MSN, Microsoft's own Microsoft postmaster page points senders toward reputation, authentication, DNS, and support submission paths. If your symptom is a bounce rather than silent junk placement, the practical companion is a Microsoft bounce guide that keeps the investigation tied to the NDR and SMTP code.
Confirm which server rejected the message
A Microsoft 365 non-delivery report (NDR) does not establish that Microsoft blocked the message. Compare 'Generating server' with the rejecting remote server and the 'Remote server returned' response. A Microsoft-generated bounce for a non-Microsoft recipient can describe that recipient provider's rejection. Microsoft's NDR reference explains these fields.
- 4xx responses are temporary failures. Keep the message queued and retry with backoff rather than repeatedly forcing delivery.
- 5xx responses are permanent failures for that attempt. Fix the stated cause before resending; repeated unchanged attempts do not resolve the block.
A final 250 response after message transfer means the receiving server accepted responsibility for the message. It does not prove inbox delivery. For accepted mail, check junk folders and ask the Microsoft 365 recipient admin to review message trace or quarantine.
How to read the Microsoft error
A common mistake is checking the outbound IP, seeing no public listing, and assuming the error is wrong. Check the exact identity and rejection wording first; a clean public result does not establish that Microsoft has stale data.
Example HELO-specific SMTP rejection
smtp;550 5.7.1 Service unavailable HELO domain is listed in Spamhaus. To request removal from this list, see the lookup page. (S8001)
For Microsoft 365 recipients, follow Microsoft's delisting instructions. For 550 5.7.606-649, use the IP delist portal named in the NDR. For 550 5.7.511, that portal does not apply; forward the full NDR and IP address to delist@microsoft.com as instructed in the rejection. A 451 4.7.550 response is a temporary IP restriction, so queue the message and retry with normal backoff. Consumer Outlook.com blocks use a separate sender support route through Microsoft postmaster.
For 550 5.7.513, the recipient organization put your sending IP on its custom blocklist (blacklist). Contact that organization's email administrator to review the entry; service-wide IP delisting does not remove a tenant-specific block. This distinction is documented in Microsoft's SMTP error reference.
What the error names
- HELO host: The hostname your sending server presents at the start of SMTP.
- Named domain: The domain Microsoft says matched a blocklist or blacklist rule.
- Policy code: Preserve S8001 and the full reply. The marker alone does not prove which identity or reputation signal caused the block.
What people often check
- Outbound IP: Important, but it does not prove the HELO hostname is clean.
- IP-only status: Useful for connection reputation, but not a full blocklist diagnosis.
- Last campaign: Content changes matter, but connection-level rejects often happen before content review.
Use a valid, fully qualified HELO hostname with public forward DNS. The sending IP should have a PTR record whose hostname resolves back to that IP. The HELO name does not need to match your visible From domain. A provider-managed hostname is acceptable when its DNS is configured correctly.
Basic sender identity checks
EHLO mail.example.com mail.example.com. IN A 203.0.113.10 10.113.0.203.in-addr.arpa. IN PTR mail.example.com. example.com. IN TXT "v=spf1 ip4:203.0.113.10 ~all" _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Sender identities Microsoft checks when blocking email: sending IP, HELO hostname, PTR name, SPF domain and DKIM domain.
Evidence to collect before escalation
Before opening or updating a Microsoft ticket, collect evidence that identifies the sending stream and the rejecting server. Keep the ticket short enough to understand and detailed enough to act on.
- Capture reply: Save the full SMTP reply, rejecting host, UTC timestamp and actual connecting IPv4 or IPv6 address from your delivery logs.
- Identify HELO: Pull the EHLO hostname from your MTA logs or SMTP transcript. A connection rejected before message transfer has no recipient-generated message headers.
- Compare scope: Test consumer Microsoft domains and Microsoft 365 recipients separately.
- Verify DNS: Check forward DNS, reverse DNS, SPF, DKIM, and DMARC for the sending stream.
- Document reputation: Record current blocklist (blacklist) results for the IP, HELO and sender domains, including lookup sources and UTC timestamps.
A real message test helps because valid DNS records do not prove a message authenticates correctly. Use Suped's email tester to send a live message and inspect Authentication-Results for SPF, DKIM and DMARC. A pass at a test mailbox does not establish Microsoft's verdict on the rejected connection.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For a broader DNS pass, run a domain health check across the sending domain before you update the ticket. Fix missing DMARC or SPF syntax errors, then verify the DKIM selector used by the actual message. Include the results in your escalation notes.
What to fix before escalation
Microsoft support is easier to work with when the obvious sender issues are already removed. Treat these checks as the minimum bar before asking Microsoft to recheck a block.
Sender-side fixes
- SPF match: The envelope sender domain, normally shown in Return-Path after delivery, must authorize the actual connecting IP or sending service.
- DKIM pass: Enable DKIM for the sending stream and verify a passing signature against its selector and public key in DNS.
- DMARC record: Publish DMARC and verify a pass using SPF or DKIM. Under relaxed matching, the authenticated domain and visible From domain share an organizational domain; strict matching requires an exact domain match.
- PTR identity: Ask the IP owner or hosting provider to set a PTR record for the actual sending IP, with a hostname that resolves back to it. Check IPv6 as well as IPv4 when both are used.
- List quality: Suppress hard bounces and complaints promptly. Segment low-engagement recipients for review instead of removing them based only on opens.
If one server sends for several domains, verify each stream's envelope sender and DKIM signing domain separately. A valid SPF record on the HELO hostname does not authenticate every From domain. Publish only one SPF record per envelope sender domain and stay within SPF's limit of 10 DNS-querying terms, including nested include and redirect processing.
|
|
|
|---|---|---|
SPF | Authorized IP and pass | Sending source |
DKIM | Valid signature | Selector or key |
DMARC | DMARC pass for the From domain | Authenticated domain |
PTR | Forward-confirmed name | Reverse DNS |
HELO | Routable hostname | MTA identity |
Blocklist | IP and domains clear | Cause and delisting |
Compact triage map for Microsoft blocking incidents.
Minimum DMARC record for monitoring
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
A monitoring policy of p=none does not request enforcement. Aggregate reporting requires a rua destination and a receiver that sends reports. Reports show authentication for the traffic they cover; they do not prove inbox placement or account for every connection rejected before message transfer.
Meet Outlook.com's high-volume sender requirements
Since May 5, 2025, Outlook.com has required stronger authentication for high-volume senders. Microsoft defines the threshold as 5,000 or more messages per day to its consumer email services using the same visible From domain. Treat 550 5.7.515 as an authentication failure. Investigate that code even if current daily volume is below the threshold.
- SPF must pass for the envelope sender domain, and its record must authorize the actual sending source.
- DKIM must pass with a valid signature and a current public key in DNS.
- DMARC must have at least a p=none policy, and messages must pass DMARC using SPF or DKIM with the required domain match. Both SPF and DKIM must pass independently; DMARC requires the domain match for at least one.
- Bulk and promotional mail should have clear consent, an easy-to-find working unsubscribe link, accurate headers and prompt bounce suppression.
Outlook.com high-volume rejection
550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.
The Microsoft postmaster page covers the consumer Outlook.com service and its sender requirements. Passing these checks does not guarantee inbox placement, but it removes a documented reason for rejection.
Use Suped to gather authentication evidence
Suped is our DMARC and email authentication platform. During a Microsoft blocking incident, use Suped to identify sending sources and review their SPF, DKIM and DMARC results in received aggregate reports. Compare those findings with your delivery logs and configured blocklist monitoring.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Use Suped's DMARC monitoring to check the affected sending source and blocklist monitoring to add observed listing changes to the evidence packet. Correct approved authentication records through hosted controls where configured. Suped cannot expose Microsoft's internal reputation data or remove Microsoft blocks; the SMTP reply and Microsoft's review are still needed.
Manual triage
- Evidence gap: DNS, logs, DMARC reports, and blocklist checks sit in separate places.
- Slow alerts: Teams often learn about Microsoft failures after support or sales reports them.
- Fragile fixes: SPF changes and sender additions can break when DNS ownership is unclear.
Suped workflow
- Issue detection: Suped highlights authentication failures and gives steps to fix them.
- Configured alerts: Your team receives notifications when monitored authentication results change.
- Hosted controls: Hosted SPF and hosted DMARC reduce DNS handoffs during urgent fixes.
For MSPs and agencies, compare affected client domains in the multi-tenant dashboard, then use delivery logs to check whether they share a sending IP or route. Similar failures across clients help define the scope of the support request.
Escalate persistent Microsoft-only rejections
After you check the sending identities, DNS, authentication and public blocklist status, ask Microsoft to review a persistent Microsoft-only rejection. Clean public checks do not identify the internal reason for a block. Document observed failures without assigning an unverified internal cause.
Microsoft Defender for Office 365 email entity page showing delivery action, filtering verdicts and authentication results.
For personal Outlook.com accounts, Safe Senders and inbox rules apply only after Microsoft accepts the message. They cannot override a service-level SMTP rejection, and personal accounts do not have access to the Microsoft 365 quarantine portal. For a Microsoft 365 work or school recipient, the tenant admin can inspect message trace, quarantine, and policy hits.
For Microsoft 365 messages that were accepted but filtered, the recipient admin should review Microsoft's false positive steps. Check the spam confidence level (SCL), bulk complaint level (BCL) and policy verdicts to identify the cause. Submit legitimate messages as false positives where appropriate, correct the specific policy entry if needed, then retest the same sending stream.
Escalation language that works
Keep the support request short and specific to the observed error. If the reply names the HELO domain, include that identity, current lookup results and the tested recipient scope. Do not claim a Microsoft-wide failure from one tenant test.
- Clear ask: Ask Microsoft to review the rejection for the identity named in the complete SMTP reply.
- Current proof: Include the exact lookup time, sender IP, HELO name, and recipient domain.
- No guesswork: If the first response misses the issue, add a fresh failure timestamp and request review of the exact rejection.
Ticket evidence template
Issue: Microsoft rejects mail with 550 5.7.1. Full SMTP reply: [Paste the complete reply, including HELO wording and S8001 if present] Sender IP: 203.0.113.10 HELO: mail.example.com Envelope sender domain: example.com From domain: example.com Recipient domain: outlook.com Rejecting Microsoft host: [Hostname from delivery log] SMTP stage: [Stage where rejection occurred] First seen: [UTC timestamp] Latest failure: [UTC timestamp] Current checks (include lookup source and UTC time): - Sending IP: [Listing result] - Named HELO/domain: [Listing result] - PTR and forward DNS: [Result] - SPF: [Result for connecting IP and envelope sender] - DKIM: [Result, d= domain and selector] - DMARC: [Result for visible From domain] Ask: Please review the rejection for the named HELO domain and sending IP. Current public lookup results and the SMTP transcript are attached.
After a mitigation or delisting, send a small test through the affected route before restoring normal traffic. Check fresh SMTP responses and recipient placement; removal of a rejection does not guarantee inbox delivery.
Resolve the block in order
The quickest path out is to start with the exact Microsoft SMTP reply, identify the identity it names, and validate every related domain and IP. If you find a real sender issue, fix that first. If everything is clean and the block is Microsoft-only, escalate with a precise request for Microsoft to recheck the decision.
- First move: Confirm whether the rejection names the IP, HELO hostname, sender domain, or policy.
- Second move: Fix DNS, authentication, reputation, and list-quality problems you can prove.
- Third move: Escalate to Microsoft with the smallest complete evidence packet.
