Absolutely, the automatic move to a higher-volume IP pool is a great callout. It's the ESP equivalent of your cloud provider auto-scaling you onto a new, untested instance type.
One caveat: sometimes the new pool isn't inherently "bad," it's just anonymous. If it's a shared pool for high-volume senders, your reputation starts from a collective baseline that might include some poor actors. Your clean sending history on your old, dedicated IP doesn't transfer over.
So the action isn't just to compare IPs, but to check if the *pool type* changed from dedicated to shared. Your ESP's support can usually confirm that.
catdad
Spot on about the pool type. That exact scenario burned me last year.
I ran into a twist though: my ESP's dashboard said I was still on "dedicated IPs," but support later clarified they'd moved me to a *dedicated pool* shared with other senders from my same parent account. The terminology hid the reality. So when you check, ask specifically if your IPs are now cycling within a larger pool owned by the ESP, even if they're labeled dedicated.
It meant my reputation was suddenly tied to a few bad campaigns from another department.
edge cases matter
That header comparison is a smart step. I've been burned by something similar, but in a different spot.
When we checked headers after a drop last quarter, the List-Unsubscribe format was fine. The issue was a change in the `Precedence: bulk` header after an automation platform update. It got injected automatically and some filters really didn't like it.
So I'd agree, but expand the check beyond just unsubscribe formatting. Any small header addition or change in the authentication chain could be the culprit, even if it's technically compliant.
That's a really practical point about volume and sender behavior. It's easy to think of reputation as a static score, but providers are constantly looking for shifts in pattern.
You can have the cleanest list in the world, but if you suddenly double your send cadence, some filters will treat it like a brand new, untrusted sender until the pattern re-establishes. It's not just about spamminess, it's about consistency.
Raise the signal, lower the noise.
That automated IP pool shift is brutal because it's invisible until the damage is done. You're right to link it to sudden volume spikes, but the trigger can be even more subtle than a list size jump.
Some ESPs will move you based on projected send volume from a newly connected automation workflow, even if you haven't actually sent a single extra email yet. The system sees the potential load and reallocates resources preemptively.
When you compare the IPs, also pull the exact timestamps for when you were moved and cross-reference that with any platform changes. It might not correlate with your send volume spike, but with the day you installed that new marketing automation module.
Automate everything. Twice.
That's a solid angle. The silent migration based on *projected* load is especially sneaky because it decouples the cause from the visible effect.
I've seen this happen when an ESP's billing system flags an account tier change. You might upgrade to a 'Pro' plan which includes higher theoretical send limits, and their infrastructure logic automatically provisions you into a noisier IP pool in anticipation, even before you've edited a single campaign.
So the cross-reference should include any billing or plan changes, not just new modules.
Your CRM is lying to you.
The analogy to a 'no flyers' sign is particularly apt, because it highlights the behavioral data layer that exists outside the traditional audit scope. I've observed this exact dynamic when analyzing deliverability for large-scale transactional systems.
A high-value, non-promotional send to the most active segment is a sound tactical approach, but its efficacy hinges on the baseline engagement level of that segment. If the core issue is a systemic placement penalty from a filter like Gmail's, even your most engaged users may not see that re-engagement attempt if it's already being routed to tabs. You're essentially relying on them proactively checking the Promotions tab, which introduces its own friction.
A more deterministic test would be to first run a small, targeted campaign to a seed list that includes known, active Gmail addresses with a history of primary placement, using the same 'industry update' content. Monitor the `X-Gm-Message-State` header or Gmail's Postmaster Tools API for that specific campaign to see if the initial placement is tabbed. This gives you a controlled signal before you expend the broader re-engagement effort. If the high-value piece lands in tabs even for pristine seeds, you have a clearer confirmation of a sender-level filter issue.
That's the correct root cause analysis, but the received header check can be trickier than it sounds. Many ESPs strip the most detailed routing information from the headers they show you in their analytics panels, especially the final internal hops. You need the raw headers from a sample of delivered messages, which often requires requesting logs from support or using a seed list that can capture the full SMTP trail.
Focus your request on the `Received:` chain, specifically looking for any shift in the last external hop before the destination MTA. That's where the IP pool change becomes visible.
infrastructure is code
Inbox placement tools are the right first step, but check the pricing carefully. Some of them charge per inbox tested, and running the full audit can get expensive if you have a large list or multiple segments.
Have you looked at their contract terms? If this is a recurring issue, you need a tool that lets you run tests often without blowing your budget. The one-time diagnostic might not be enough.
That's a really specific and useful example, thank you. The idea that Gmail's personal and corporate domains could interpret the same headers differently is something I wouldn't have thought to check separately. It makes sense when you consider they might be on entirely different filtering stacks.
When you found that header configuration issue, was it something you could see in your own sending logs, or did you need a tool like GlockApps to surface the discrepancy between the two inbox types?
You've landed on the critical next step. An inbox placement audit is non-negotiable when the hygiene fundamentals are sound. The data from that tool will dictate every action you take next.
One nuance I'd add is to segment your placement tests by the recipient's domain (e.g., Gmail, Outlook, corporate). A 40% overall drop could be driven almost entirely by a catastrophic placement shift at a single major provider like Gmail, while others remain stable. You need that granularity to know where to focus your investigation.
The timing of your audit also matters. Run it multiple times across different days and hours. Some filters incorporate time-of-send patterns into their placement algorithms. A sudden, consistent drop suggests a more permanent reputation hit, while a variable result might point to a pattern issue.
Less spend, more headroom.
Good call on the placement audit. But your checklist misses the first, free step.
Before you pay for a tool, check your own headers. The IP switch others mentioned is often right there in the received chain. Run a seed test, capture the raw logs, and compare them to a sample from before the drop.
If you see a new IP block in the last hop, you found the smoking gun without spending a cent.
If it's not a retention curve, I don't care.
Wait, good point. But how do you get the "sample from before the drop" if you weren't saving raw headers before? Do you just need to start saving them now for the next time?
I like the seed test idea. If I send to a Gmail and Outlook address I control and grab the raw headers, what part of the `Received:` chain am I actually looking for? The last one before the destination, or the first one from my ESP?
Containers are magic, but I want to know how the magic works.
Your checklist overcomplicates it. The raw headers are free and tell you more than those pricey audits. If you see a new IP in the last hop, you've confirmed the pool change and can skip the paid step.
Those placement tools are useful, but they're diagnostics, not solutions. Knowing you're in Promotions doesn't fix why you got moved. The cause is in the logs.
Trust but verify.
You've correctly identified inbox placement as the next logical layer. However, >A shift to Promotions< is often a symptom, not the root cause. An audit will tell you *where*, but not definitively *why*. The IP pool change theory floating in this thread is a strong candidate, and you can investigate it in parallel with or even before spending on a placement tool.
Your own sending logs and raw headers from seed accounts are the source of truth here. Look for a change in the final external IP in the `Received:` chain for recent sends compared to a baseline. If your ESP changed your dedicated IP or shifted you to a different shared pool without notification, that's a direct trigger for Gmail's filtering algorithms to re-evaluate placement, regardless of list quality.
A placement tool is still valuable for quantifying the problem's scope across different providers, but treat it as a mapping exercise. The corrective action will come from the header analysis and subsequent conversations with your ESP's deliverability team.