Send a Test Email: Confirm Delivery and Placement
Send a Test Email
Sending a test email means delivering a real message to your own or a seed address to confirm it sends, renders correctly, and lands in the inbox before you send to your list.
What a good test send confirms
Three things: it actually sends (no SMTP or auth failure), it renders right across clients (no broken layout or images), and it lands in the inbox rather than spam. Sending to a single address confirms delivery. Sending to a seed set across providers confirms placement.
A test send is the cheapest instrument in deliverability testing, and it sits inside the wider practice of email deliverability, where reputation and authentication decide what a clean-looking message is actually worth.
George, our CEO, keeps a preflight list for exactly this in his Email Marketing Bible, a skill reference built from 908 sources: resolve wrapped CTA URLs, run the spam score, weigh image against text, lint for dark mode, and send a test to a seed address. Resend, Nitrosend and others build versions of that preflight in. If your tool does not, do it yourself. His baseline is simpler still: offer a test send before any real send, every time.
The rendering check matters more than most senders think. George's rule from years of running ecommerce email: Gmail, Yahoo and Outlook cannot read an image, so an image-only email looks like a wall of nothing to the filter and gets filed to promotions or spam. Alt text is how you tell the inbox what the email is about, and a test send is where you catch that you forgot it.
Test to yourself vs seed testing
A test to your own inbox catches obvious breakage but tells you nothing about placement, because your own domain trusts you. Seed testing across inbox placement providers is what reveals whether the wider world sees inbox or spam. Pair it with a spam test email for the score.
This is why I maintain a first-party pool of roughly 20 real seed mailboxes across Gmail, Workspace, Outlook and O365, Yahoo and Apple. They are real accounts, not simulated scores. In our deliverability layer, every verified sending domain resolves to placement results from that pool, so a test send answers the question that matters: where did this land, per provider, right now.
When a seed test comes back badly, work backwards rather than resending. Start by running a domain deliverability check on the sending domain, then a Spamhaus listing check, because a listed domain fails at every provider at once and no amount of copy editing moves it.
If the test never lands anywhere, the failure is at the transport layer instead. Opening a raw SMTP session by hand shows the exact command and response code where the conversation stopped.
Remembering to send a test to yourself, then remembering to check a handful of providers before the real send, is exactly the kind of housekeeping an AI agent should own by default. Tell Claude, ChatGPT or Cursor to send the campaign, and Nitrosend's MCP server runs the test pass first, without anyone having to ask for it.
How Nitrosend handles test sends
The AI agent has separate tools for delivery review and test messages, so a test send is clearly a test and never confused with the real thing. Once DNS setup completes, a real test email goes out automatically to confirm the path.
The same separation matters for transactional email, where a stray test against live order data would mail real customers. Anything driven by an email API should carry an explicit dry-run mode so a test can be proven safe before it is trusted.
The safety rules behind that came out of a real incident. A send once silently ignored an unknown contact_id parameter, so George drafted our campaign-send-safety spec: reject unknown params, require confirm: true on every send so nothing blasts by accident, and give agents a dry_run flag that checks the recipient count before anything goes out.
We hold our own internal tooling to the same bar. When we shipped the seed-demo personaliser worker (nitrosend/api#204), it went out off by default, in a proof mode that delivers only to the operator until explicitly enabled, with a kill switch carrying an auto-disable date and guards re-checked at enqueue, at perform and at pre-send. Test paths stay test paths until you say otherwise.
Test states also should not scream. A working sandbox brand in our app was lighting four simultaneous amber warnings, so we made them neutral (app#135). Sandbox sending is a supported state, not a problem. Only a hard fail blocks sending.
George has watched an early user pattern worth naming here: people do the setup in an AI tool, then switch to the UI for the final big send, because they get nervous and want to push the button themselves. A test send is what makes that handoff safe.
FAQ
How do I send a test email?
Send a real message to your own address or a seed set to confirm it sends, renders correctly, and lands in the inbox before mailing your list.
Why does my test email land in the inbox but real sends go to spam?
Your own domain trusts your mail. Seed testing across other providers reveals the placement real recipients actually see.