In sintesi
- Routing su più provider: collega diversi provider di invio (Amazon SES, SendGrid, Mailgun, SMTP generico, Gmail OAuth) a un unico workspace e gestiscili da un solo punto.
- Bilanciamento del carico ponderato: assegna a ogni server una quota del traffico in uscita in base a costo, quota giornaliera e velocità massima di invio.
- Failover automatico: quando un provider restituisce errori di throttling o di disponibilità (ad esempio HTTP 429, HTTP 5xx o un SMTP 421 dal relay), i messaggi in coda vengono reindirizzati in tempo reale verso un server di backup.
Quando i tuoi volumi raggiungono centinaia di migliaia o milioni di email al mese, affidarsi a un solo provider di invio diventa un single point of failure. Un disservizio del provider, una manutenzione programmata, il throttling o il raggiungimento inatteso della quota giornaliera di invio possono ritardare campagne ed email transazionali da cui dipende l'attività.
L'infrastruttura multi-provider di eMailBase risolve il problema trasformando i tuoi server di invio in un pool flessibile e capace di autoripararsi, invece che in un unico canale.
1. I vantaggi tecnici di un'architettura multi-server
Gestire più server di invio da un unico pannello di controllo ti offre tre vantaggi operativi:
Failover automatizzato
Quando il server principale non è raggiungibile o rifiuta gli invii con un errore temporaneo (come un SMTP 421 dal relay, oppure un HTTP 429 o 5xx dall'API di un provider), eMailBase sposta automaticamente i messaggi interessati dalla coda a un server di backup preconfigurato, così la campagna continua. I rinvii decisi dal mailbox provider del destinatario (ad esempio un 4xx da Gmail o Outlook) vengono ritentati secondo la pianificazione anziché passare al failover, perché cambiare provider non risolve un blocco lato destinatario.
Throughput e quote scalabili
Ogni account di invio in cloud ha una velocità massima di invio (email al secondo) e, nella maggior parte dei provider, una quota giornaliera o mensile. Distribuendo il traffico su più server, il throughput complessivo può avvicinarsi alla capacità combinata di tutti i server, così le campagne di grandi dimensioni si concludono prima. In pratica, il throttling applicato dai principali mailbox provider lato ricezione resta valido, quindi regola il ritmo degli invii verso ciascun dominio destinatario in base alla tua reputazione.
Separazione del traffico per finalità
Puoi dedicare server distinti a ciascun flusso di posta: un account Google Workspace (Gmail OAuth) per i follow-up commerciali personali one-to-one, un pool Amazon SES per le newsletter ricorrenti e Twilio SendGrid per le email transazionali attivate da eventi. Tenere separati i flussi ne isola anche la reputazione, così una campagna newsletter poco riuscita non penalizza reset delle password e ricevute.
2. I modelli di infrastruttura di invio più comuni
| Modello di architettura | Configurazione | Obiettivo operativo principale |
|---|---|---|
| Ottimizzato sui costi, con failover | Amazon SES (peso 80%) + SendGrid (peso 20% e destinazione di failover) | Sfruttare il basso costo per messaggio di Amazon SES mantenendo su SendGrid un percorso di backup affidabile e già «caldo». |
| Configurazione iniziale flessibile per PMI | Gmail OAuth con 1 clic (email one-to-one) + Amazon SES (email delle campagne) | Usare la casella aziendale esistente per partire subito con i contatti personali, mentre SES gestisce i grandi volumi. Google Workspace limita gli invii a circa 2.000 messaggi per utente al giorno, e l'invio massivo verso Gmail richiede comunque SPF, DKIM e DMARC sul tuo dominio. |
| Grandi aziende | Più account Amazon SES in diverse regioni (US East, EU West, Asia Pacific Southeast) | Ottenere quote e velocità di invio indipendenti per regione, mantenere i dati nella regione richiesta per la conformità sulla residenza dei dati e restare operativi se una regione AWS subisce un incidente. |
3. Come configurare il routing dei server in eMailBase
- Apri il BYO Sending Hub nel tuo workspace.
- Collega ciascun provider inserendo la sua API key o le credenziali SMTP, oppure collega un account Google con OAuth in 1 clic.
- Regola il cursore Weight di ogni server per impostare la ripartizione del traffico che desideri.
- Scegli il server che fa da destinazione di failover e imposta la soglia di tentativi, cioè il numero di tentativi falliti ammessi prima che il traffico cambi percorso.
