Qual è la differenza, in una riga?
SMTP è il protocollo aperto che il tuo software usa per consegnare la posta a un server; un’API email è un’interfaccia HTTPS specifica del provider che fa lo stesso lavoro con payload strutturati e feedback sugli eventi. Il protocollo di invio non decide se arrivi in inbox: lo decidono l’autenticazione e la reputazione del dominio, e SPF, DKIM e DMARC si applicano allo stesso modo a entrambe le strade. Quindi scegli in base all’integrazione: portabilità, gestione degli errori, strumenti. Per tutto ciò che succede dopo che il provider ha accettato il messaggio, la guida è la deliverability delle email per startup.
Come funziona l’invio in SMTP?
La tua applicazione apre una connessione con il server del provider, il relay SMTP (per l’invio di solito la porta 587 con autenticazione, come previsto dalla RFC 6409), e consegna il messaggio già pronto. Il protocollo di trasferimento in sé è la RFC 5321, standardizzata nella forma attuale nel 2008 e in uso da molto prima: per questo lo parlano tutti. Qualsiasi framework, CMS, forum, strumento di monitoraggio o script di decenni fa può inviare così con nient’altro che un host, una porta e delle credenziali. È il vantaggio discreto di SMTP: migrare significa cambiare credenziali, quindi cambiare piattaforma email non vuol dire mai riscrivere il codice di invio. È anche la scelta naturale per gli stack self-hosted, dove il supporto SMTP c’è di serie.
Come funziona l’invio tramite API email?
Il tuo codice chiama l’endpoint HTTPS del provider con un payload JSON: destinatario, contenuto o riferimento a un template, tag, metadati, spesso una chiave di idempotenza per evitare invii duplicati. La risposta è sincrona: un successo con l’ID del messaggio, oppure un errore che il tuo codice può intercettare e ritentare. La documentazione di Postmark rende esplicito il contrasto: la sua API REST restituisce subito un successo o un errore, mentre il suo endpoint SMTP accetta tutti i messaggi e registra gli eventuali errori come bounce, recuperabili comunque tramite i suoi webhook dei bounce. Dopo l’accettazione, i webhook rimandano alla tua app bounce, segnalazioni di spam e aperture, ed è questo che rende possibile la soppressione automatica. Gli SDK dei provider racchiudono tutto in poche righe; in cambio, l’integrazione è specifica di quel provider.
SMTP vs API: il confronto diretto
Tutta la decisione si riduce a uno scambio: SMTP ti dà portabilità, l’API ti dà feedback sugli eventi e strumenti. Ecco come si traduce, riga per riga.
| SMTP | API email | |
|---|---|---|
| Cos’è | Protocollo aperto (RFC 5321), uguale ovunque | Interfaccia di prodotto specifica del provider, su HTTPS |
| Sforzo di integrazione | Quasi nullo se il software parla già SMTP: host, porta, credenziali | Codice da scrivere per l’endpoint o l’SDK del provider |
| Portabilità | Alta: cambiare provider significa cambiare credenziali | Bassa: ogni provider ha il suo formato; cambiare significa riscrivere l’integrazione |
| Gestione degli errori | Accettato all’invio; alcuni errori emergono dopo come bounce asincroni | Errori sincroni che puoi intercettare e ritentare, più eventi asincroni |
| Feedback sugli eventi | Niente nel protocollo: i webhook dei bounce del provider coprono anche la posta inviata in SMTP, ma vanno collegati a parte | I webhook inviano alla tua app bounce, segnalazioni di spam e aperture |
| Template e analisi | Niente nel protocollo: invii un messaggio già pronto | Riferimenti ai template, tag e metadati per messaggio |
| Adatto al self-hosting | Naturale: il software self-hosted parla SMTP di serie | Una dipendenza in più legata a un fornitore nel tuo stack |
Quando è giusto scegliere SMTP?
- Software che lo parla già: un CMS, un forum, un helpdesk o un’app legacy iniziano a inviare tramite il tuo provider con nient’altro che nuove credenziali.
- Massima portabilità: se vuoi la libertà di cambiare provider senza toccare il codice, SMTP è l’interfaccia neutrale.
- Stack self-hosted: il supporto SMTP è integrato in praticamente tutto ciò che faresti girare sulla tua infrastruttura, senza bisogno di SDK.
- Posta operativa a basso volume: gli avvisi dei cron e le notifiche interne raramente giustificano un’integrazione API su misura.
Quando è giusto scegliere l’API?
Per gli invii di prodotto su larga scala. Quando l’email è collegata alla tua applicazione (onboarding, ricevute, flussi del ciclo di vita), errori sincroni, riferimenti ai template e webhook degli eventi ripagano il costo dell’integrazione, e una lista di soppressione può aggiornarsi da sola nel momento in cui un indirizzo va in bounce o segnala spam. Una cosa che l’API non ti dà è la reputazione: quella vive sul tuo dominio di invio, non sul modo in cui invii, quindi il riscaldamento del dominio e l’autenticazione valgono allo stesso modo, comunque tu invii.
Perché fromHello supporta entrambi?
Poiché la scelta riguarda l’integrazione e non la deliverability, fromHello include adattatori per entrambi: API HTTP (Resend, Postmark, SendGrid), qualsiasi server SMTP e caselle Microsoft 365. Imposti un provider predefinito per ogni workspace e puoi legare un template a un provider specifico. Su fromHello Cloud, in accesso anticipato, i piani Team e superiori includono l’invio email già configurato; su Core o in self-hosting, il provider lo porti tu. In ogni caso i limiti stanno a livello del provider: Resend, per esempio, documenta per il suo endpoint SMTP lo stesso rate limit della sua API. E soppressione e consenso li applica la piattaforma qualunque sia la strada di invio: un indirizzo soppresso resta soppresso, che il messaggio parta su HTTPS o dalla porta 587.