Perché le stesse 50.000 email costano $5 o $66

Il divario di prezzo spiegato

La differenza di prezzo dipende dal modello di business: infrastruttura contro piattaforma. Amazon SES vende capacità di calcolo e banda allo stato puro (infrastruttura), mentre provider come Postmark o Mailgun vendono un'esperienza gestita (piattaforma) con una UI migliore, supporto specializzato e pool di IP curati. Per 50.000 email, SES a consumo costa circa $5, mentre i piani di Postmark possono arrivare a $66. Paghi per ridurre il carico operativo e per la qualità degli strumenti che circondano l'API.

I conti nudi e crudi: 50.000 email

Quando guardo la coda degli incidenti o la fattura mensile del cloud, la disparità nei prezzi delle email è una delle voci più stridenti. Per capirne il motivo, dobbiamo guardare le tariffe di mercato attuali, aggiornate a settembre 2026.

L'approccio infrastrutturale: Amazon SES

Amazon SES è il riferimento per i costi. Secondo la sua pagina dei prezzi, l'invio a consumo costa $0.10 ogni 1.000 email.

• Calcolo: (50.000 / 1.000) * $0.10 = $5.00.

Tuttavia, il 21 luglio 2026 AWS ha introdotto nuovi piani a livelli. Se passi al piano Essentials, il costo è $0.16 ogni 1.000 email. Il piano Pro costa $0.22 ogni 1.000 più un canone mensile di $105 per regione. Il piano Enterprise costa $0.23 ogni 1.000 più $500 al mese. Per un piccolo team di prodotto il modello a consumo è il più economico, ma scarica tutto il peso della configurazione su chi sviluppa.

L'approccio a piattaforma: Postmark e Mailgun

Provider come Postmark e Mailgun puntano sulla developer experience. Secondo i prezzi di Postmark, il piano base costa $15 al mese per 10.000 email. Le eccedenze costano da $1.80 a $1.20 ogni 1.000 email.

• Calcolo (Postmark): $15 (prime 10.000) + (40.000 / 1.000 * $1.20) = $15 + $48 = $63. (A seconda del piano specifico, si può arrivare a $66).

Allo stesso modo, i prezzi di Mailgun partono da $15 al mese per 10.000 email, con eccedenze tra $1.80 e $1.10 ogni 1.000. Questi provider offrono template ospitati e analytics più intuitive, e questo giustifica il sovrapprezzo per i team che non vogliono costruirsi le proprie dashboard di monitoraggio.

La via di mezzo moderna: Resend

Resend punta sullo stack di prodotto moderno. La sua pagina dei prezzi indica un piano gratuito da 3.000 email al mese (con un tetto di 100 al giorno). Il piano Pro costa $20 al mese per 50.000 email, con eccedenze a $0.90 ogni 1.000.

• Calcolo (Resend): $20 fissi per le prime 50.000.

Accettazione, consegna e arrivo in inbox: la distinzione fondamentale

Un errore comune che vedo nella documentazione tecnica è usare questi tre termini come sinonimi. Non lo sono, e nessuna API può garantire l'ultimo passaggio.

1. Accettazione: è la risposta dell'API. Quando invii un payload con POST a un endpoint, il provider restituisce 202 Accepted o 200 OK. Significa solo che il provider ha ricevuto la richiesta e che questa ha superato la validazione di base. Non significa che l'email sia partita.
2. Consegna: è l'handshake SMTP. Il provider tenta di passare il messaggio al server ricevente del destinatario. Un evento "delivered" significa che il server ricevente ha detto "Lo prendo io".
3. Arrivo in inbox: è la destinazione finale. Il server ricevente (Gmail, Outlook, ecc.) decide se la posta va nella inbox, nella scheda Promozioni o nella cartella spam. Lo determinano i filtri interni del destinatario, la reputazione del mittente e i tuoi record di autenticazione.

Per aumentare le probabilità di consegna devi configurare correttamente il DNS. Ti consiglio di usare un controllo DNS per assicurarti che i record si stiano propagando. Segui una guida rigorosa su DKIM, SPF e DMARC per dimostrare di essere chi dici di essere.

Progettare per l'affidabilità

Inviare un'email è un effetto collaterale esterno. In un sistema distribuito gli effetti collaterali sono pericolosi, perché possono essere duplicati o fallire in silenzio.

Il problema dell'idempotenza

Se il tuo application server va in timeout mentre attende la risposta dell'API email, non sai se l'email è stata inviata. Se ti limiti a ritentare, l'utente riceve due email. Ecco perché una chiave di idempotenza è indispensabile.

Una chiave di idempotenza è un identificatore univoco (di solito un UUID) inviato nell'intestazione. Se l'API vede la stessa chiave due volte, restituisce la risposta memorizzata della prima richiesta riuscita invece di inviare una seconda email.

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

Gestire gli invii guidati dagli agenti

Con la diffusione degli agenti AI e dei server MCP, vediamo sempre più comunicazione "Agent-to-Agent" (A2A). Gli agenti non dovrebbero mai avere accesso illimitato a un'API di invio. Se un LLM entra in loop, può esaurire la tua quota di 50.000 email in pochi minuti e distruggere la reputazione del mittente.

Implementa un flusso di approvazione per gli agenti:

1. Fase di bozza: l'agente genera l'email e la salva in una tabella pending_emails.
2. Human-in-the-loop: un utente o un agente supervisore rivede il contenuto.
3. Esecuzione: il sistema chiama l'API solo dopo che è stato impostato il flag status = 'approved'.

La checklist tecnica per la migrazione

Se passi da un provider costoso a uno più economico (o viceversa), non limitarti a sostituire la chiave API. Usa questa checklist:

• Audit DNS: verifica i tuoi record SPF. Assicurati di non superare il limite di 10 lookup.
• Mappatura dei webhook: ogni provider usa nomi di evento diversi. Mappa delivered del provider A su sent del provider B.
• Sincronizzazione delle soppressioni: esporta le liste di bounce e di segnalazioni di spam. Se importi 50.000 utenti in un nuovo provider e invii a indirizzi noti per i bounce, il tuo account verrà sospeso immediatamente.
• Gestione del limite di frequenza (rate limit): implementa un backoff esponenziale per gli errori 429 Too Many Requests.

Esempio di logica di gestione degli errori

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

Scegliere lo strumento giusto

Se sei uno sviluppatore solitario che costruisce un prototipo, bastano il piano gratuito di Resend o i prezzi a consumo di SES. Se sei un team di prodotto che gestisce un flusso transazionale complesso e ad alto impatto (come reimpostazioni della password o avvisi di fatturazione), la sicurezza operativa di un provider a piattaforma spesso vale la differenza di $60.

Se costruisci applicazioni AI-native, ti serve più di un semplice tubo. Ti serve la prontezza per gli agenti, come un server MCP e un file llms.txt strutturato che aiuti i tuoi agenti a capire come interagire con il livello di comunicazione. È qui che un'API specializzata diventa un moltiplicatore di forza anziché un semplice centro di costo.

In definitiva, il costo dell'API è la parte più piccola dell'equazione. Il costo reale è il tempo di engineering speso a fare il debug di un record DNS configurato male o a gestire una crisi di reputazione causata dalla mancata gestione delle soppressioni. Che tu scelga la strada da $5 o quella da $66, dai priorità alla telemetria e agli strumenti che fanno viaggiare le tue email.

Scopri altra infrastruttura email pensata per chi sviluppa su https://sendhq.cc.