Un provider può accettare il tuo volume mensile ma limitare il burst dopo un'interruzione al checkout. Confronta il contratto di invio con il lavoro che la tua applicazione deve recuperare.
Cos'è l'email transazionale?
L'email transazionale serve una transazione o un'attività sull'account del destinatario, come una ricevuta o un reset della password. Lo scopo del messaggio ne determina la categoria. Il numero di destinatari e l'invio automatico non rendono transazionale un contenuto promozionale.
Cosa dovresti valutare?
Confronta le funzionalità di cui la tua applicazione ha bisogno, poi testa i percorsi di errore prima di impegnarti.
- Deliverability e strumenti di reputazione. Riesci ad autenticare il tuo dominio con SPF, DKIM e DMARC facilmente? Sono disponibili IP dedicati se ne hai bisogno, con indicazioni sul riscaldamento?
- Qualità di API e SDK. La API è ben documentata, con SDK ufficiali nei linguaggi che utilizzi?
- SMTP e HTTP entrambi. Verifica quale interfaccia di invio supporta il tuo runtime. I client SMTP esistenti possono usare un relay; un HTTP API serve le applicazioni che inviano richieste strutturate.
- Template. I template lato server con sostituzione di variabili ti permettono di modificare il testo senza un deploy e di mantenere la formattazione coerente tra i messaggi.
- Webhook ed eventi. Gli eventi webhook in tempo reale per consegna, apertura, clic, bounce e reclamo sono il modo in cui mantieni accurati i tuoi record e attivi logiche di follow-up.
- Analitiche. Viste aggregate di tassi di consegna, bounce e coinvolgimento, più un log consultabile per indagare su un singolo messaggio.
- Gestione delle soppressioni. Il provider dovrebbe sopprimere automaticamente gli hard bounce e i reclami, così che la tua applicazione possa interrompere gli invii bloccati da quei segnali. Chiedi come vengono gestite le liste di soppressione e se puoi ispezionarle.
- Scalabilità. Riesce a gestire il tuo volume di picco (un lancio di prodotto, un picco festivo) senza intervento manuale o throttling imprevisto?
- Pricing. Comprendi il modello (per messaggio, a fasce, volume incluso) e dove scattano i costi di eccedenza. Calcolalo per il tuo volume previsto e i periodi di picco.
- Supporto. Quando la posta smette di funzionare alle 2 di notte, come raggiungi una persona e quanto velocemente risponde? Verifica il livello di supporto incluso nel piano che acquisteresti davvero.
- Conformità. Conferma che il provider soddisfi i requisiti di gestione dei dati e regionali a cui è soggetta la tua azienda prima di impegnarti.
Quando scegliere un servizio relay SMTP?
Scegli un relay SMTP quando la tua applicazione costruisce già i messaggi email e supporta un mail server configurabile. Scegli un HTTP API quando hai bisogno di campi di richiesta strutturati o template archiviati.
Per Bird, confronta i percorsi di invio e di ripristino prima di scegliere l'interfaccia:
| Decisione o errore | Relay SMTP | HTTP email API |
|---|---|---|
| Autenticazione | Username bird, chiave API come password, con lo scope emails. Usa TLS sull'host regionale SMTP. | Chiave API nell'header Authorization: Bearer, con lo scope emails. |
| Risposta all'invio | Il 250 finale contiene l'ID del messaggio in coda. Salvalo insieme all'evento applicativo. | 202 contiene l'ID del messaggio accettato. Salvalo insieme all'evento applicativo. |
| Responsabilità dei retry | La tua applicazione o il client SMTP gestisce i retry di invio. Riutilizza X-Bird-Idempotency-Key per lo stesso messaggio logico. | La tua applicazione o SDK gestisce i retry di invio. Riutilizza Idempotency-Key per lo stesso messaggio logico. |
| Scadenza | Prima di riprovare un job non inviato, la tua applicazione verifica se il link o il codice è ancora valido. | Applica lo stesso controllo prima di inviare un'altra richiesta. |
| Ipotesi di throughput | Verifica i limiti di connessioni concorrenti separatamente dalle quote di invio. Più connessioni aperte non stabiliscono un'indennità di velocità di invio. | Regola le richieste API usando gli header di limitazione delle richieste nella risposta. Frequenza delle richieste e volume dei destinatari sono quantità diverse. |
| Tracciamento eventi | Segui gli eventi del destinatario dopo la risposta di accodamento. Bird ritenta le consegne differite. | Segui gli stessi eventi del destinatario dopo l'accettazione. Bird ritenta le consegne differite. |
| Selezione del pool | La configurazione SMTP della chiave API seleziona il pool. Una chiave non configurata usa il pool predefinito dell'organizzazione. | Imposta ip_pool_id per singolo invio, oppure usa il pool predefinito dell'organizzazione. |
La guida al relay SMTP fornisce le impostazioni di connessione e la gestione delle risposte. Il riferimento per l'invio HTTP definisce la richiesta e la risposta API. Entrambe le interfacce usano la stessa pipeline email, incluse gestione delle soppressioni e firma.
L'accettazione a livello di trasporto significa che Bird ha accodato il messaggio. Il successivo evento email.delivered indica che il server ricevente lo ha accettato. Nessuno dei due stabilisce il posizionamento in inbox o la lettura.
Conserva il tuo record di invio oltre la finestra di retention dell'idempotenza, perché un retry successivo può creare un altro messaggio. Un differimento è già in fase di retry da parte di Bird; creare un altro invio duplica lavoro ancora in corso.
Gli IP dedicati sono opzionali per entrambe le interfacce. Verifica i requisiti di pool e riscaldamento prima di instradare un burst attraverso un pool dedicato.
Quali funzionalità documentate dovresti confrontare?
Verifica l'interfaccia documentata dietro ogni funzionalità. Ricevere un'email analizzata, archiviarne il contenuto ed esporre una conversazione API sono funzionalità diverse.
| Provider | Invio | Tracciamento del destinatario | Infrastruttura di ricezione e invio |
|---|---|---|---|
| Bird | Invio HTTP e SMTP | Eventi, log dei messaggi e soppressioni | Caselle e thread; pool di IP dedicati |
| Amazon SES | SendEmail API e SMTP | Destinazioni eventi e lista di soppressione dell'account | Regole di ricezione nelle regioni supportate; IP dedicati standard o gestiti |
| SendGrid | Mail Send API e SMTP | Event Webhook e Email Activity | Inbound Parse webhook; IP pools |
| Mailgun | Messages API e SMTP | Eventi di consegna e record di bounce | Route per inoltrare o archiviare la posta; IP pools |
| Postmark | Email API e SMTP | Webhook e soppressioni dello stream | Webhook inbound; idoneità IP dedicati |
| Resend | Email API e SMTP | Eventi webhook e log API | Contenuti ricevuti e risposte; IP dedicati gestiti |
Conferma idoneità e retention per il piano che acquisteresti. Un link a una funzionalità non stabilisce un'indennità di throughput o un impegno sui tempi di ripristino.
Per i contenuti archiviati, verifica quali corpi, header, allegati e record di eventi rimangono recuperabili. Per la residenza dei dati, ottieni l'ambito documentato di archiviazione e trattamento, incluse le eccezioni. Un endpoint regionale da solo non stabilisce quel contratto.
Cosa cambia a dieci milioni di invii al mese?
Il traffico di picco e la capacità di ripristino determinano la velocità di invio necessaria. Il volume mensile da solo no.
In un mese illustrativo di 30 giorni, dieci milioni di messaggi con destinatario singolo producono una media di circa 3,86 messaggi al secondo. Un burst di 100.000 messaggi in dieci minuti ne richiede circa 167 al secondo. Valuta il burst separatamente dall'indennità mensile.
Dopo un'interruzione di dieci minuti a 100 nuovi messaggi al secondo, la tua applicazione ha 60.000 job non inviati. Se il nuovo lavoro continua a 100 al secondo, smaltire quel backlog in venti minuti richiede altri 50 al secondo. L'obiettivo di ripristino è quindi 150 messaggi accettati al secondo, prima di retry o ritardi del server ricevente.
Verifica come ogni provider conteggia il lavoro. Le quote SES contano i destinatari e si applicano separatamente per regione. Includono una quota giornaliera a finestra mobile e una velocità di accettazione. SES avvisa anche che l'accettazione effettiva può essere inferiore alla velocità massima dell'account.
I limiti di Resend distinguono la frequenza delle richieste API dalle quote di volume email. Gli header di limitazione delle richieste di Bird riportano la quota effettiva di richieste. Traduci la dimensione del tuo batch in richieste prima di confrontare l'una o l'altra con la velocità di destinatari dello scenario.
Come dovresti testare il ripristino da un incidente?
Testa come la tua applicazione riprende dopo un invio fallito o quando il suo handler di webhook diventa indisponibile. La pagina di stato del provider fornisce il contesto dell'incidente; i tuoi record dei messaggi stabiliscono quale lavoro rimane.
| Provider | Limiti pubblicati o contratto di errore | Stato ufficiale |
|---|---|---|
| Bird | Quote effettive e header di retry | Stato di Bird |
| Amazon SES | Quote di invio | Stato dei servizi AWS |
| SendGrid | Limiti di frequenza API | Stato di SendGrid |
| Mailgun | Contratto di errore e limitazione delle richieste API | Stato di Mailgun |
| Postmark | Contratto di risposta e di errore API | Stato di Postmark |
| Resend | Limiti di utilizzo | Stato di Resend |
Metti in pausa un worker di test, accumula i job e riprendi entro il limite effettivo dell'account. Misura quanto tempo attende il job idoneo più vecchio. I job di reset scaduti richiedono un percorso di nuova richiesta anziché un replay automatico.
Preserva ogni identificatore di evento business durante il ripristino. Verifica il contratto del provider sull'invio duplicato prima di riprovare un invio incerto. Postmark non documenta una funzionalità di chiave di idempotenza, quindi la sua integrazione richiede salvaguardie applicative. La retention delle risposte completate di Bird è di tre ore. Il ripristino oltre quella finestra richiede il tuo record di eventi.
Associa gli eventi successivi del destinatario agli ID dei messaggi salvati. L'accettazione da parte del server ricevente non stabilisce il posizionamento in inbox o la lettura. Il ciclo di vita dell'email transazionale API spiega questi esiti separati.
Cosa includere nel confronto dei prezzi?
Confronta le inclusioni pubblicate per il piano esatto, il periodo di fatturazione e la valuta che acquisteresti. Tieni il volume di invio separato dall'infrastruttura e dalla retention di cui ha bisogno.
| Fonte dei prezzi del provider | Inclusioni da verificare per il tuo carico di lavoro |
|---|---|
| Prezzi Bird | Indennità di invio, eccedenze, infrastruttura dedicata, contenuti conservati e supporto |
| Prezzi Amazon SES | Utilizzo in uscita e in entrata, costi dati, IP dedicati e funzionalità opzionali |
| Prezzi SendGrid | Volume del piano, eccedenze, idoneità IP dedicati, retention delle attività e supporto |
| Prezzi Mailgun | Volume di invio, retention di log e messaggi, IP dedicati e supporto |
| Prezzi Postmark | Indennità di invio, volume aggiuntivo, opzioni di retention e idoneità IP dedicati |
| Prezzi Resend | Indennità di invio e ricezione, eccedenze, retention e idoneità IP dedicati |
Verifica se un'indennità dichiarata conta richieste, messaggi o destinatari. Registra le funzionalità escluse accanto al piano anziché assumere che siano incluse. I confronti tra provider di Bird contengono i confronti separati per prodotto.
Domande frequenti
Qual è la differenza tra email transazionale e marketing?
La posta transazionale serve una transazione o un'attività sull'account. La posta di marketing promuove qualcosa o consegna contenuti in abbonamento. Lo scopo del messaggio determina la distinzione, anche quando entrambe sono automatizzate.
Un unico provider può gestire sia la posta transazionale che quella di marketing?
Un provider può servire entrambi i flussi di lavoro. Verifica separatamente la policy di categoria, le identità di invio autenticate e la selezione del pool IP. Un'infrastruttura condivisa può comunque esporre la posta operativa a problemi di reputazione dovuti al traffico di marketing.
Ho bisogno di un IP dedicato?
Non subito. I pool di IP condivisi vanno bene per volumi inferiori e ti risparmiano il riscaldamento dell'IP. Un IP dedicato ha senso quando il tuo volume è abbastanza alto e costante da mantenere una propria reputazione. Scegli un provider che ti permetta di iniziare con IP condivisi e passare a dedicati quando i numeri lo giustificano.
Dove si inserisce Bird
Puoi inviare tramite SMTP o l'HTTP API. Pubblica template per contenuti riutilizzabili. Iscriviti agli eventi del destinatario. Ispeziona i singoli messaggi nel log email.
Seleziona gli IP pool separatamente dalla categoria del messaggio. Segui le indicazioni di riscaldamento quando modifichi il volume di invio. Usa la checklist operativa per testare la gestione dei duplicati e il ripristino.
Come fare la scelta finale?
- Abbina le interfacce documentate e i controlli sui destinatari alla tua applicazione.
- Conferma le quote effettive sia per il traffico di picco che per il ripristino del backlog.
- Testa la gestione degli errori confrontandola con i record salvati di messaggi ed eventi business.
- Confronta inclusioni pubblicate, retention e supporto per il piano che acquisterai.