How to test email deliverability (placement tests + seed lists)

Testing deliverability means answering three separate questions with three separate instruments, and most teams conflate them. Where did the message land? A seed placement test is the only thing that sees a folder. How does the receiver rate you? Google Postmaster Tools, for authenticated traffic above a volume Google will not publish. Did authentication pass? The Authentication-Results header on one message you send to yourself, which costs nothing and catches the majority of real faults. An open rate answers none of these.

Three instruments, three questions, and the one that answers yours

Start by naming the question, because every instrument below is useless against the wrong one.

• "Which folder did it reach?" Only an inbox placement test observes this. Nothing in the SMTP conversation reports the folder decision back to the sender, and no analytics dashboard infers it reliably.
• "How does this receiver currently rate my domain?" Google Postmaster Tools, if your volume clears its threshold. Microsoft offers the equivalent only to whoever owns the sending IP.
• "Did SPF, DKIM and DMARC pass, and did they pass for my domain?" The Authentication-Results header, specified in RFC 8601, on a single message sent to a mailbox you control.

Notice that acceptance is on none of those lists. A 250 reply at the end of the SMTP transaction, defined in RFC 5321, means the receiving server has taken responsibility for the message. The folder decision happens afterwards, in a filtering system that does not report back. This is why a delivery rate of 99% can sit above a campaign that produced nothing.

How an inbox placement test actually runs, phase by phase

The mechanism is worth knowing because it explains every limitation the result carries. A placement test has two phases that must be separated in time, since a message has to arrive before anyone can look for it.

Phase one, dispatch. The system takes the real subject and body you want to test, appends a short unique token to the subject line, and sends that message from the source mailbox to every active seed inbox. Autocloz generates the token as a random hex string prefixed spct-, stores it against the run, and marks the run running. The token exists so that phase two can find this specific test among whatever else is sitting in the seed mailbox.

Phase two, scoring. After a delay — Autocloz waits 15 minutes — the scorer connects to each seed over IMAP, selects INBOX read-only, and issues SEARCH SUBJECT "". A hit means inbox. No hit, and it selects the seed's configured junk folder and searches again; a hit there means spam. No hit in either means missing. The results roll up per provider and the score is the percentage of seeds that landed in the inbox.

Three details follow directly from that mechanism. The junk folder name is provider-specific and has to be configured per seed — [Gmail]/Spam, Junk Email, Bulk Mail — and a wrong folder name turns every spam placement into a "missing". A seed that fails to answer IMAP is recorded as missing rather than crashing the run, so infrastructure noise inflates the missing count. And a run with no registered seed mailboxes fails immediately with the reason no active seed mailboxes registered, which is the correct behaviour and a surprise to anyone expecting a shipped seed list.

Why your seed test cannot see the Promotions tab

This is the limitation that most often makes a placement number look better than reality, and it is a protocol fact rather than a product gap.

Google's IMAP extensions documentation lists the special-use folders Gmail exposes: INBOX, [Gmail]/All Mail, [Gmail]/Drafts, [Gmail]/Important, [Gmail]/Sent Mail, [Gmail]/Spam, [Gmail]/Starred and [Gmail]/Trash, plus user-created labels as ordinary folders. The inbox category tabs — Promotions, Social, Updates, Forums — are not folders. A message categorised into Promotions is still in INBOX as far as IMAP is concerned, so a SEARCH against INBOX finds it and reports inbox.

The only way to ask the question over IMAP is Gmail's proprietary extension X-GM-RAW, which Google documents as passing the full Gmail search syntax through, as in a005 SEARCH X-GM-RAW "has:attachment in:unread". A category query would take the same shape with category:promotions. That is a Gmail-specific capability, so a test built on it works for Gmail seeds and has no equivalent on Outlook or Yahoo.

Be honest with yourself about what a three-bucket result means. Inbox, spam, missing is a real measurement of a real thing. It is not the same measurement as "a human saw this in their primary tab", and a drift into Promotions is invisible to it.

The bigger limitation: a seed mailbox has no engagement history

Every provider's filter weighs signals specific to the relationship between you and that recipient. Whether they have replied to you. Whether they have moved your mail out of spam before. Whether they open messages from this domain. A seed mailbox has none of that history with your domain by construction, and it never will, because nobody reads it.

That has two consequences worth stating plainly rather than burying.

First, a seed result is not a prediction for a real recipient. It is a measurement of how a filter treats your message when the recipient relationship contributes nothing. That is a genuinely useful baseline — it isolates the message and the sending identity from the relationship — but it is a floor, not an average.

Second, seed results are only comparable to themselves. Comparing your inbox percentage to a figure published by a deliverability vendor is comparing two different seed populations, two different message bodies and two different weeks. Compare a run to your previous run, with one variable changed. That is the only comparison the instrument supports.

Autocloz's free plan covers 5 users and 10 mailboxes with on-demand placement runs and SPF, DKIM and DMARC monitoring included — start free if you would rather watch the placement number than the acceptance number.

Google Postmaster Tools: eight dashboards, and the ones that stay empty

Postmaster Tools requires you to verify the sending domain by DNS, after which Google publishes eight dashboards: Compliance status, Spam rate, IP reputation, Domain reputation, Feedback loop, Authentication, Encryption and Delivery errors.

Two of them carry the numbers people actually act on.

Domain reputation and IP reputation use the same four-band scale, and Google's definitions are specific enough to quote. High is "History of very low spam rates, and complies with Gmail's sender guidelines". Medium is "History of sending legitimate email, but occasionally sends spam". Low is "History of sending a significant volume of spam regularly". Bad is "History of sending a high volume of spam regularly", with mail "almost always marked as spam or rejected".

Spam rate is the percentage of your messages "delivered to engaged recipient's Inbox and then marked as spam by the recipient". Google's sender guidelines ask bulk senders to keep it "below 0.30%" and, as a target, "below 0.10%". One qualifier changes how you read it: Postmaster Tools displays the spam rate of DKIM-authenticated messages only. Unsigned mail does not appear, so a domain with broken DKIM can show a flattering spam rate over a tiny denominator.

The dashboard's real problem for cold outreach is volume. Google states data "might be missing if the total number of messages for a given day is too low" and does not publish the threshold. A programme sending a few hundred messages a day may never populate it, which means the instrument is least available exactly where it would be most useful. Set it up anyway — it costs one TXT record — but do not build a testing routine that depends on it.

Microsoft's instruments, and the one you cannot have

Microsoft's equivalent is Smart Network Data Services, and for most cold senders it is unavailable for a structural reason rather than a policy one.

SNDS grants access per IP range, and it proves entitlement by ownership. Microsoft verifies against reverse DNS, RDAP and the global routing table, then emails an authorisation link to a contact registered against that range — typically abuse@ or postmaster@ at the registrant's domain. Click the link, get the data.

If you send through Microsoft 365, Google Workspace or any shared relay, the outbound addresses are registered to that provider. The authorisation email goes to them. You cannot request data for an IP you do not own, and the signup process is fully automated with no manual route around it. So IP-level reputation is not merely hard to see from a shared provider — it is not yours to see, and it is not yours to change either. That asymmetry is the core of the shared versus dedicated IP decision.

What remains available is Microsoft's Junk Mail Reporting Program feedback loop, which also keys on IP ownership, and the ordinary evidence of rejection: the bounce text. Microsoft is unusually explicit in its rejections, and 550 5.7.515 Access denied, sending domain does not meet the required authentication level tells you more about your DNS than a dashboard would.

The test that costs nothing: read your own headers

Before any of the above, send one message from your sending mailbox to a mailbox you control on a different provider, open it, and read the raw source. In Gmail that is Show original; in Outlook, View message source.

The Authentication-Results header is the receiving server stating its conclusions. You want three things.

• spf=pass — and check which domain it passed for. The header names it.
• dkim=pass — and check the header.d= value. That is the domain that signed, and it is frequently your sending platform rather than you.
• dmarc=pass with header.from= your own domain.

The failure worth learning on sight is dmarc=fail on a message that shows spf=pass. Something authenticated; it was not your From domain. That is an alignment failure, and it is the single most common reason a technically correct setup fails DMARC. The SPF and DMARC record checker reads the DNS side of this without a terminal, and what Gmail and Outlook each reward covers why the same message can pass one and fail the other.

A testing routine that produces a number you can act on

Sequence matters, because a placement test run against broken authentication measures the authentication, not the message.

1. Authentication first. dig TXT yourdomain.com, dig TXT _dmarc.yourdomain.com, dig TXT selector._domainkey.yourdomain.com, then one message to yourself and read Authentication-Results. Fix everything red before you continue.
2. Register seeds across the providers your list actually contains. If 70% of your prospects are on Microsoft 365, a seed list that is 70% Gmail is measuring the wrong receiver.
3. Run the placement test with the real body. A test using lorem ipsum measures a message you will never send. Use the template, the links and the signature you intend to ship.
4. Record the source mailbox, the date and the exact body. A placement score without those three is not comparable to anything.
5. Change one variable and re-run. New template, or new domain, or a completed ramp — one of them.
6. Re-test on a cadence, not only before launch. Placement drifts, so a single pre-launch score decays into a claim about a week that has passed. Put a recurring reminder against it rather than trusting that nothing changed.

Two things not to do. Do not treat a rising open rate as evidence of improved placement — Apple Mail Privacy Protection and Gmail's image proxy both fetch tracking pixels without a human involved, and why an open rate stopped measuring opens is worth understanding before you build any decision on one. And do not run a placement test as a substitute for volume discipline: a good score on a mailbox that is about to triple its daily send tells you about today, not about next week, which is the argument in the mailbox warmup myth.

What a placement test cannot tell you, and what Autocloz does not do

A placement test reports where probes landed. It does not report why. No provider exposes the reasoning, and any tool that claims to know which of your subject lines triggered a filter is guessing.

It cannot see personalised filtering. Two real recipients on the same provider can get different outcomes for the same message based on their own history, and a seed sees neither of theirs.

It has no equivalent for the Gmail category tabs on any provider except Gmail, and even there it needs a Gmail-specific search extension rather than the IMAP standard.

And Autocloz specifically. It does not ship a seed list. Every seed mailbox is one you register yourself, with its own IMAP host, port, username, encrypted password and junk folder name; a shared platform seed pool exists in the data model as a nullable owner and is not populated today, so a workspace with no seeds gets a failed run rather than a borrowed one. It classifies into three buckets — inbox, spam, missing — with no Promotions bucket, for the protocol reason above. It does not schedule placement tests for you. A run is queued by an operator, rate-limited to twenty an hour, and a background worker advances pending and running tests every five minutes; there is no recurring weekly job, so a cadence is something you have to keep, alongside the mailbox warmup ramp that does run on its own. It reads seeds over IMAP, which means a seed provider that blocks IMAP or requires an app password you have not created reports missing rather than a placement. It cannot see inside Gmail's or Microsoft's classifiers, and the seed result measures the outcome rather than the reasoning. And connecting a mailbox through Gmail and Google Workspace gives Autocloz no more visibility into Google's filtering than you have — the API surface simply does not expose it.