Free SMTP server: a relay tier or a sandbox, and what an agent should pick

A free SMTP server is either a cloud relay with a no-cost sending tier or a sandbox server that captures messages without delivering them. The two do different jobs, and the hostname rarely tells you which one you have. An AI agent asked to "add email to this app" often reaches for the first free SMTP host it finds, so it needs to know which of the two it is wiring in before the first real password reset goes out. Use a sandbox while building, a relay tier when real recipients must get mail, and give an agent a sending-scoped key rather than a relay password.

VerifiedBy George Hartley, Co-founder·Updated

Cloud SMTP relays for live sending

A free relay tier gives you authenticated SMTP submission with a monthly or daily send cap. The mail is really delivered, so the tier is limited by volume rather than by capability.

What free tiers actually restrict

Most free tiers restrict the things that cost the provider money or reputation: send volume, the number of verified sending domains, log retention, and whether you can use a dedicated IP. Deliverability itself is usually the same infrastructure the paid customers use.

The restriction that surprises people most is identity. New free accounts usually cannot send from their own domain immediately, because an unverified domain on a brand-new account is the shape of an abusive signup.

Rate limiting on new accounts is standard and is applied on top of the headline cap. A provider that lets a fresh account send its full monthly allowance in an hour is a provider with a spam problem.

What changes when an AI agent picks the free SMTP server

An agent setting up email for an app works from a few search results and a README. With a free SMTP server, that shortcut creates three problems a person doing the setup by hand usually notices.

  1. Password leak. A free relay hands out an SMTP username and password, and an agent wiring them into an app tends to write them into a config file, a test script or its own prompt context. From there they end up in a commit or a log.
  2. Relay or sandbox. A hostname rarely says whether it belongs to a relay or a sandbox, so the agent should check where a test message lands, a real inbox or a capture interface, before it ships the config.
  3. Volume. Free tiers advertise a monthly number, and an agent planning a backfill or a first import reads that number as its budget. On a new account, a daily or rolling limit usually binds well before the monthly headline does.

Nitrosend handles sending through its email API, its MCP server and its CLI, so the agent calls a send tool with a key scoped to sending instead of holding a relay password. The email for Claude guide shows the same setup from inside a coding assistant.

Testing and sandbox servers

A sandbox server accepts SMTP connections and never delivers. Messages are captured and displayed in a web interface so you can inspect headers, rendering and attachments without touching a real inbox.

This is the right tool for development and CI. It removes the risk of sending real mail to real people from a test suite.

Some public catch-all test servers accept anonymous mail on port 25 and publish it to a shared log. Treat those as a demonstration, never as staging: anything you send is readable by anyone, so a message containing a real token, address or password is a disclosure.

Choosing between them

Use a sandbox while building, and a relay tier once you need to know whether real recipients receive the mail. The two answer questions that do not overlap. Nitrosend's tools put one reviewed test send before any real send, as the worked example below shows.

Free relay tier and sandbox server compared
AttributeRelay tierSandbox
Delivers mailYes, to real inboxesNo, captures it for inspection
Limited bySend volume and sender identityCapability, it never delivers
Best forLive sending once real recipients matterDevelopment and CI
Main riskA leaked SMTP password and new-account limitsLeft in production, so real mail never arrives

The setup detail for each lives on the SMTP relay and SMTP server pages, and email relay covers how relaying differs from sending through an API. Other options sit on the transactional email services hub.

Worked example: an agent moves a password reset off a free SMTP relay

A signup app built with an AI coding assistant sends password resets through a free SMTP relay. The relay password sits in an env file, and during development the host pointed at a sandbox.

Prompt: Replace the free SMTP relay in our signup app with Nitrosend and keep password resets working.

Left unguided, an agent swaps the SMTP hostname and password, sends one reset to itself and calls the job done. If the old host was a sandbox, nobody has yet seen a reset reach a real inbox, and the new secret goes into the same env file as the old one.

With Nitrosend, the agent works in this order:

  1. nitro_get_status reads which sender identity the resets will use and whether the account is ready to send.
  2. nitro_manage_domains verifies the app's own sending domain if the team wants resets from it. The step is optional, because the Nitrosend brand subdomain sender works with no DNS.
  3. nitro_manage_template builds the reset email as a reusable template, with the one-time reset link as a field.
  4. nitro_review_delivery checks that reset template before anything goes out: the reset link, the preview and the spam signals. It approves nothing and sends nothing.
  5. nitro_send_test_message sends one real reset, with its live link, to the developer's own address and to nobody else. That address is the test recipient saved with nitro_configure_account.
  6. A person opens that reset, clicks the link, confirms it lands on the right page and approves the switch.
  7. Only then does the app call nitro_send_message through the transactional email API for each reset request, reusing an idempotency_key only when it retries that exact request.
  8. nitro_get_insights then shows whether real resets are delivered and opened once users start requesting them.

Before: an SMTP password in an env file and resets landing in a sandbox nobody watches. After: one reviewed reset template and a tested send.

Where free SMTP goes wrong when an agent sets it up

  • The sandbox host stays in the production config, so the app logs every reset as sent and no real inbox receives one.
  • Real reset tokens go to a public catch-all test server on port 25 during testing, where anyone reading the shared log can use them.
  • The free relay's SMTP password is committed to the repo or pasted into the agent's context, where it outlives the tier it was created for.
  • A bulk import or backfill goes out on day one and hits the new account's rolling 24-hour recipient allowance before the job finishes.
  • A failed reset is retried with a new idempotency key, so the user receives two reset emails with two different links.

Where free actually stops

Nitrosend's Free plan includes 5,000 non-expiring starter emails, plus 500 emails each month, with unlimited stored contacts. The starter allowance is a one-time grant, not a monthly refill. See current pricing for plan allowances and paid options.

A new sender also has a rolling 24-hour recipient allowance. A new Free account starts at 100 and the allowance rises with sender standing, to 500 recipients at Standard and 5,000 at Trusted. That is separate from monthly email credits. Verifying your domain and sending to a clean list raises standing. Paying does not skip these checks. Your account shows its current allowance and any reason sending is held.

You can start with the Nitrosend brand subdomain sender, without setting up custom DNS. Connecting your own sending domain is optional. A team that already pays another provider can connect those provider credentials with nitro_configure_providers.

Go deeper

First send in thirty seconds.

Simple pricing. Unlimited contacts.

Every plan includes full stack emailing: Flows, Newsletter Campaigns and Transactional Email, plus our NitroWheel LLM and all agent integrations (Claude, ChatGPT, Codex, Cursor and others). Pay for what you send, not who you store.

Choose your billing interval

Every paid plan includes 3 agent inboxes and no Nitrosend footer.

Starter

For your first email program.

$16USD / month

$192 billed yearly.

20,000 emails / month

Choose Starter
  • 5 brands · 3 seats
  • 5 custom sending domains
  • 500 email verifications/month
  • $1.50 / 1,000 extra emails

Pro

For a growing audience.

$40USD / month

$480 billed yearly.

60,000 emails / month

Choose Pro
  • 10 brands · 5 seats
  • 10 custom sending domains
  • 1,000 email verifications/month
  • $1.20 / 1,000 extra emails

Growth

For teams and agencies.

$120USD / month

$1,440 billed yearly.

200,000 emails / month

Choose Growth
  • Unlimited brands · 10 seats
  • 25 custom sending domains
  • 2,500 email verifications/month
  • $0.90 / 1,000 extra emails

Scale

For high-volume sending.

$240USD / month

$2,880 billed yearly.

500,000 emails / month

Choose Scale
  • Unlimited brands · 20 seats
  • 100 custom sending domains
  • 5,000 email verifications/month
  • $0.70 / 1,000 extra emails
Enterprise

Hey, big sender.

Sending 500,000+ emails a month? Get a custom plan designed for you, with volume email pricing and capacity that fits your business.

Start free. No card needed.

5,000 emails to start, then 500 emails every month. No expiry on your starter emails.

Start free

Daily allowances depend on your plan and sender standing. Strong list, domain and delivery evidence can raise standing, including on day one. Trusted receives the full plan allowance; available email credits, safety checks and delivery pacing still apply.

Free forever. No credit card required. See full comparison →