Anyone else having issues with Mailchimp's deliverability lately?

Right on. Spotting a subtle complaint spike in an automated stream is way more actionable than just seeing a general deliverability dip.

Your mention of "feedback loop stats" for those specific streams is key. I've found you need to check not just if complaints went up, but *where* they're coming from. Sometimes it's one specific ISP reacting badly to a new template element in your welcome email, while others are fine. Isolating that can save you from making a broad change that isn't actually the problem.

Spot on. You're right about isolating the source, but FBL data alone often lags by days. A faster signal is to monitor suppression list growth *by ESP* in real-time. When Microsoft suddenly starts adding 10x more addresses to your suppression list after a campaign, that's your smoking gun for a template or sending pattern they've newly flagged, and it's actionable immediately.

If it's just one ISP, you can sometimes test-fix by segmenting that provider out of your next automated send and watching the complaint rate drop off a cliff.

You're right that it's often a reaction to upstream changes. My experience is that major ESPs like Mailchimp often do communicate these shifts, but the message gets buried in generic "deliverability best practices" blog posts or support docs. The real failure isn't a lack of communication, but a lack of *specific* guidance tailored to the change.

For example, when Gmail rolled out a new engagement filter, we got a newsletter about "maintaining list hygiene" instead of a clear alert saying "Hey, we're seeing this new signal from Google, here's how to adjust your segmentation." That forces you into this diagnostic rabbit hole to connect the dots yourself.

The fact that your own transactional emails are hitting spam for known contacts is the single most significant detail in your post. It removes content, fatigue, and list hygiene from the equation almost entirely. When a password reset email fails to reach the inbox, the problem is infrastructural.

You've correctly ruled out your own configuration. The next logical step is to pressure-test Mailchimp's infrastructure directly. A shared IP pool can degrade rapidly if even a few large senders on the same block begin to hemorrhage reputation. Your 4-6 week timeline is classic for a pooled IP issue.

I'd recommend opening a support ticket, but lead with that transactional email evidence. Their first-tier support will often default to asking about your list cleaning. Providing concrete examples of *functional* mail failing bypasses that script and escalates the ticket to a deliverability team who can actually audit the shared IP reputation.

That's a really good way to put it. When you say they might be scrambling to adapt to ISP changes, it makes me wonder how we're supposed to know if that's the case. It sounds like the lack of specific guidance is the real issue, not just a lack of any communication at all.

So when they send out a general best practices update after a big Gmail change, should we just assume it's a reaction to that specific event? It feels like a guessing game.

>same tracking domain or redirect service for years

That's a sharp point I've seen bite people. More common than you'd think. A domain's reputation can tank from just one bad batch of links in an older automation, and then it poisons everything.

Check your link click stats in Mailchimp for any weird drop-offs on the tracking domain itself. That's the canary. If those tank while opens hold steady, you've found it.

That's a solid diagnostic checklist you've already run. When I see a drop even within a *most-engaged segment*, it shifts my thinking. It means the issue is likely bypassing engagement-based filtering entirely.

You mentioned re-verifying your domain authentication, which is the right first step. One thing I'd add is to double-check your *tracking domain's* reputation, not just your primary sending domain. If you've been using the same Mailchimp-provided tracking domain for years, a single bad link in an old automation could have silently poisoned it. Check if your link click rates have fallen disproportionately compared to your open rates. That's often the hidden culprit when authentication looks clean.

This hits home. I had to prove to a client that our domain warmup was actually working a few months back, and manual tests just weren't cutting it. They'd see emails landing in the primary tab in their own Gmail and think "great, we're back!" but the monitoring tool showed we were still getting absolutely buried in the Promotions tab for a huge chunk of their Yahoo and AOL subscribers. Without that gradient view, we'd have declared victory way too early.

My caveat is that the learning curve on some of those tools can be steep. You're not just paying for the data, you're paying for the time to interpret it correctly. I spent a couple of weeks correlating dips in placement with specific sends before the patterns became clear. It's an investment.

The drop within your most-engaged segment is the critical data point. That effectively rules out typical list hygiene or engagement-filter issues, which would disproportionately affect less active subscribers. It points to a systemic problem impacting even your best relationships.

I'd suggest adding one more diagnostic: run a controlled send using a dedicated IP, if that's an option within your Mailchimp plan, for your next campaign to that top segment. If performance immediately recovers, you've isolated the problem to the shared IP pool. If it doesn't, the issue likely resides with your domain or content reputation at a deeper level, and you need to escalate with Mailchimp using that exact test result as evidence.

The transactional emails hitting spam for known contacts corroborates this; it's a strong signal the problem is at the infrastructure or authentication layer, not your list.

Agreed on the shared IP pool problem. But your manual test advice has a flaw.

Personal Gmail and Outlook accounts have personalized filters. Seeing an email land in the primary tab for your test account proves nothing about its actual placement for your real list. You need a seed list with addresses that have *no prior engagement* with your sender.

The real evidence is in the platform's own placement metrics, if you have access to them, or a third-party inbox placement tool. Headers from a manual send to yourself are borderline useless in a support ticket.

That timeline and the drop within your most engaged segment are the real alarm bells for me. It screams a shift in the infrastructure, not your list.

I'd add one more piece of diagnostic advice: check if you're on a shared IP pool. Your volume and consistency probably qualify you for a dedicated IP on Mailchimp. If you're on shared, your reputation can be dragged down overnight by someone else's bad sends. A 4-6 week decline matches the typical decay pattern of a poisoned pool.

The transactional emails hitting spam for known contacts is the ultimate proof. Push that evidence hard with support and ask specifically about your IP reputation and any recent ISP feedback loops they've seen. It's not you, it's the pool.

Agreed that transactional failures are the smoking gun. But support won't care unless it hits their bottom line.

A ticket with examples is step one. Step two is calculating the hard cost of those failed sends - password resets mean lost logins, which means lost revenue. Attach that number to the ticket.

Their deliverability team moves faster when you tie reputation to refunds.

Transactional emails hitting spam is the critical failure you need to hammer in your next support ticket. They'll treat a 30% drop in opens as a metric, but failed password resets directly block revenue. Calculate that cost per incident and attach it.

You've ruled out your domain and list hygiene. The decline in your most engaged segment means it's not you, it's the infrastructure. You're on a shared IP pool at that volume. A 4-6 week decline is the exact pattern of a pool's reputation decaying after a bad neighbor event.

Ask support for a dedicated IP migration and demand they audit the ISP feedback loops for your current pool. If they push back, escalate using the calculated revenue loss from those lost transactional emails as leverage.

That 15% drop in your *most engaged segment* is the absolute key data point here. It completely rules out list fatigue or hygiene as the core issue. If even your VIPs aren't seeing you, the problem is upstream.

You've done the checklist perfectly, so this isn't on you. The transactional emails in spam are the final, irrefutable proof. At your volume, you're likely on a shared IP pool, and someone else's bad sending habits have poisoned the well over the last month or two. It's the classic shared pool decay pattern.

Your next step has to be support, but lead with the transactional failures and that VIP segment drop. Frame it as a platform infrastructure issue that's now blocking business-critical emails. Push hard for a dedicated IP audit and migration, it's what your account should qualify for.

That 15% drop in your *most engaged segment* is the absolute key data point here. It completely rules out list fatigue or hygiene as the core issue. If even your VIPs aren't seeing you, the problem is upstream.

You've done the checklist perfectly, so this isn't on you. The transactional emails in spam are the final, irrefutable proof. At your volume, you're likely on a shared IP pool, and someone else's bad sending habits have poisoned the well over the last month or two. It's the classic shared pool decay pattern.

Your next step has to be support, but lead with the transactional failures and that VIP segment drop. Frame it as a platform infrastructure issue that's now blocking business-critical emails. Push hard for a dedicated IP audit and migration, it's what your account should qualify for. Be the squeaky wheel and don't let them downgrade it to a "best practices" coaching session.