Every agent that sends email ends up with an adapter in front of it: a wrapper class, a tool definition, a hand-written schema, and a retry path somebody will get wrong.
That adapter is not product work. It is glue, and it breaks quietly whenever the API on either side of it changes shape.
MiniMailer speaks MCP directly. An agent connects to the server, reads the tool definitions from it, and sends. There is no wrapper to write and nothing to keep in sync when the API grows a field.
The MCP server is in beta and opens to everyone in Q4.
SPF allows 10 DNS lookups. Not 10 records, 10 lookups, and every include, a, mx, ptr and redirect in the chain spends one.
Add a marketing tool, a help desk, a payroll provider and a CRM, and a record that was fine last year now resolves past the limit. The result is a permanent error, and a receiver that treats permerror as a hard fail will reject mail that is otherwise completely legitimate. Nothing in the dashboard changes, because nothing on the sending side broke.
Count the lookups on the live record, not the one in the notes, and drop the includes for services that stopped sending months ago.
A sending domain with 1 include has room to grow. One with 9 is an incident waiting for the next vendor.
An agent that sends email on your behalf is processing personal data, and most email APIs route that through US infrastructure by default.
For a developer in the EU that turns a small integration into a transfer question: which entity, which safeguard, which sub-processor, and whether any of it is written down somewhere a reviewer will accept.
MiniMailer is EU-resident by design, not by region toggle. The sending path and the data it produces stay in the EU, and that was the first architectural decision rather than an enterprise upgrade added later.
The API is in beta and opens to everyone in Q4.
Webhooks bolted on after the send path is why you have a cron job polling for delivery status right now. The events exist, but they were added later, so they cover some states and not others, and you fill the gaps by asking.
MiniMailer's event model came before the send path, not after it. Every state a send reaches is an event, signed, delivered to your endpoint, including the terminal ones you care about most: bounced, complained, suppressed.
Delete the polling job.
A mailbox full is a soft bounce. A mailbox that does not exist is a hard bounce. Plenty of send code treats both the same and retries both, which is how a typo in one signup form turns into a reputation problem.
Receivers score you on how often you mail addresses that were never real. A hard bounce is the receiver telling you the address does not exist, so sending there again is the exact behaviour a spam filter is built to catch. A soft bounce is temporary and says nothing about you.
Suppress on hard bounces, retry soft ones, and never let the same code path handle both.
"Free tier" usually means 60 days. Then the trial ends mid-integration, the card you never handed over gets asked for, and the thing you were halfway through wiring up stops sending.
MiniMailer's free tier is 5,000 emails a month, every month, no credit card. At the limit the API returns 402 and stops. It does not quietly start billing, and it does not expire on day 61.
Build against it for as long as the build takes.