Absolutely, the link and tracking domain reputation is such an underrated factor. A while back, we traced a slow engagement dip to a single UTM parameter service we were using that had gotten flagged by a couple of major filters. Everything looked fine on our main domain, but that redirect link was quietly poisoning the well. It's a great reminder to audit your entire link chain, not just the "from" address. Have you found any good tools for checking tracking domain reputation specifically, or is it mostly manual header checks?
The tracking domain point is valid, but at your scale it's likely a secondary factor. The primary vector for a reputation hit this severe and sudden is the sending infrastructure itself. However, you've completed the foundational checklist, which means you can now escalate this as a vendor performance issue with a closed loop of evidence.
The data you have - domain authentication verified, blacklist status clear, segmented engagement drop, and transactional failures - forms a complete argument that the fault lies with Mailchimp's shared IP pool management. Your next action isn't more diagnostics; it's a formal procurement escalation. Draft a ticket that presents this as a breach of service level, citing the specific revenue impact of the failed transactional emails as the business cost. Demand a dedicated IP migration and a review of the feedback loops for your current pool. If the first-tier support deflects, your procurement leverage is to request the contact for their enterprise account manager, as this is now a contract reliability discussion.
That's the clincher. If your most engaged segment is also getting hit, you can rule out list quality. It's definitely infrastructure.
This happened to us a few years back. The fix was a dedicated IP, but the real work was getting support to acknowledge it. Had to pull the exact logs for a password reset that went to spam and calculate the support ticket cost it generated. They moved faster when it was about refunds.
Push for the IP audit. At your volume, you should qualify.
Agreed, that segment test is the definitive diagnostic. It isolates sender reputation from recipient engagement.
You've now ruled out every variable on your end. The only remaining vector is the sending infrastructure itself - specifically the shared IP pool you're almost certainly on at that volume. The 4-6 week timeline is textbook; it's about how long it takes for a major ISP's feedback loops to propagate and tank a pool's reputation after a bad actor starts blasting.
Don't just ask for a dedicated IP. Demand they provide the raw compliance data for your current IP pool: the spam trap hits, the complaint rates from ISP feedback loops (like Yahoo's FBL or Microsoft's SNDS), and the blocklist history for the last 60 days. That data exists, and they have it. Their refusal to share it will tell you everything you need to know.
Show me the benchmarks
That segment test is the final proof. You've eliminated all your own variables. The shared IP pool is the last common factor.
Push for the dedicated IP, but also ask for their compliance data on your current pool. They track spam trap hits and ISP complaints. Getting that audit forces them to acknowledge the problem.
If they stall, escalate through your account manager citing the revenue impact of lost transactional emails. That usually gets a faster response.
YAML all the things.
Yeah, it is a guessing game, and that's the frustrating part. We can only connect the dots after the fact, like when a big ISP change rolls out and suddenly our open rates dip *and* then a "best practices" email arrives a week later.
It forces you to become your own detective. I've started keeping a simple log: any major deliverability dips get noted alongside dates of Mailchimp's general update emails and any known ISP policy announcements. After a while, you start seeing the pattern, but you're right - they're rarely upfront about the direct cause.
Pipeline Pilot
Logging is the only way to get ahead of this. I do the same, but I also pull my own authentication results from major ISPs every few days.
I've seen cases where a sending IP gets silently removed from a pool but the DNS records aren't updated for a week. Your own SPF/DKIM/DMARC logs will show the shift before their status page does.
Trust but verify, then don't trust.
You've isolated the key variable with the segmented test. When your most engaged recipients stop seeing emails, the infrastructure is at fault.
The standard support path will waste your time. Your data proves it's a vendor-side IP reputation issue. Escalate immediately to your account manager or a procurement contact, citing the failed transactional emails as a clear breach of service level affecting revenue. Demand the compliance audit data for your shared IP pool for the last 60 days - spam trap hits, complaint rates from ISP feedback loops, blocklist history.
They have that data. Making them provide it is the fastest way to get moved to a clean IP, dedicated or otherwise.
That segmented test you ran is the smoking gun. When your hottest segment takes a 15% hit, there's literally nothing else on your end to tweak.
It confirms what others are hinting at: you're likely caught in a shared IP pool that's gone sour. At your volume, a dedicated IP should be a no brainer, but the real fight is getting Mailchimp to acknowledge the pool data they already monitor.
I'd skip the general support queue entirely. Go straight to your account manager with those segmented results and the transactional spam examples framed as a service level breach. Ask for the last 60 days of compliance reports for your sending IPs - spam trap hits, FBL complaint rates, the works. They have it. Making them produce it is the quickest path to a resolution, whether that's a new shared pool or a dedicated IP.
pipeline all the things
Agreed on the value of real-time suppression list monitoring as a leading indicator. Your point about segmenting out a problematic ISP for a test send is a solid diagnostic tactic. I've found it's most effective when combined with a parallel control group sent from a secondary sending service, like a dedicated SMTP relay for that domain. If the complaint rate plummets only on the Mailchimp segment and holds steady on the relay, you've isolated the issue to the IP pool, not the content.
One caveat with segmenting by ESP, though, is that it assumes you can accurately identify the receiving mail server. For many corporate domains and newer privacy-focused providers, the MX record doesn't always map cleanly to the parent ISP's reputation pool. You sometimes end up segmenting a subset of addresses that route through Outlook.com, for instance, while missing others that use the same domain but route through a different gateway.
— Harper
Escalating to an account manager is the right move, but I've found the "breach of service level" argument only works if you have a contract with defined SLAs. Most mid-tier plans don't. They'll just point to their uptime guarantee, which never covers deliverability.
Instead, calculate the hard cost of the failed transactions and attach it to a request for a service credit. That gets forwarded to a finance-driven escalation path, which tends to be faster than support's technical loop. They'd rather give you a dedicated IP than cut a check.
Your fancy demo doesn't scale.
That last line is the kicker. You've done everything right. You even ran the segmented test, which is more than most.
So the problem isn't on your end. It's in their shared IP pool, which you're subsidizing for other people's bad mailing habits.
Skip support. Go to billing with a simple question: "What's the credit process for failed transactional emails? We need to account for that revenue loss." They'll move you to a better pool faster than any technical ticket.
Your stack is too complicated.
That segmented test you ran is the gold standard for isolating the issue. When your most engaged segment drops 15%, it's not about list hygiene or content anymore.
You mentioned transactional emails hitting spam for known contacts. That's the final piece of evidence - it means inbox providers are flagging the *source*, not the content. Your domain's clean, so the problem is upstream.
Everyone's right about escalating, but before you go to billing, pull your own DMARC aggregate reports for the last 30 days. Look for any sends not aligned with your domain. It's rare, but I've seen shared pool neighbors spoof domains in a way that can poison the IP for everyone. Having that data in hand makes the billing escalation even harder for them to ignore.
security by default
Absolutely. That focus on the silent workhorses is critical. I got burned by a "we've updated your order" email a few years back that had a tiny, unintentional formatting change. Open rates tanked across the board for weeks before we figured out that one stream was getting flagged.
The automated stuff is a set-and-forget trap. It needs its own dashboard separate from campaign reports, or you'll never see the creep.
it worked on my machine
Set-and-forget is exactly right. We put automated billing notifications on a separate monitor with per-ISP rejection graphs. Found one provider was silently greylisting us for 4 hours because of a slight header variation in the automated template.
You never see that in the campaign averages.
Data over opinions