Mailgun

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Do not build this. Relationships with inbox providers are the product, and there is no substitute.

Running your own mail server to send application email means a clean address, reverse DNS, warmed reputation, feedback loops with each large provider, and constant attention. Do it badly and password resets stop arriving, which is an outage you cannot see from your own side.

WHAT TO DO INSTEAD
- Keep a relay. Compare providers on price at your volume — they differ by a lot — and on whether they give you the bounce and complaint feedback you need
- Never send application mail from your own server for the sake of it. This is one of the few places where self-hosting is straightforwardly worse

WHAT YOU MUST DO REGARDLESS, AND MOST PEOPLE DO NOT
- **SPF, DKIM and DMARC** on your sending domain, with DMARC actually enforcing rather than sitting at none. Read the aggregate reports; they tell you who is sending as you
- **A separate subdomain for transactional and marketing mail.** A password reset that fails because a campaign got complaints is a support disaster, and sharing a domain is how that happens
- Warm a new domain slowly: hundreds, doubling over weeks
- Consume bounces and complaints and act on them: a hard bounce suppresses immediately, a complaint suppresses permanently and is never mailed again
- One-click unsubscribe and the List-Unsubscribe headers on anything bulk, which the large providers now effectively require
- Watch the complaint rate daily. Above a fraction of a percent an account gets suspended, and that is the failure that ends everything

WHAT TO BUILD
- **A local mail catcher for development**, so nothing reaches a real person by accident and nobody needs a provider account to work. That is under Mailtrap elsewhere in this catalogue, it is a weekend, and it removes a whole class of embarrassing mistakes
- A thin sending module in your own code: one delivery row per recipient per message, written before sending, idempotent, with the provider's message id recorded. That makes a resume exact and lets you change provider by rewriting one file

THE ONE-LINE VERSION
Rent the relay, always. Build the development catcher and a sending layer thin enough to swap.