If you want an inbox placement test to tell you the truth about where Gmail or Outlook will put your mail, the seed mailbox that receives the test has to behave like a neutral new recipient — not like a mailbox that has learned to love (or hate) the senders that test against it. That neutrality does not survive on its own. It has to be maintained. The mechanic we use is rotation.
Why seeds go stale
Gmail, Outlook and most major ML-filtered providers adjust folder placement partly on per-recipient engagement signals. Read a sender's messages and the filter learns: this recipient likes this sender. Mark a sender as Not Spam and the filter writes that in capital letters. Do the opposite and the filter writes the opposite.
A seed mailbox that receives tests from a few hundred different senders each week is not a neutral observer. It is a mailbox whose filter has an opinion about "senders that look like test senders". Given enough time the opinion can tilt in either direction — and both tilts produce wrong answers.
The "always inbox" trap
If the seed's operators are careless and mark test messages as read, or worse mark Spam placements as Not Spam to clean up the mailbox, the filter learns that messages from this general population of senders belong in the Inbox. Every test sender starts to land in Inbox regardless of actual reputation. The reports look great. They are useless.
This is the most common failure mode we see when we spot-check competitors' seed pools. A bad sender sends a deliberately-misconfigured message (no DKIM, bad SPF, shouty subject line), and the report still claims 95% inbox placement. The seed has been cleaned up to the point of blindness.
The "always spam" trap
The opposite also happens. A seed that has only ever received mail from cold outreach tools and deliverability-test senders eventually gets classified as a mailbox whose user does not want that kind of mail. Everything goes to Spam. The report looks dire even for senders with near-perfect reputation.
We saw this with one of our first Mail.ru seeds. Eight weeks of test sends, no organic inbound traffic, and Mail.ru's filter started Spam-routing messages that landed in the Inbox on every other provider. The seed was not broken — it had correctly learned that the mailbox did not want this kind of mail. The fix was to retire the seed and create a new one.
Measuring drift
We measure drift with a canary campaign. Every hour, each seed receives two known-good sends (from our own transactional domain, which has months of reputation, and from a reputable newsletter we subscribe to) and two known-bad sends (from a deliberately-misconfigured domain and from an IP on a public blacklist). The expected result is simple: known-good in Inbox, known-bad in Spam.
seed drift panel (gmail consumer, last 30 days):
known-good inbox rate: 100% 99% 100% 98% 92% 85% ... drifting down
known-bad spam rate: 100% 100% 100% 100% 100% 100% ... still good
verdict: seed biased toward Spam-routing generic senders
action: schedule retirement, start new seed soakWhen known-good inbox rate drops below 90% on three consecutive days, we plan a retirement. When it drops below 75% we retire immediately and mark the provider degraded on the status page until the replacement seed is live.
Rotation cadence
Six months is our default. Some providers go longer — ProtonMail and Tutanota both have filters that barely depend on per-recipient engagement, so a single seed can run for a year. Consumer Gmail and consumer Yahoo usually need rotation at the six-month mark. Mail.ru and Yandex are more volatile and can need rotation in three to four months.
What we rotate — the mailbox, not the IP
Important distinction that confuses people from the IP-reputation side of deliverability: we are not rotating sending IPs here. The sending IP is the customer's. We are rotating the receiving mailbox, because the bias lives in the filter's per-recipient state, not in the network.
A new mailbox on the same provider has a fresh per-recipient filter state. The provider's global reputation data for the test senders does not change; what changes is the private, per-recipient signal that a specific mailbox has accumulated about the general population of test senders.
Handling Google Workspace retention
Google Workspace accounts get special treatment. We do not delete them when we rotate — Workspace has minimum data-retention requirements that make a clean delete awkward. Instead, a rotated Workspace seed is moved into an archive tenant, kept alive at minimum cost for 180 days, and only then deleted. During archive it does not receive tests. This is the most expensive part of rotation and the main reason we try to be disciplined about rotating only when the canary says we must.
A seed mailbox is retired when its canary campaign tells us it has an opinion — in either direction — about senders it should not have an opinion about.
Open questions we still live with
Rotation is not a solved problem. A few things we still wrestle with:
- Cross-seed leakage. When a Gmail seed is retired and a new Gmail seed is created, Google Workspace's shared reputation infrastructure still knows something about the senders that have historically mailed our account base. We have not observed strong leakage in practice but we cannot prove its absence.
- Calibration of the canary itself. If our known-good sender accidentally develops a real deliverability problem, the canary will misfire across every seed simultaneously. We mitigate with two known-good senders, but correlated failures are a real risk.
- Rare providers with slow soak. A new Mail.ru account needs a longer soak than a Gmail account. During the soak, the provider runs at reduced seed capacity. We still do not have a clean answer to this other than scheduling retirements so Mail.ru soak and Gmail soak never overlap.