Send a test email: confirm delivery and placement, and what changes when an agent sends the test

What sending a test email means

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.

When an AI agent wrote the email, through a coding assistant or over MCP, the test is the first time a person sees it, so it doubles as the review. The agent also runs unattended and can repeat a step without being asked, so the test has to be plainly a test, sent to the right inbox, and never a quiet first send to the list.

The quickest way to start: end the prompt to Claude, ChatGPT or Cursor with "send me a test email", so the first result of any change lands in your inbox before anything else happens.

What changes when an AI agent sends the test

In short: the agent reviews the email first, sends the test as its own call, and a sent test is never approval.

A person sending a test clicks a button and looks at their own inbox. An agent sending a test makes tool calls, and the calls decide what gets checked and where the message goes. With the Nitrosend MCP tools, the first call is nitro_review_delivery on the email. That call is read-only. It validates the content, checks readiness, runs spam analysis and preflight, and returns previews, and it never approves or sends anything.

Only then does the test go out, as its own call. nitro_send_test_message delivers one real email for a template, a campaign or an exact flow revision, and it never sends to an audience. The inbox it lands in comes from the test recipients kept in the account settings, which are managed with nitro_configure_account, so the destination is decided before the agent starts. Reviewing first means the copy in the inbox is the version that already passed the checks.

The rule that matters most: "test sent" is not approval. A test proves one copy reached one inbox. It does not prove a person read it. A workable line is that tests to the person's own addresses need no extra yes, and any send to more than one recipient waits for an explicit "send it". The same applies to the setup that pairs with this page, sending email from an LLM, where the model drafts and a person signs off.

What a good test send confirms

Three things:

• It sends. No SMTP or auth failure.
• It renders. No broken layout or images across clients.
• It lands in the inbox. Not in spam.

Sending to a single address confirms delivery. Sending to a seed set across providers confirms placement.

A test send is the quickest check in deliverability testing. It will not fix a sender reputation or authentication problem, which the email deliverability guide covers.

George Hartley, Co-founder of Nitrosend, keeps a preflight list for exactly this in his Email Marketing Bible skill:

• Resolve wrapped button links.
• Run the spam score.
• Weigh image against text.
• Lint for dark mode.
• 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. The image-against-text check is one a test send makes visible: an image-only layout or missing alt text shows up the moment a person opens the copy.

Test to yourself vs seed testing

A test to your own inbox catches obvious breakage, but one address confirms delivery at one provider, not placement. 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, or a mail tester report for the headers.

A warm-up score does not answer the placement question either. Warm-up scores measure warm-up mail, not campaigns, so a mailbox can score 99 while its campaigns land in spam. Confirm with a seed placement test before launch and again each month.

When a seed test comes back badly, work backwards rather than resending:

1. Run a domain deliverability check on the sending domain.
2. Run a Spamhaus listing check, because a listed domain fails at every provider at once and no amount of copy editing moves it.
3. If the test reached the spam folder, the test email went to spam guide walks the causes in order.
4. If the test never lands anywhere, the failure is at the transport layer. An SMTP test checks the connection, and a raw SMTP session by hand shows the exact command and response code where the conversation stopped.

How Nitrosend handles test sends

The AI agent has separate tools for delivery review and test messages, so a test send is always its own call, separate from the real send. Each step of a test pass is a different call:

• nitro_review_delivery checks one saved template, campaign or flow, or a piece of inline email content, and reports what would fail. It changes nothing.
• nitro_send_test_message puts one real copy in the test inbox. It is the only call in the pass that delivers mail, and it never reaches the list.
• nitro_configure_account holds the sender defaults and the test recipients, so the team decides once where tests go.
• nitro_compose_campaign and nitro_compose_flow create drafts. Neither delivers or activates anything, so an agent can build and test a broadcast or a sequence without either step putting it live.
• nitro_control_delivery is the separate step that approves, schedules or starts a campaign or flow, after a person has read the test.

Safe mode is on by default. An agent can get all the way to a finished draft and put tests in your inbox, but a bulk send needs the final confirm in the Nitrosend UI, not from the agent.

The same separation matters for transactional email, where a stray test against live order data would mail real customers. Over the email API, nitro_review_delivery can also review inline email content without sending it. In code, the transactional email API sends one message per call, so a test there is a single send to an address the team owns.

A test pass is a handful of sends, so it will not eat into the daily allowance on any plan. The tiers are on the pricing page.

Worked example: an agent tests a receipt before launch

The prompt: "Send me a test of the new receipt with a real order filled in."

Before. Left unguided, an agent takes "a real order" literally. It pulls the most recent order from the database and sends the new receipt to the address on it, so a customer gets a second receipt for something they already paid for. Or it invents a name, an order number and a total, and the test looks perfect while a broken line-item field goes unseen.

After. With the Nitrosend MCP tools, the agent makes these calls in order:

1. nitro_get_status confirms the account is ready and shows which sender identity the receipt goes out from.
2. nitro_manage_template edits the receipt template, putting the order number, the line items and the total into the new layout as merge fields.
3. nitro_review_delivery checks the edited receipt before anyone opens it: validation, spam analysis, preflight and previews. Nothing is sent.
4. nitro_send_test_message puts one real copy of the edited receipt in the team's test inbox, the address the account keeps for tests. No customer is on it.
5. The person who asked opens the test on a desktop client and on a phone, checks the merge fields, the total, the links and the images, and says yes.
6. The app then sends the new receipt for real orders through nitro_send_message, with one idempotency_key per order so a retried order never gets two receipts.
7. After launch, nitro_get_insights reports email analytics for the receipt with trends, benchmarks and recommendations.

The difference in one line: before, the first person to read the new receipt is a customer who already paid. After, it is the person who asked for it, on two screens.

Where it goes wrong when an agent sends test emails

• A "test" sent to the real list. Told to "send a test of the newsletter", an agent reaches for the campaign path and tries to schedule the draft instead of testing it. Safe mode stops that bulk send at the confirm in the UI, and a test should only ever be nitro_send_test_message, which never sends to an audience.
• A test to a customer's address. A model that has just read an order record or a support thread picks up the customer's email and uses it as the test address. Tests belong at the team's own or seed addresses, set once on the account.
• Made-up data that looks real. An invented name, order and total fill the template neatly, so a merge field that breaks on a long product name or a second currency never shows. Fill tests from a sample record with the same shape as live data.
• Tests repeated until the seed inbox stops trusting them. An agent that resends after every small edit puts dozens of near-identical messages into the same seed mailboxes, and the placement result stops saying much about the real send. Group the edits, review, then test once per change.
• A passing test read as approval. "Test sent" means one copy reached one inbox. Any send to more than one recipient still waits for an explicit "send it" from a person.
• The agent's own report taken as proof. An agent's summary of what it sent is not evidence. Check the send record in the account before trusting that a test went only where it was meant to.

FAQ

Go deeper