Three tests, three different questions
Deliverability testing is not one activity. There are three distinct layers, they answer different questions, and running the cheapest one tells you almost nothing about the others.
Transport testing asks whether the receiving server can be reached and will accept the message. Content and authentication scoring asks whether filters will find anything objectionable. Placement testing asks the only question anyone actually cares about: where does the message land.
What each layer covers
The order matters because each layer is cheap and fast relative to the one above it, and failures at the bottom make the layers above meaningless. There is no point measuring placement if the MTA is refusing the connection.
The test stack
what each layer proves, and where it stopsThat last row is the one people miss. A 10 out of 10 content score and a spam-folder placement are entirely compatible outcomes, because content is only one input and reputation outweighs it.
Testing before the send, automatically
My view is that the test should not be a separate thing you remember to do. We run preflight checks before sending, with dry-run validation covering domain verification and sender configuration, so a misconfigured send is caught at composition rather than after it has gone out.
George's version of this is a product principle rather than an engineering one: offer a test send before any real send, every time. If you end a prompt with "and send me a test email", you get a finished, branded message in your own inbox before anything reaches a list. Claude can generate a preview link and fire a test to a test account in the same step.
The sandbox exists for the same reason. Our free tier includes a sandbox mode that tracks remaining test sends, so you can exercise the whole path without touching a real recipient. Chong caught a genuine bug in this area worth mentioning, where the test send fired before the email had finished saving, which is exactly the class of thing a preflight is supposed to prevent.
Showing the limits, not hiding them
One thing I care about in how we built this: the system shows the whole sending machine and every limit on it, measured through the same doors a user would use. Every new account runs an automated content check with hourly and daily limits while it builds a sending reputation, and those limits are visible rather than silent.
Silent throttling is the worst possible experience, because the sender sees a successful send and no mail arriving, and has no way to connect the two. If a limit is applied, it should be legible.
Test in the right order and act on what you find: fix authentication if layer two flags it, check blacklist status if transport fails outright, and measure real inbox placement rather than stopping at a content score.
If the failure is at layer one, the transport itself, the SMTP dialogue is where to look, and SMTP ports covers which port and encryption combination the receiver expects. Application mail deserves the same preflight discipline as campaigns, which is the argument on transactional email best practices.
Go deeper
References
The primary sources behind the rules on this page. Provider policy and the underlying standards, not vendor marketing.
Common questions
Use three layers: an SMTP transport test, a content and authentication score, and a seed inbox test. Only the third one tells you where mail actually lands.
Above 9 out of 10. But a high score only means your content and authentication are clean, it does not mean you will reach the primary inbox.
Yes. A test send costs nothing and catches broken links, unrendered variables and authentication regressions before they reach a real list.