Mailjet

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 an email sending service. This entry explains why and what to build instead.

**Deliverability is reputation, and reputation is time.** A new IP address and a new domain start with no standing at every mailbox provider. Sending a few thousand messages from a fresh server puts most of them in spam or nowhere, and no amount of correct code changes that in the first months.

The correct answer is to **rent the sending and own everything else.** Use a delivery provider for the SMTP relay — that part is cheap — and build the layer above it, which is where the money and the lock-in actually are.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A relay provider for delivery only
- MJML for templates
- Caddy in front

WHAT TO BUILD
- templates: id, name, mjml, version, updated_at — **versioned, so a change does not rewrite what was already sent**
- messages: id, template_id, template_version, to_hash, subject, payload_json, provider_ref, status, queued_at, sent_at
- events: id, message_id, kind, at — delivered, bounced, complained, opened if you must
- suppressions: id, address_hash, reason, at — **hard bounces and complaints, permanent, checked before every send**

THE RULES THAT PROTECT THE REPUTATION YOU ARE RENTING
- **Never send to a hard-bounced or complained address again, ever.** One provider suspension from ignoring this costs more than years of subscription
- A per-recipient rate cap, so a loop cannot send somebody four hundred messages
- Queue everything with retries, backoff and a dead-letter list. Never send inside a web request
- Idempotency keys, so a retried job does not send twice

WHAT YOU MUST CONFIGURE WHOEVER SENDS
- SPF, DKIM and DMARC on your own domain, with DMARC eventually at reject. **This is the largest single deliverability factor you control** and it is free
- A separate subdomain for marketing and transactional mail, so a campaign cannot damage your password reset delivery
- One-click unsubscribe headers on anything bulk, which is now required by the large providers
- A plain text alternative on every message

WHAT TO MEASURE
- Delivery, bounce and complaint rates per template and per day. **A complaint rate above about one in a thousand is an emergency**, not a metric
- Time from queue to delivery, which catches a relay problem before customers do

IF YOU RELAY THROUGH YOUR OWN SERVER ANYWAY
- Only for genuinely low volume to addresses that expect you, with reverse DNS, a warm-up over weeks, and the acceptance that some providers will never deliver you reliably

WHAT MATTERS MOST
Rent the delivery, own the templates, the queue and the suppression list. That way switching provider is a configuration change and nothing is lost.