AI-Agent-Email-List

# 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](#for-ai-agents-start-here), a Mailgun-shaped REST API, DKIM signing,
automatic sending warmup and inbound mail.

Live at **[ai.agentemaillist.com](https://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:

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

### The tools

| Tool | Does | Needs a key |
| --- | --- | --- |
| `create_account` | Open an account, get an API key | **No** |
| `add_domain` | Register a sending domain, get its DNS records | Yes |
| `verify_domain` | Re-read DNS and activate the domain | Yes |
| `send_email` | Send a message, with a test mode that costs nothing | Yes |
| `list_domains` | Domains and how much each can send today | Yes |
| `get_sending_limits` | Today's cap and what graduates it | Yes |
| `list_messages` | Sent and received mail | Yes |
| `get_delivery_events` | What actually happened to a message | Yes |

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

| Limit | Figure |
| --- | --- |
| Accounts per IP address | 5 an hour, 20 a day |
| Domains per account | 3, rising to 50 once any one of them is verified |
| API requests per account | 600 a minute — a pace limit, not a sending limit |
| Sending per domain | starts at 10 a day and climbs the warmup ladder |
| Screening refusals | sending pauses at 8 in 24 hours, and lifts by itself |

`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.

```bash
# 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](https://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](https://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

| | This | Mailgun | SendGrid | Amazon SES |
| --- | --- | --- | --- | --- |
| An agent can sign up alone | **Yes** | No | No | No |
| MCP server | **Yes** | No | No | No |
| Free tier | **Free, no clock** | Limited | Trial, then paid | Pay per message |
| Inbound mail | **Yes** | Yes | Yes | Via S3 |
| Self-hostable | **Yes** | No | No | No |

A longer comparison, including Brevo, Resend and SMTP2GO, is at
[ai.agentemaillist.com/free-smtp-relay](https://ai.agentemaillist.com/free-smtp-relay).

## Self-hosting

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

```bash
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](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

```bash
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:

```bash
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:

```bash
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:

```bash
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](DEPLOY.md) explains every step it takes:

```bash
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:

```bash
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:

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

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

### A note on PGDATABASE

Host, user and password are read from the environment. The database name is
not. It is not a credential, it is which application's data this is, and
`PGDATABASE` is a standard libpq variable that may already be exported on a
shared box for some other service. Honouring it would point `mix ecto.migrate`
at that s