Emails from MS Corporate Accounts Going to Spam in MS Personal Accounts Despite SPF, DKIM, DMARC Setup—Looking for So...

·Jul 15, 2026 07:18 PM·

Hey everyone! 👋 I recently saw an issue where emails sent from "MS corporate accounts" are landing straight in the spam folder of "MS personal accounts" (@live, @hotmail, @outlook). SPF, DKIM, and DMARC are all set up and green, but Outlook’s consumer filters seem extra aggressive. Has anyone run into this MS-to-MS deliverability issue? Any SNDS tricks or specific tweaks that worked for you? Would love to hear your thoughts!

5 comments

· Sorted by Oldest

Md R.
·
·
Yeah, seen this pattern a lot. SPF/DKIM/DMARC green just clears the front-door check at Outlook - the consumer-side (@live, @hotmail, @outlook.com) runs a second filter that's. meaningfully stricter than the enterprise M365 tenant filter. A few things that aren't always on the checklist:
1.
RFC 8058 one-click List-Unsubscribe. Not just any List-Unsubscribe header - the mailto + POST-URL pair with List-Unsubscribe-Post: List-Unsubscribe=One-Click. Missing it = major trust penalty even with everything else green.
2.
JMRP feedback loop. SNDS is useless for shared-IP setups, but JMRP still works. Note: Microsoft recently blinded JMRP. They no longer pass the complainant's raw email address in the headers. You now have to inject custom X-headers or map the returned Message-ID to your own send logs to figure out who hit the spam button.
3.
IP warmth to Outlook consumer specifically. Your IP might be warm to Gmail/Yahoo but cold to Outlook consumer. Microsoft tracks reputation to consumer separately. A small-volume, highly engaged warmup targeting live/hotmail/outlook addresses over 2-4 weeks tends to move the needle more than any DNS change.
4.
The 0.1% Complaint Ceiling. While Google allows up to 0.3%, Microsoft's machine-learning filters flag sending domains when complaints cross just 0.1%. Above that, aggressive junk-folder routing kicks in fast.
5.
Content Triggers. Consumer Outlook's SmartScreen is incredibly aggressive on cold-email patterns. Reduce URL density, cut tracking-domain redirects, and avoid obvious sales/outreach jargon.
6.
Delisting check. If your IP or domain got flagged recently, sender.office.com has a delisting request form. Worth submitting - it's free and occasionally works fast.
What's the IP model - dedicated or shared through the sequencer? Fix priority order changes based on that.
vaibhav k.
·
·
What's solution here then Md R.
Md R.
·
·
Depends which of the six is your actual bottleneck. Rough sequence I usually run: Triage first if sends are actively broken. Pause sends to @hotmail.com / @outlook.com / @live.com for 48 hours so you're not compounding reputation damage while you diagnose. Submit the sending IP + domain to sender.office.com delisting form - 2 minutes, sometimes works fast. Fix the trust signals. 1. RFC 8058 one-click List-Unsubscribe - mailto + POST-URL headers plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. Most sequencers ship this correctly but custom setups often miss the POST-URL line. 2. JMRP feedback loop at sendersupport.olc.protection.outlook.com/pm/. Free. Microsoft blinds the complainant now, so inject an X-Campaign-ID or X-Subscriber-ID header into your outbound - when the JMRP report lands, that header lets you identify and suppress the specific complainer. De-risk the content. 3. Turn off open/click tracking for MS consumer addresses until placement recovers. SmartScreen is unusually harsh on shared tracking domains from marketing platforms. 4. Text-heavy over HTML-heavy. Cut URL count, drop unnecessary redirects. MS-consumer-specific warmup. 5. Pull the segment of MS consumer users who opened or clicked in the last 30 days. Trickle to just that segment - 20-50 sends/day, ramp 10-15% daily over 2-3 weeks - before reintroducing cold or unengaged MS-consumer contacts. No shortcut on this one. Constraint check. 6. If your IP is a shared pool that's actively getting trashed by other senders on it, the above still helps but the ceiling is capped by neighbor behavior. Dedicated IP or a cleaner pool becomes the unlock at that point. Priority depends on your actual constraint - without pulling your DNS + DMARC aggregate reports + a fresh seed-list test, it's a guess which is really breaking your sends. If anyone wants a public-data scan on a specific domain to see which items are in the red, drop it here or DM.
M.Muazzam R.
·
(edited)·
I'm sending through Microsoft 365 mailboxes connected to Instantly. Emails to my personal Outlook account are rejected with 550 5.7.708 - Access denied, traffic not accepted from this IP, not just delivered to Junk. Since the outbound IP belongs to Microsoft's shared Exchange Online infrastructure, have you seen this before? Was the fix simply warming the tenant longer, or is there another Microsoft-specific reputation issue I should investigate?
Md R.
·
·
Yeah, seen this exact combo before. Short version: this is not primarily a warmup problem. 5.7.708 is Microsoft's outbound-abuse system flagging your tenant or source IP as low-reputation. Once that happens, more warmup doesn't clear the flag - it treats the symptom, not the cause. What's actually happening under M365 + Instantly at cold-outbound volumes:
1.
The outbound edge block. The 5.7.708 is a hard rejection at Microsoft's outbound edge. This fires when Microsoft's machine learning detects bulk-sending patterns (Instantly-style shape signals) and restricts your tenant's outbound. It's not just routing you into the High-Risk Delivery Pool (which usually results in spam placement) - Microsoft is refusing to transmit the message entirely.
2.
Instantly-through-M365 at cold-outbound scale is the trigger. M365's outbound limits are officially 10,000 external recipients/day per tenant, but the pattern-detection thresholds are lower and shape-based, not volume-based. Consistent same-content sends across many mailboxes to unengaged recipients is a strong signal - doesn't take many days of that pattern to trip the classifier.
3.
What to check in your M365 Defender admin (in this order):
Restricted Entities list. Defender > Email & collaboration > Review > Restricted entities. If any of your sending mailboxes are listed here, that's the immediate block. Removing them requires clearing the underlying pattern AND acknowledging - Microsoft will re-restrict if the pattern continues.
Outbound spam policy alerts. Defender > Policies & rules > Threat policies > Anti-spam policies. Check the outbound policy for tenant-level alerts fired in the last 30 days.
Custom DKIM signing per sending domain. If you're sending with Microsoft's default onmicrosoft.com-aligned DKIM keys instead of custom DKIM on your actual sending domain, that's a tenant-reputation drag. Configure custom DKIM in your admin center.
Message trace on a rejected send. Get the specific outbound IP from the trace headers. If it's different from your normal Exchange Online outbound range, you're on a restricted pool - from there, delisting has to go through Microsoft Support.
7.
The uncomfortable architectural read. M365 mailboxes plus Instantly-scale cold outbound is fighting Microsoft's own outbound-abuse system. Warmup and custom DKIM help at the margins, but the fundamental constraint doesn't move - you're using infrastructure that Microsoft explicitly forbids for bulk marketing / cold outbound. Operators who consistently succeed at M365-based cold outbound usually run at very low per-mailbox volumes with highly personalized content and high recipient-engagement signals. If your volume math doesn't fit that shape, a different sending stack (dedicated IPs via SendGrid / Postmark / Amazon SES with proper reputation setup) is architecturally cleaner than fighting Microsoft.
Happy to look at a message-trace header from one of your rejects if you drop it here or DM - the fix path is usually either "restricted user, unrestrict and normalize" or "tenant blocked, Microsoft Support ticket plus an architecture question."

Emails from MS Corporate Accounts Going to Spam in MS Personal Accounts Despite SPF, DKIM, DMARC Setup—Looking for So... | Clay

Md R.
·
·
Yeah, seen this pattern a lot. SPF/DKIM/DMARC green just clears the front-door check at Outlook - the consumer-side (@live, @hotmail, @outlook.com) runs a second filter that's. meaningfully stricter than the enterprise M365 tenant filter. A few things that aren't always on the checklist:
1.
RFC 8058 one-click List-Unsubscribe. Not just any List-Unsubscribe header - the mailto + POST-URL pair with List-Unsubscribe-Post: List-Unsubscribe=One-Click. Missing it = major trust penalty even with everything else green.
2.
JMRP feedback loop. SNDS is useless for shared-IP setups, but JMRP still works. Note: Microsoft recently blinded JMRP. They no longer pass the complainant's raw email address in the headers. You now have to inject custom X-headers or map the returned Message-ID to your own send logs to figure out who hit the spam button.
3.
IP warmth to Outlook consumer specifically. Your IP might be warm to Gmail/Yahoo but cold to Outlook consumer. Microsoft tracks reputation to consumer separately. A small-volume, highly engaged warmup targeting live/hotmail/outlook addresses over 2-4 weeks tends to move the needle more than any DNS change.
4.
The 0.1% Complaint Ceiling. While Google allows up to 0.3%, Microsoft's machine-learning filters flag sending domains when complaints cross just 0.1%. Above that, aggressive junk-folder routing kicks in fast.
5.
Content Triggers. Consumer Outlook's SmartScreen is incredibly aggressive on cold-email patterns. Reduce URL density, cut tracking-domain redirects, and avoid obvious sales/outreach jargon.
6.
Delisting check. If your IP or domain got flagged recently, sender.office.com has a delisting request form. Worth submitting - it's free and occasionally works fast.
What's the IP model - dedicated or shared through the sequencer? Fix priority order changes based on that.
vaibhav k.
·
·
What's solution here then Md R.
Md R.
·
·
Depends which of the six is your actual bottleneck. Rough sequence I usually run: Triage first if sends are actively broken. Pause sends to @hotmail.com / @outlook.com / @live.com for 48 hours so you're not compounding reputation damage while you diagnose. Submit the sending IP + domain to sender.office.com delisting form - 2 minutes, sometimes works fast. Fix the trust signals. 1. RFC 8058 one-click List-Unsubscribe - mailto + POST-URL headers plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. Most sequencers ship this correctly but custom setups often miss the POST-URL line. 2. JMRP feedback loop at sendersupport.olc.protection.outlook.com/pm/. Free. Microsoft blinds the complainant now, so inject an X-Campaign-ID or X-Subscriber-ID header into your outbound - when the JMRP report lands, that header lets you identify and suppress the specific complainer. De-risk the content. 3. Turn off open/click tracking for MS consumer addresses until placement recovers. SmartScreen is unusually harsh on shared tracking domains from marketing platforms. 4. Text-heavy over HTML-heavy. Cut URL count, drop unnecessary redirects. MS-consumer-specific warmup. 5. Pull the segment of MS consumer users who opened or clicked in the last 30 days. Trickle to just that segment - 20-50 sends/day, ramp 10-15% daily over 2-3 weeks - before reintroducing cold or unengaged MS-consumer contacts. No shortcut on this one. Constraint check. 6. If your IP is a shared pool that's actively getting trashed by other senders on it, the above still helps but the ceiling is capped by neighbor behavior. Dedicated IP or a cleaner pool becomes the unlock at that point. Priority depends on your actual constraint - without pulling your DNS + DMARC aggregate reports + a fresh seed-list test, it's a guess which is really breaking your sends. If anyone wants a public-data scan on a specific domain to see which items are in the red, drop it here or DM.
M.Muazzam R.
·
(edited)·
I'm sending through Microsoft 365 mailboxes connected to Instantly. Emails to my personal Outlook account are rejected with 550 5.7.708 - Access denied, traffic not accepted from this IP, not just delivered to Junk. Since the outbound IP belongs to Microsoft's shared Exchange Online infrastructure, have you seen this before? Was the fix simply warming the tenant longer, or is there another Microsoft-specific reputation issue I should investigate?
Md R.
·
·
Yeah, seen this exact combo before. Short version: this is not primarily a warmup problem. 5.7.708 is Microsoft's outbound-abuse system flagging your tenant or source IP as low-reputation. Once that happens, more warmup doesn't clear the flag - it treats the symptom, not the cause. What's actually happening under M365 + Instantly at cold-outbound volumes:
1.
The outbound edge block. The 5.7.708 is a hard rejection at Microsoft's outbound edge. This fires when Microsoft's machine learning detects bulk-sending patterns (Instantly-style shape signals) and restricts your tenant's outbound. It's not just routing you into the High-Risk Delivery Pool (which usually results in spam placement) - Microsoft is refusing to transmit the message entirely.
2.
Instantly-through-M365 at cold-outbound scale is the trigger. M365's outbound limits are officially 10,000 external recipients/day per tenant, but the pattern-detection thresholds are lower and shape-based, not volume-based. Consistent same-content sends across many mailboxes to unengaged recipients is a strong signal - doesn't take many days of that pattern to trip the classifier.
3.
What to check in your M365 Defender admin (in this order):
Restricted Entities list. Defender > Email & collaboration > Review > Restricted entities. If any of your sending mailboxes are listed here, that's the immediate block. Removing them requires clearing the underlying pattern AND acknowledging - Microsoft will re-restrict if the pattern continues.
Outbound spam policy alerts. Defender > Policies & rules > Threat policies > Anti-spam policies. Check the outbound policy for tenant-level alerts fired in the last 30 days.
Custom DKIM signing per sending domain. If you're sending with Microsoft's default onmicrosoft.com-aligned DKIM keys instead of custom DKIM on your actual sending domain, that's a tenant-reputation drag. Configure custom DKIM in your admin center.
Message trace on a rejected send. Get the specific outbound IP from the trace headers. If it's different from your normal Exchange Online outbound range, you're on a restricted pool - from there, delisting has to go through Microsoft Support.
7.
The uncomfortable architectural read. M365 mailboxes plus Instantly-scale cold outbound is fighting Microsoft's own outbound-abuse system. Warmup and custom DKIM help at the margins, but the fundamental constraint doesn't move - you're using infrastructure that Microsoft explicitly forbids for bulk marketing / cold outbound. Operators who consistently succeed at M365-based cold outbound usually run at very low per-mailbox volumes with highly personalized content and high recipient-engagement signals. If your volume math doesn't fit that shape, a different sending stack (dedicated IPs via SendGrid / Postmark / Amazon SES with proper reputation setup) is architecturally cleaner than fighting Microsoft.
Happy to look at a message-trace header from one of your rejects if you drop it here or DM - the fix path is usually either "restricted user, unrestrict and normalize" or "tenant blocked, Microsoft Support ticket plus an architecture question."