Free SMTP server: what is actually free, and the limits to check

The short version

1. What people mean by a free SMTP server. An SMTP server is the service your application hands a message to so it can be delivered.
2. Option 1: the SMTP of an account you already have. Mailbox providers and web hosts let you send through their SMTP server with your account credentials.
3. Option 2: the free plan of a sending service. A sending service gives you SMTP credentials and an API, a pool of sending IPs it looks after, and tools for bounces and complaints.
4. Option 3: running your own server. Mail server software is free, and it is the option that costs the most in practice.
5. The settings you will need. Whichever you choose, your application needs the same five details: a host name, a port, a security mode, a username and a password.
6. Limits that matter more than the price. Whatever the plan, the main limit is your own sender reputation.

What people mean by a free SMTP server

An SMTP server is the service your application hands a message to so it can be delivered. When people search for a free one they usually want to send password resets, order confirmations or a small newsletter from a website or app without a monthly bill.

Three options exist. You can use the SMTP access that comes with a mailbox or hosting account, use the free plan of a sending service, or install mail software on a server of your own. They solve different problems, so it helps to know which one you need.

Option 1: the SMTP of an account you already have

Mailbox providers and web hosts let you send through their SMTP server with your account credentials. It costs nothing extra and works in minutes, which makes it fine for a contact form that sends a handful of messages a day.

The limits are the catch. Google, for example, documents a daily sending limit per user account, and for Google Workspace it is 2,000 messages per user per day. Personal accounts have lower limits that Google can change. Hosting providers set their own, often per hour, and they may throttle or suspend an account that sends bulk mail.

Option 2: the free plan of a sending service

A sending service gives you SMTP credentials and an API, a pool of sending IPs it looks after, and tools for bounces and complaints. Free plans exist so you can test the service and send low volume.

Read the limits before you rely on one: messages per day and per month, whether you can use your own domain, how many days of logs you keep, and what happens at the limit (messages rejected or queued). Pick a service whose paid plans use the same credentials, so growing does not mean changing your code.

Option 3: running your own server

Mail server software is free, and it is the option that costs the most in practice. A new server and IP have no sending reputation, so providers treat its mail with suspicion. Many hosting and cloud providers block outbound port 25 by default to stop spam, and some will not unblock it.

You also own everything a service would do for you: SPF, DKIM and DMARC records, reverse DNS, TLS, retries, bounce handling, suppression lists and monitoring for blocklists. That can be a reasonable choice for a team with the time and the skill. It is rarely the cheap way to send a few thousand messages.

The settings you will need

Whichever you choose, your application needs the same five details: a host name, a port, a security mode, a username and a password. Use port 587 with STARTTLS or port 465 with implicit TLS, both of which expect you to log in. Port 25 is for server-to-server delivery and is often blocked for ordinary users.

openssl s_client -starttls smtp -connect smtp.example.com:587

Test the connection from the machine that will send before you wire it into the app, and keep the credentials in your environment settings, not in the code.

Limits that matter more than the price

Whatever the plan, the main limit is your own sender reputation. Mail from a new domain that suddenly sends a large volume, or that sends to addresses that do not exist, is filtered whether the server was free or not. Google and Yahoo ask senders to authenticate their domain and to keep complaint rates low.

Set up SPF, DKIM and DMARC for your own domain from the start, send only to people who asked to hear from you, and start at a low volume. Our checker will read your records and tell you what is missing.

How to choose

If you send a few messages a day from a small site, the SMTP of an account you already have is enough. If your application sends mail that matters to your business, such as sign-in codes and receipts, use a sending service from the first day, because the cost of a missing password reset is higher than a plan.

Whatever you pick, make sure you can authenticate your own domain, see why a message bounced, and move up a plan without rewriting anything.

Further reading and sources

• Google Workspace: Gmail sending limits
• Google: Email sender guidelines
• RFC 6409: Message Submission for Mail

Do it in MigoSMTP: help-center articles

• SMTP settings: ports, TLS and authentication
• Verify your sending domain: DNS records and propagation
• Authenticate a sending domain in MigoSMTP: SPF, DKIM and DMARC

Related guides and tools

• SPF record generator: Build the record for your sender.
• What is an SMTP server?: The basics, and how to choose.
• SMTP relay explained: How a relay works.
• Pricing: Compare plans.