Yeah, MS-specific spam-foldering (versus Google delivering fine) is usually one of three failure modes. Which one you're in depends on your setup - quick check first: 1. What's your sending stack? M365 mailboxes direct, dedicated IP through a relay (SendGrid / Postmark / Amazon SES), or a shared-IP sequencer (Instantly / Smartlead / Apollo / Reply.io)? 2. What does your DMARC aggregate report show for MS-side deliveries? rua reports break out by receiving domain - MS-side pass/fail rates tell you whether it's an authentication alignment problem or a pure reputation problem. 3. Is it consumer inboxes or corporate tenants? Are you getting filtered at consumer addresses (@outlook.com / @hotmail.com / @live.com) or at corporate Office 365 domains? While you're pulling that, three things you can check now: **SNDS / JMRP (for consumer mail).** If you're hitting consumer junk folders, check your IP health at Microsoft's Smart Network Data Services. Heads up: MS overhauled the portal in June, it now lives at substrate.office.com/ip-domain-management-snds/SNDS (old URL deprecated). JMRP complaint feeds went header-only ARF at the same time - sender address redacted, message body stripped, so any tooling built against the old body-included format is broken. If you see a recent complaint-rate spike, that's likely your cause - MS spam-folders aggressively above ~0.3% complaint rate. **EOP + Delist Portal (for corporate B2B).** If you're getting filtered at corporate Office 365 tenants, SNDS won't reflect it - that's Exchange Online Protection filtering. Check whether your sending IP has been flagged on the enterprise blocklist and needs clearing via the Microsoft 365 Anti-Spam IP Delist Portal at sender.office.com. **MS SmartScreen on content.** MS inbound filters are more aggressive than Google on B2B cold-email content signals. In the last 30 days did you change anything about URL density per email, tracking-domain redirects (especially shared sequencer tracking domains), image count, or subject-line patterns? SmartScreen retrains on those shifts quickly. Immediate mitigation while you diagnose: cut your total volume to Microsoft destinations by half for two weeks. Not a permanent fix, but it stops the reputation drop from compounding while you find the root cause. Happy to look at a message-trace header or a rua sample if you drop it here or DM - the specific pattern usually surfaces from those first few data points.
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:
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.
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.
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.
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."
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.
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:
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.
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.
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.
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.
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.
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.
Caroline H. volume is less the issue than UNauthenticated volume. Well-authenticated domain can regularly push 100+/day per inbox without reputation damage. Two things worth checking on your setup, in order: 1. Is the domain you're sending from your main company domain, or a segregated subdomain (e.g., go.<company>.com or mail.<company>.com)? If it's the main domain, any reputation hit affects ALL company email - the segregation is what isolates the risk. 2. Is DMARC published and aligned with your SPF + DKIM? mxtoolbox.com on your sending domain shows this in 30 seconds. Also happy to do a quick scan on your sending domain and share the findings over DM if useful.
0.2% over two weeks is the kind of number where "Google update" is usually the wrong frame. Platform shifts move the needle but rarely take you from 1%+ down to 0.2%. At that level, the message either isn't being seen (spam/promotions placement) or the audience isn't right. Fast triage: Mailflow seed test for actual placement, check Google Postmaster for a reputation drop, and confirm SPF/DKIM/DMARC alignment is still clean on both Google and Azure DFY accounts. Then compare open rates over the same window - if opens collapsed too, it's placement; if opens held but replies didn't, it's copy or ICP.
Before the provider list rolls in, worth flagging the choice matters less than people assume once you're past the obviously bad actors. Most stability problems blamed on infra are actually warming pace, SPF/DKIM/DMARC alignment, or seed damage carried over from the previous setup. Questions I'd put to any vendor before signing: how do they handle warmup pacing, do they expose Postmaster + Mailflow data, and what's their swap-out protocol when a single inbox's reputation slips. Bundled is fine. The diagnostic layer underneath is what saves you when placement dips.
Clay does not provide pre-warmed mailboxes - it is a "Bring Your Own Pipes" system. You connect your own Google Workspace or Outlook accounts, whereas Instantly’s "Done-For-You" (DFY) accounts are ready to send out of the box. That is the single biggest practical differentiator between the two. Here is the 2026 reality check for your setup: • Infrastructure: In 2026, deliverability is all about isolation. Google and Outlook have become elite at fingerprinting shared warmup patterns. While Instantly's DFY accounts get you moving faster, self-managed mailboxes on dedicated domains are significantly more durable for long-term campaigns. If you go with Clay, you'll need to buy domains and warm them for 2–3 weeks first. • Deliverability: Clay’s native sequencer is excellent for keeping your data and sending in one place, but it won't "fix" bad inbox reputation. Most high-level teams use Clay for the enrichment and then push to a dedicated sender like Instantly or Smartlead for the infrastructure management. • The Math: For 500 contacts at 5 steps (~2,500 total emails/month), Instantly Growth ($47/mo) is perfectly sufficient. It caps at 1,000 uploaded contacts and 5,000 sends, so you have plenty of breathing room. Hypergrowth is overkill until you scale past 1,000 new leads per month. So, if you want "push button" simplicity, use Instantly for sending. If you want a "cleaner" long-term reputation and don't mind a 14-day setup delay, use Clay's sequencer with your own dedicated mailboxes.
Deliverability is the easiest of the three to detect from outside. Public DNS lookups show everything. SPF over 10 lookups, DMARC at p=none with no reporting endpoint, missing DKIM alignment across their sending tools - all visible from a Kitterman or MXToolbox check. A company running outbound from a domain with broken DMARC is your textbook ICP.
