Il playbook per migrare le email transazionali

La sfida principale della migrazione

Per migrare le email transazionali senza perdere osservabilità, devi separare l'attivazione dell'invio dall'implementazione del provider. La strategia consiste nell'implementare uno strato di astrazione del provider che consenta il doppio invio (shadowing) e la mappatura degli eventi. Instradando una piccola percentuale di traffico verso il nuovo provider e continuando a tracciare gli eventi di consegna tramite webhook, puoi verificare che il nuovo provider accetti la posta e che la tua pipeline di osservabilità ne registri i risultati prima di spostare il flusso principale.

Perché si migra

La maggior parte delle migrazioni è motivata da costi, esperienza degli sviluppatori o conformità. Per esempio, la differenza di costo tra provider è significativa. Secondo i prezzi di Amazon SES, l'invio a consumo costa 0.10 USD ogni 1.000 email. I prezzi di Postmark, invece, partono da 15 USD al mese per 10.000 email, con eccedenze tra 1.80 e 1.20 USD ogni 1.000. Inviare 50.000 email costa circa 5 USD con SES a consumo, contro circa 66 USD con i piani di Postmark.

Altri motivi includono il passaggio a una telemetria ridotta al minimo, solo nell'UE, o l'esigenza di una migliore prontezza per gli agenti (come il supporto per server MCP). Qualunque sia il motivo, il rischio è lo stesso: un punto cieco nella pipeline di consegna durante la transizione.

Fase 1: lo strato di astrazione

Se la tua applicazione chiama l'SDK di un provider direttamente nella logica di business, sei vincolato a quel provider. Ti serve un wrapper che standardizzi richiesta e risposta.

Il payload unificato

Definisci uno schema interno indipendente dal provider. Così alla tua applicazione non importa se l'API sottostante si aspetta to come array o come singola stringa.

{ "message_id": "msg_12345", "recipient": "user@example.com", "template_id": "welcome_email", "variables": { "name": "Alex" }, "idempotency_key": "unique_request_id_789" }

Con agenti AI o flussi automatizzati, trattare l'email come un effetto collaterale esterno è fondamentale. Devi usare una chiave di idempotenza per evitare che un loop di un agente che ritenta invii cinque volte la stessa email transazionale allo stesso utente.

Fase 2: configurazione di DNS e identità

Prima di inviare anche una sola email, devi stabilire la tua identità. È qui che fallisce la maggior parte delle migrazioni, per ritardi di propagazione DNS o configurazioni errate.

1. Verifica i domini: aggiungi i record DKIM e SPF del nuovo provider. Usa uno strumento come il controllo DNS email di SendHQ per verificare che i tuoi record siano attivi e formattati correttamente.
2. Comprendi i record: assicurati di conoscere la differenza tra SPF (che autorizza il server) e DKIM (che firma il messaggio). Se durante la migrazione usi più provider, il tuo record SPF deve includerli entrambi.
3. Allineamento DMARC: assicurati che la tua policy DMARC sia impostata su p=none durante la fase iniziale della migrazione, per evitare hard bounce se l'allineamento non è perfetto. Consulta la guida di SendHQ a DKIM, SPF e DMARC per i passaggi di configurazione dettagliati.

Fase 3: l'invio ombra (doppio invio)

Non limitarti a premere un interruttore. Implementa invece una logica di instradamento che invia al provider principale e, in modo asincrono, invia un duplicato (o una percentuale campionata) al nuovo provider.

Logica di implementazione

async function sendEmail(payload) { // Primary send (Current Provider) const primaryResult = await primaryProvider.send(payload); // Shadow send (New Provider) - do not await or block the main thread if (Math.random() < 0.1) { // 10% sample newProvider.send(payload).catch(err => console.error("Shadow send failed", err) ); } return primaryResult; }

In questa fase stai testando l'accettazione da parte del provider: il momento in cui il provider dice "Sì, prendo in carico questo messaggio". È diversa dalla consegna (il messaggio che raggiunge il server ricevente) e dall'arrivo in inbox (il messaggio che evita la cartella spam).

Fase 4: osservabilità e parità degli eventi

L'osservabilità è la capacità di seguire un messaggio da sent a delivered o bounced. Ogni provider ha uno schema di webhook diverso.

Mappare gli eventi

Crea una tabella di mappatura per normalizzare gli eventi nel tuo database interno:

Evento interno | Amazon SES | Resend | Postmark | SendHQ

sent | Send | sent | Sent | sent

delivered | Delivery | delivered | Delivered | delivered

bounced | Bounce | bounced | Bounced | bounced

complaint | Complaint | complained | Complaint | complaint

Gestire i payload dei webhook

Il tuo listener di webhook dovrebbe essere generico. Se ricevi un payload da un nuovo provider, deve passare da un trasformatore prima di arrivare al tuo motore di analytics.

function transformWebhook(provider, payload) { switch(provider) { case 'resend': return { event: payload.data.delivered ? 'delivered' : 'failed', id: payload.data.id }; case 'sendhq': return { event: payload.event, id: payload.message_id }; default: throw new Error("Unknown provider"); } }

Fase 5: il passaggio graduale

Dopo aver verificato che il nuovo provider accetta la posta e che i tuoi webhook mappano correttamente gli eventi, passa a una distribuzione ponderata.

1. 1% del traffico: instrada l'1% di tutta la posta transazionale verso il nuovo provider. Monitora i tassi di bounce.
2. 10% del traffico: aumenta il carico. Controlla i limiti di frequenza (rate limit). Per esempio, il piano gratuito di Resend è limitato a 100 email al giorno, il che può diventare un collo di bottiglia durante i test.
3. 50% del traffico: è il test di stabilità. Assicurati che la latenza resti accettabile.
4. 100% del traffico: passaggio definitivo.

Risolvere gli errori di migrazione più comuni

Lo "scarto silenzioso"

Alcuni provider accettano l'email (202 Accepted) ma la scartano internamente a causa di filtri sui contenuti o di identità di invio non verificate. Ecco perché la fase di invio ombra non è negoziabile. Se i tuoi eventi sent sono numerosi ma gli eventi delivered sono pochi, hai un problema di consegna, non di API.

Picchi e limiti di frequenza

Provider diversi hanno limiti di burst diversi. I prezzi di Mailgun e i prezzi di SendGrid (che ora usa una prova di 60 giorni al posto del piano gratuito) prevedono spesso quote di throughput diverse. Se migri da un account con limiti alti a un account nuovo, potresti subire limitazioni. Implementa una coda (come RabbitMQ o SQS) per assorbire i picchi.

Errori di idempotenza

Quando cambi provider, potresti attivare per errore un nuovo tentativo di un intero batch. Se usi agenti AI per attivare le email, assicurati che l'agente fornisca un ID di richiesta univoco. Se l'agente usa un server MCP per interagire con la tua API email, l'API dovrebbe rifiutare i valori idempotency_key duplicati entro una finestra di 24 ore.

Checklist di migrazione

• Livello di astrazione implementato (payload indipendente dal provider).
• Record DNS (SPF, DKIM) aggiunti per il nuovo provider.
• DNS verificato tramite sendhq.cc/tools/email-dns-checker.
• Listener webhook aggiornato per gestire i nuovi schemi del provider.
• Tabella di mappatura degli eventi completata (Sent, Delivered, Bounced, Complaint).
• Invio shadow attivo dall'1% al 10%.
• Amazon SES non ha più un solo percorso tariffario. AWS ha introdotto i piani Essentials, Pro ed Enterprise il 21 luglio 2026, mantenendo al contempo la tariffazione à la carte. AWS afferma che i nuovi account SES e le combinazioni account-regione senza attività SES a consumo dal 1° giugno 2025 iniziano con Essentials, con l'opzione di passare a un livello superiore o alla tariffazione à la carte. La cronologia dell'account esistente e la regione selezionata possono quindi cambiare il punto di partenza. Prima di creare un foglio di calcolo, apri la sezione dei piani tariffari SES per ogni account e regione di produzione, registra il modello attivo e annota la data. Non dedurre la fatturazione da un vecchio post di blog, dall'account di un altro team o da una tariffa citata senza le funzionalità incluse. I prezzi SES, l'idoneità ai piani, la disponibilità regionale e le regole di AWS Free Tier possono cambiare, quindi al momento dell'acquisto considera la pagina dei prezzi ufficiale e i dati di fatturazione dell'account come fonte autorevole.
• Aumento graduale (1%, 10%, 50%, 100%).
• Chiavi API del vecchio provider revocate dopo 7 giorni di stabilità al 100%.

Considerazioni finali sulla scelta del provider

Scegliere un provider è un compromesso tra costo e velocità di sviluppo. Se ti serve il costo più basso in assoluto, Amazon SES è difficile da battere con 0.10 USD ogni 1.000 email a consumo, anche se i suoi nuovi piani a livelli (Essentials a 0.16 USD, Pro a 0.22 USD) introducono strutture di costo diverse dal 21 luglio 2026. Se ti serve un'API moderna, pronta per gli agenti e con telemetria ridotta al minimo solo nell'UE, SendHQ offre un'alternativa semplificata.

Qualunque sia il provider, l'obiettivo è che il tuo team di ingegneria non resti legato all'SDK di un fornitore specifico. Trattando l'email come un effetto collaterale standardizzato, trasformi una migrazione ad alto rischio in una normale modifica di configurazione.

Scopri di più su come costruire flussi email affidabili su https://sendhq.cc.