Free SMTP Relay and Email API for AI Agents

An email service an AI agent can sign up for on its own. No credit card, no sales call, no human with a corporate account. Free, with an MCP server, a Mailgun-shaped REST API, DKIM signing, automatic sending warmup and inbound mail.

Live at ai.agentemaillist.com · Source available · Built in Elixir and Phoenix

For AI agents: start here

This is a remote MCP server. Add it and the whole service arrives as tools:

https://ai.agentemaillist.com/mcp

JSON-RPC 2.0 over HTTP POST. The important part:

create_account needs no credentials. An agent that has just found this server can call it, get an API key back, and start sending. Every other transactional email provider stops an agent at a payment form or an identity check. This one does not.

See what is available before committing to anything:

curl -X POST https://ai.agentemaillist.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The tools

Send the key as Authorization: Bearer <key> on every call after the first.

Two things that will stop you

A domain must be verified in DNS before it can send. Publishing DNS usually needs a human with registrar access, so start it early. Until then every send returns a refusal explaining exactly that.

A newly verified domain starts at 10 messages a day and climbs as it proves itself, because a domain that opens at full volume gets filtered by receivers. Call get_sending_limits before planning a bulk send rather than finding out part way through.

Use test_mode: true on your first send. It runs the whole pipeline, screening included, sends nothing, and spends none of the daily allowance.

The limits, so you never meet one by surprise

get_sending_limits reports all of these live, with no domain argument needed. Every 429 carries a Retry-After. Opening a second account does not get you more: accounts are limited by address, so both come out of one budget.

For developers: the REST API

Mailgun-shaped, so most Mailgun client libraries work against it unchanged by pointing at a different base URL.

# An account and an API key, in one request
curl -X POST https://ai.agentemaillist.com/v1/accounts \
  -d 'email=you@company.com' -d 'password=a sufficiently long password'

# Send
curl -X POST https://ai.agentemaillist.com/v3/yourdomain.com/messages \
  --user 'api:YOUR_KEY' \
  -F from='you@yourdomain.com' \
  -F to=someone@example.com \
  -F subject='Hello' \
  -F text='Hello there.'

Full API reference, written for machines to read: ai.agentemaillist.com/llms.txt. Its sending limits are generated from the running service, so they are the limits you will actually meet rather than a number written down once.

There is also a web console at ai.agentemaillist.com/signup for setting up a domain by hand.

What it does

• Free SMTP relay and email API. No trial clock, no card.
• Send over SMTP or REST. Adding a domain issues SMTP credentials; the REST API is Mailgun-shaped.
• Receive mail too. A real SMTP server on port 25, with inbound routing to your webhook. Not just sending.
• DKIM signing, RSA-SHA256 with relaxed canonicalisation, and a keypair minted per domain.
• Automatic sending warmup, a published ladder from 10 a day to unlimited, so a new domain builds reputation instead of being filtered.
• Content screening in both directions, refusing outbound and filing inbound as spam.
• Delivery events for every message, plus signed webhooks.
• Limits that open as you prove yourself, rather than a flat cap: verifying a domain is what buys headroom, because it is the one thing a throwaway account cannot fake at scale.

Compared to the alternatives

A longer comparison, including Brevo, Resend and SMTP2GO, is at ai.agentemaillist.com/free-smtp-relay.

Self-hosting

It is one Phoenix application and a Postgres database. One command deploys it:

sudo bash deploy/deploy.sh --domain mail.yourcompany.com --email you@company.com

That installs Postgres and nginx, builds a release, issues a TLS certificate, and sets up systemd and the firewall. DEPLOY.md explains every step it takes and what to do when one fails.

Licence

Currently unlicensed, which means all rights reserved. If you want to use or contribute to this, say so and a licence will be added.

Maintained by Logan Besecker. Questions, bug reports and cold outreach all welcome at me@LoganBesecker.com or lbesecker195@gmail.com.

Running and operating it

Everything below is for someone running their own copy.

Running it

mix setup            # deps, database, migrations
mix phx.server       # http://localhost:4005
mix test

It listens on 4005 by default, because 4000 through 4003 are taken on the machines this runs alongside. PORT overrides it.

Database

Set credentials once, in .env at the project root:

cp .env.example .env

Every mix command reads it, so nothing has to be retyped per command, and a real environment variable still overrides it: DATABASE_URL=... mix test does what it looks like. .env is gitignored; .env.example lists everything that can go in it.

Without that file, DATABASE_URL wins if it is set, which is the form that works everywhere:

DATABASE_URL=ecto://user:pass@localhost/email_provider_dev mix setup

Otherwise the standard PGUSER, PGPASSWORD, PGHOST, PGPORT and PGDATABASE variables, and only then a guess at a role named after the OS user, which is what a stock Homebrew Postgres gives you.

The guess skips the OS user when that user is root. On a server you are often root, there is rarely a Postgres role called root, and the error you get back — password authentication failed for user "root" — reads like a credentials problem when really nobody has said which credentials to use. If you hit that on a fresh box, either set DATABASE_URL or create the role:

sudo -u postgres psql -c "CREATE ROLE youruser LOGIN PASSWORD 'apassword' CREATEDB;"

On a real deployment, run the release with MIX_ENV=prod and DATABASE_URL rather than mix setup, which is a development task. One command does the whole thing, and DEPLOY.md explains every step it takes:

sudo bash deploy/deploy.sh --domain ai.agentemaillist.com --email you@example.com

On a machine that is running other things

mix setup is a developer command and it is not a good neighbour. Use this instead:

DATABASE_URL=ecto://user:pass@localhost/email_provider_dev bin/setup-server

Three differences, each of which is a way mix setup can disturb something else on the box.

It caps the build. Compiling 35 dependencies and two C NIFs fans the Elixir compiler out to one process per scheduler and make to one job per core, which on a small VPS makes the build the largest memory consumer on the machine. When memory runs out the kernel does not kill the build; the OOM killer picks the biggest process, which is usually a running application. The script serialises compilation and, under systemd as root, runs it inside a scope with a hard MemoryMax, so anything killed for memory is the build itself. Override with MEMORY_MAX=1G.

It opens two connections, not ten. Postgres has a fixed max_connections, and one that runs out answers every client with "sorry, too many clients already", including services that were already connected. The dev pool now defaults to 5 and reads POOL_SIZE; the script sets it to 2.

It never starts the application. mix setup boots the whole supervision tree to run priv/repo/seeds.exs, which opens a pool and starts the delivery queue. mix setup.server creates and migrates without booting anything.

If something already went offline during a mix setup, these say which of the two it was:

sudo dmesg -T | grep -i -A2 'killed process'

sudo grep -i "too many clients" /var/log/postgresql/*.log | tail

A note on PGDATABASE