You're on the right track with the placement audit, but I'd argue it's premature as step one. The raw header analysis from a few seed sends is a faster, free diagnostic that can confirm or rule out the IP pool change theory in under an hour. If you see a new sending IP in the last external `Received` header, you've found a probable cause and can take that evidence directly to your ESP. An audit will tell you you're in Promotions, but the header tells you *why* that might have happened suddenly. Do the free check first, then use the audit for granular placement mapping if the headers don't show a smoking gun.
Mike
Totally agree on the test-first approach with a seed list. It's like checking the temperature before you jump in the pool.
Your point about X-Gm-Message-State is a pro move. For anyone else trying this, Gmail's Postmaster Tools API can be a bit of a bear to set up initially, but that granular placement data is gold once you get it flowing. A simpler hack I've used is to just have those seed accounts auto-forward a copy of the received message to a parser I set up in Make - the headers are all preserved, and you can spot "category: promotions" without needing full API access.
But you've hit the core tension: if even your best content lands in tabs for your most engaged seeds, you're not in a re-engagement problem anymore, you're in a hard reputation reset. That changes the whole game plan.
Spot on about the forwarded messages hack. That's a clever way to bypass the API setup headache.
One thing to watch for: if you're using a forwarded message to check headers, remember that some forwarding setups (like Gmail's 'forward as attachment') preserve the original headers perfectly, but others might strip or alter them. Always do a quick sanity check by comparing the forwarded headers to the ones you see when opening the original in the seed account itself.
The "hard reputation reset" point is the real gut punch. It shifts the whole timeline from a quick fix to a long, slow rebuild.
Infrastructure as code is the only way
Blaming the ESP for a silent IP shift is convenient, but they aren't the only ones moving you. Your own actions can trigger it automatically. Connect a high-volume Shopify flow? The system sees that new potential load and reassigns you to a different shared pool before you send a single email. The cause isn't always on their side.
Your stack is too complicated.
You're right to zero in on inbox placement. That's almost always the culprit after a sudden drop with clean metrics. One thing I'd add to your checklist, though, is timing. An audit will show *where* you landed, but if the drop coincided with a specific campaign or a spike in send volume, that's your correlation point. A massive but still-permission-based blast can sometimes trigger a temporary tab demotion even without reputation damage, as filters react to the pattern shift. So while you're waiting on the audit results, cross-reference the drop date with your send logs for any anomalies in pacing or content type.
Keep it constructive.
Totally get why you'd jump straight to an inbox placement audit. It makes sense.
But I saw some folks earlier mentioning checking raw headers first, and honestly that sounds like a faster way to start. Couldn't you just send a test to a personal Gmail you own, check the headers for the last 'Received' IP, and compare it to an older email? If it's different, that might explain the sudden drop and you'd know before paying for a tool.
Is there a reason the audit is definitely step one instead of that? Just trying to learn the order of operations here.
The inbox placement audit is indeed a critical first diagnostic layer, but its primary value is in mapping the symptom, not isolating the etiology. You're correct to suspect a delivery issue, but the audit result alone - say, a shift to Promotions - is an outcome. Your next step is correlating that outcome with a proximate cause, which often lies in a change invisible on your dashboard.
While you await audit results, immediately conduct a parallel investigation into your sending infrastructure's consistency. The most common technical trigger for a sudden, list-wide placement demotion is an unnoticed change in the outbound IP address, either through an ESP pool reassignment or a routing change in your integration. Extract the full headers from a recent send and compare the final external `Received` IP against one from a campaign prior to the drop. A mismatch here is a strong indicator and provides actionable evidence for your ESP. This can often be done in the same timeframe as setting up an audit.
That's a very precise distinction between mapping the symptom and isolating the cause, and it's absolutely correct. I'd add one technical nuance to your header comparison method: when you're comparing that final external `Received` IP, also check the SPF authentication result line in the headers. A silent IP shift can sometimes cause SPF to pass but from an unexpected IP, which is a red flag for filters even if everything technically validates. It's not just about the IP changing, but whether that new IP is properly aligned with your domain's SPF record.
That makes me think about automation. If you're using a platform that dynamically ramps up sends based on an event trigger, wouldn't that look like a sudden pattern shift to an ISP even if it's technically "on plan" from your side? The filter just sees a spike.