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.
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.
What free tiers actually restrict
The restriction that surprises people is not volume, it 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.
We have been on the receiving end of this policing ourselves. When Mailgun sandboxed an account we ran, the notice Kam, our co-founder, posted read: the account is on probation, domains are limited to 100 messages an hour, and the account has been temporarily disabled to maintain the rate. Every serious provider polices this layer, and a free tier that does not is one to avoid.
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, which is a failure every team makes exactly once.
Public catch-all test servers exist too, accepting anonymous mail on port 25 and publishing 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. My product rule is the same idea in one line: offer a test send before any real send.
Where free actually stops
Free tiers on sending platforms usually have two limits stacked on top of each other, and confusing them is the most common reason someone thinks they have been cut off early.
The first is a sandbox. Before a domain is verified, sending happens from a shared platform domain to verified addresses only, and it is capped low deliberately. Ours allows 50 sends a month in that state, and the same cap applies to paid accounts that have not yet verified a domain. It exists to let you test the integration, not to run anything. The counter is visible the whole way, a status like 50/50 sandbox sends remaining, so you know exactly where you stand before anything blocks.
We found the sharpest edge of this by dogfooding it. In one of our own test runs the safety block landed around the eighth test email and there was no obvious way to fix it or to flag that we were not a spammer. Opaque safety blocks are the worst part of free tiers everywhere, ours included, which is why the sandbox counter and the block reasons are surfaced now.
The second is the actual plan limit, which unlocks once a domain is verified. On our free plan that is 8,000 emails and then 500 a month, with unlimited contacts, because charging for stored contacts rather than sent messages never made sense to me.
Verification is not reputation. A brand-new sending domain with no history often sees its first sends to Gmail, or even to your own mail server, land in spam or get greylisted, and that settles as the domain warms up.
The free plan carries both transactional and marketing email with no dashboard required, because the whole platform drives from your agent or the API. I have sent 6 billion emails across my last two SaaS companies, and this tier is shaped by what that scale teaches you.
Not everyone on the team loves free plans. Nick, whose SmartrMail years overlapped mine, wants to avoid them as much as possible because of what free accounts attract. We kept ours anyway and put the controls above around it.
The distinction matters because the two failure modes look identical from the outside. Mail stops going out and the dashboard says you are over a limit. One is fixed in about a minute by verifying a domain. The other means you have genuinely outgrown the tier.
Free tiers and sandbox servers are still something a person has to shop for and babysit. The honest fix for most of what a free SMTP server gets used for is not a bigger free tier, it is an AI agent that sends the email for you and does not care what the underlying send limit is, because it is managing the whole relationship. That is the shift Nitrosend was built for: describe the email inside an agent like Claude or ChatGPT, and it sends, on your brand, without you ever comparing free-tier caps again.
Free stops being viable at the point where the mail matters more than the cost. A password reset that does not arrive costs more than the sending did, and the sandbox in particular is not built for anything a customer depends on, since it sends from a shared domain whose reputation you neither control nor benefit from. And a free relay tier is not cold-outreach infrastructure. Cold is its own world: different domains, different mailboxes, different volumes, different deliverability rules.