01What a 250 actually tells you
A 250 is a receipt for a handover. The receiving MTA has read your message off the wire and accepted responsibility for what happens to it next. That is a real and useful fact — it means authentication passed the connection-time checks, the recipient was not rejected outright, and you are not being blocked at the door — but it is a statement about a transfer, not about an inbox.
A 250 means the receiving MTA took the message into its own queue. Inbox, spam and silent discard all happen after that, and all three produce exactly the same delivery event.
$ MAIL FROM:<[email protected]>250 2.1.0 Ok$ RCPT TO:<[email protected]>250 2.1.5 Ok$ DATA354 End data with <CR><LF>.<CR><LF>$ .250 2.0.0 Ok: queued as 4Xk9m2# connection closes. nothing further is ever reported.
Read that last line carefully: queued. The receiver has taken the message into its own queue, and its own filtering runs after that, on its own schedule, with information you do not have — the recipient's history with your domain, how the rest of your traffic behaved this hour, what other people did with your last campaign. The connection is already closed by then. There is no second callback in the protocol.
| Outcome | What it is | What your event stream records |
|---|---|---|
| Inbox | The message is in the primary folder, or in a tab. This is the outcome you wanted and the one you cannot observe. | delivered |
| Spam | Delivered, filed, and effectively invisible. | delivered |
| Silently discarded | Accepted and then dropped with no DSN. Large receivers do this to mail they are confident about, so you get a 250 and nothing arrives anywhere. | delivered |
02Where real placement data comes from
There are exactly two ways to learn where your mail landed, and both of them involve somebody on the receiving side telling you. Nothing on the sending side can work it out, no matter how much event data it collects, because the fact is not present in that data at any resolution.
Placement is only ever known by the receiver, so there are exactly two ways to learn it — seed mailboxes you control, and the provider’s own postmaster feed.
- Seed sends: a direct observation of the folder, for accounts you control
- Postmaster feeds: the receiver’s own verdict across your whole volume to them
- Both come from the receiving side, because that is where the fact lives
- Tells you the receiving MTA accepted the message
- Contains no folder, no filtering verdict, no silent discard — at any resolution
- No amount of event data collected on the sending side can derive one
Mailboxes you control, at the providers your audience actually uses, included in the real campaign. Somebody or something then looks at each one and records the folder. That observation is direct evidence: it is where this message landed for this account.
Google Postmaster Tools and Microsoft SNDS. The receiver aggregates across your whole volume to them and reports back — spam rate, domain and IP reputation, authentication results, delivery errors. This is the only view you get that covers your actual recipients rather than a sample.
The two have opposite weaknesses, which is why serious senders run both. A seed list is a direct observation of a handful of accounts that are unlike your real recipients in the way that matters most: nobody ever opens them, replies to them, or files them, so they have no engagement history to be judged on. Postmaster feeds cover your real traffic and are aggregated, delayed, thresholded — Google shows you nothing until your volume to Gmail is large enough — and never resolve to an individual message.
| Source | What it actually tells you | What it cannot |
|---|---|---|
| Seed sends | The folder this exact message landed in, for these accounts, on this send. | Anything about recipients with real engagement history — which is all of them. |
| Google Postmaster Tools | Spam-complaint rate, domain and IP reputation, authentication pass rates, delivery errors, across your Gmail volume. | Per-message or per-recipient placement. And nothing at all below its volume threshold. |
| Microsoft SNDS | Complaint and trap-hit data for IPs you send from, plus a filter verdict summary. | Anything about Outlook.com consumer placement for a specific campaign. |
| Your delivery events | That the receiving MTA accepted the message. | Folder. Filtering. Whether it was silently discarded. Any of it, ever. |
03Reading an estimate that says it is one
Between “accepted” and “inboxed” there is a gap, and it is legitimate to model it — provided the model is labelled as a model everywhere it appears, and never hardens into a number people quote as a measurement. That labelling rule is not decoration; it is the entire difference between a useful estimate and a lie with a percentage sign.
Model the gap if you like, but the label has to live on the number itself — an estimate that loses its label becomes a measurement by the time it reaches a slide.
An estimate is built from the signals you do have, all of which correlate with placement without determining it: authentication results and DMARC alignment, your complaint rate where a feedback loop reports one, bounce mix by class, engagement trends per receiving domain, and the shape of your sending — sudden volume changes, new domains, new content patterns. A model over those inputs can be genuinely informative. It still is not an observation.
delivered = 49,812 ← measured: the MTA said 250 estimated placement ≈ 91% ← modelled: never call this "inbox rate" seed observation = 8 / 10 ← measured, tiny sample, direct evidence gmail spam rate = 0.08% ← measured by the receiver, aggregated
Three rules keep an estimate honest, and they are worth applying to any vendor's placement chart as a test of whether theirs is:
Not in a tooltip, not in a footnote in the docs — on the number itself, every time it renders. A figure labelled once and then referenced bare in an export becomes a measurement by the time it reaches a slide.
A single percentage implies a precision the inputs cannot support. A range, or a direction plus a confidence, is honest about a model built on correlates. If a tool cannot state its error bars, it has not measured its own accuracy either.
Use the estimate to notice something and to prioritise. Use seeds and postmaster feeds to confirm it before you change your sending, your list, or your content on the strength of it.
04Acting on a placement problem
The case worth preparing for is the one where delivery stays at 99%, no chart turns red, no bounce class spikes — and clicks are down forty percent. Nothing is broken; you are being filtered. Here is the order to investigate in, cheapest and most likely first.
Confirm it is placement rather than measurement, check alignment at the message level, read the receiver’s own verdict, line the drop up against your changelog — then seed, and change exactly one thing.
Opens are a bad witness here — MPP and scanners move them for reasons unrelated to placement. Look at clicks, replies and downstream conversion, and check whether the drop is uniform or concentrated in one receiving domain. A drop confined to Gmail is a placement story; a drop across every provider at once is usually a link, a template, or a tracking change.
Send yourself the real campaign and read the received headers: SPF, DKIM and DMARC results, and whether the passing one aligns with the From domain. An expired DKIM key, a rotated selector, or a new subdomain sending without alignment produces exactly this signature — accepted everywhere, filed as spam everywhere.
Google Postmaster Tools and SNDS are the only sources that can tell you the receiver’s own verdict. Look at complaint rate first: it is the single number most likely to have moved, and the threshold at which filtering changes is far lower than people expect.
Placement rarely degrades on its own. Something shipped: a new sending domain or subdomain, a volume step change, a list import, a new link-shortening domain, a template with a different image-to-text ratio, a re-engagement campaign to addresses that have ignored you for two years. Line the drop up against your own changelog before theorising about the receiver.
Add controlled mailboxes at the affected provider to the actual campaign and observe the folder directly. This is the only step that converts a hypothesis into an observation, which is why it comes after the cheap checks and before any change of strategy.
Reputation moves slowly and every remedy takes days to show. Changing content, volume and list hygiene in the same week means whatever happens next teaches you nothing. Pick the most likely single cause, change it, and let the next two sends answer.
Two things this product can help with directly along that path. Bounce mix is a genuine leading indicator — a rise in hard_blocked is the receiver telling you something before filtering gets quieter about it, and read a bounce covers how to tell that apart from ordinary list decay. And the segment DSL is how you stop sending to the addresses that are causing the problem, which is usually the fastest real fix available: the segments query language can express “subscribed and opened in the last 90 days” in one line.
What just happened
You can now say precisely what your delivery numbers are evidence of — acceptance by the receiving MTA — and what they are silent about, which is everything that happens to the message afterwards. Real placement has two sources, seed sends and provider postmaster feeds, and neither of them is your event stream. The thing most likely to catch you out is the shape of the failure: placement problems arrive with the delivery chart at 99% and nothing on any dashboard turning red.