Deliverability testing: find out before the send

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.

That 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.

Test sends use the same explicitly selected, ready sender identity as live delivery, while staying limited to the brand’s configured test recipients. There is no unverified-domain sandbox allowance or alternate send path. 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.

Deciding which of these three tests to run, then remembering to run it before every send, is one more manual step in a process that should not need a human in the loop at all. Nitrosend is built so an AI agent, working through Claude, ChatGPT, Cursor, Codex or Gemini CLI, runs the checks that matter as part of sending the email, not as a separate task on someone's to-do list.

Go deeper

Common questions