Email transazionali: gli strumenti con cui le sviluppo, le provo e le invio

Le email sono la parte di un progetto web che quasi nessuno inserisce nel preventivo e che quasi tutti notano quando non funziona. La conferma d'ordine che finisce nello spam, il recupero password che non arriva, la notifica del modulo contatti che nessuno legge da settimane: sono problemi che pesano sull'esperienza dell'utente quanto una pagina lenta, ma restano invisibili finché un cliente non telefona. Per me le email sono uno strumento fondamentale, troppo spesso snobbato, e vanno progettate, sviluppate e provate come qualsiasi altra interfaccia.

Ci sono arrivato per gradi. Ho iniziato scrivendo l'HTML delle email a mano, tabella dentro tabella, e mandando le prove da server che si presentavano con un mittente sostituito, senza nessuna autenticazione. Funzionava, finché i provider di posta non hanno iniziato a fidarsi sempre meno di chi non dimostra di essere chi dice. Oggi lavoro in un altro modo, e gli strumenti che uso raccontano bene cosa è cambiato.

Perché le email sono un'interfaccia difficile

Il primo problema è il rendering. Un browser moderno segue gli standard; i client di posta no, o lo fanno ognuno a modo suo. Outlook per Windows usa ancora il motore di Word per impaginare, Gmail toglie parte degli stili, le app su telefono gestiscono il tema scuro invertendo i colori in modi diversi. Per questo l'HTML delle email è fatto ancora di tabelle annidate, stili in linea e larghezze fisse: tecniche che sul web abbiamo abbandonato da anni.

Il secondo problema è la consegna. Un'email ben scritta non serve a nulla se il server che la riceve non si fida del mittente. La reputazione del dominio e dell'indirizzo IP, l'autenticazione e il contenuto decidono se il messaggio arriva in posta in arrivo, nello spam o da nessuna parte. E chi sviluppa spesso non lo scopre, perché nei suoi test tutto arriva.

MJML: componenti al posto delle tabelle

Per il codice uso MJML, un linguaggio a componenti pensato per le email. Si scrive con tag come <mj-section>, <mj-column> e <mj-button>, e il compilatore produce l'HTML pieno di tabelle e stili in linea che i client si aspettano, comprese le correzioni per Outlook. Il vantaggio non è solo il tempo risparmiato: il sorgente resta leggibile, si divide in parti riutilizzabili (intestazione, piè di pagina, pulsante) e si versiona su Git insieme al resto del progetto.

MJML ha anche un limite che conviene conoscere: compila HTML statico. I dati (nome del cliente, righe dell'ordine, link di conferma) vanno inseriti dopo, con il motore di template del progetto. Io tengo separati i due passaggi: MJML per la struttura, compilata una volta, e i dati inseriti al momento dell'invio.

Mailpit: provare senza disturbare nessuno

In sviluppo uso Mailpit, un server SMTP finto con un'interfaccia web. L'applicazione gli invia le email esattamente come farebbe con il servizio vero, ma Mailpit le trattiene e le mostra: HTML, versione testuale, intestazioni, allegati. Così posso provare un flusso di registrazione dieci volte di seguito senza riempire caselle reali e senza il rischio di scrivere a un cliente con dati di prova.

È il contrario di come lavoravo all'inizio, quando le prove partivano davvero verso indirizzi miei con mittenti improvvisati. Con Mailpit l'ambiente di sviluppo è chiuso: niente parte verso l'esterno finché il codice non è in produzione. Ha anche un controllo di base dell'HTML e dei link, utile per accorgersi presto di un tag non supportato.

Brevo, Mailjet e ora Resend

Per l'invio ho usato a lungo Mailjet e Brevo. Sono piattaforme complete: editor visuale, liste, campagne, statistiche, e Brevo anche l'invio di SMS, che ho usato quando un progetto aveva bisogno di notifiche via telefono. Restano una buona scelta quando chi gestisce il sito deve preparare newsletter in autonomia.

Per le email transazionali, che partono dal codice e non da una persona, oggi sto passando a Resend. Il motivo è la comodità per chi programma: un'API semplice, librerie ufficiali per Node e gli altri linguaggi più diffusi, la verifica del dominio guidata, i webhook per sapere se un messaggio è stato consegnato, è rimbalzato o è stato segnalato come spam. Si integra bene con le funzioni serverless che uso già per moduli e API, e il flusso resta lo stesso del resto del progetto: codice su Git, chiavi nelle variabili d'ambiente, una prova in anteprima prima di andare online.

Autenticazione: SPF, DKIM e DMARC

Qui sta la differenza più grande rispetto a come lavoravo anni fa. Mandare email con un mittente qualsiasi, senza autenticazione, oggi significa finire nello spam o essere rifiutati. I record da configurare nel DNS del dominio sono tre:

• SPF elenca i server autorizzati a inviare per il dominio.
• DKIM firma ogni messaggio con una chiave crittografica: chi riceve verifica che l'email non sia stata alterata e che venga davvero dal dominio.
• DMARC dice cosa fare dei messaggi che non superano i controlli (niente, quarantena, rifiuto) e a chi mandare i report.

Il punto che spesso si trascura è il monitoraggio. DMARC va introdotto per gradi: prima in sola osservazione, leggendo i report per scoprire tutti i servizi che inviano per conto del dominio (il gestionale, il CRM, il vecchio server del sito), poi con regole più severe. È anche una protezione: chi prova a mandare email fingendosi il dominio viene bloccato, un tema che riprendo parlando di siti WordPress hackerati.

Un'altra buona regola è separare i flussi: le transazionali da un sottodominio, le campagne da un altro. Una newsletter con molte segnalazioni non deve compromettere l'arrivo delle password e delle conferme d'ordine.

Gli altri strumenti che consiglio

Oltre a quelli che uso ogni giorno, ce ne sono alcuni che consiglio di affiancare, soprattutto su progetti con molte email o un pubblico ampio:

• React Email: lo stesso approccio a componenti di MJML, ma scritto in React, con un'integrazione naturale con Resend. Utile se il progetto è già in React o se si vogliono template con logica.
• Can I email: l'equivalente di Can I use per le email, dice quali proprietà HTML e CSS supporta ogni client.
• Litmus o Email on Acid: anteprime reali su decine di client e dispositivi, compreso il tema scuro. A pagamento, ma risparmiano molte prove a mano.
• mail-tester: si invia un'email a un indirizzo generato e si riceve un punteggio con i problemi di autenticazione, contenuto e reputazione.
• Google Postmaster Tools: mostra la reputazione del dominio verso Gmail, i tassi di spam e gli errori di autenticazione. Da attivare su qualsiasi dominio che invii con regolarità.
• Un lettore di report DMARC: i report arrivano in XML, illeggibili a mano; servizi come dmarcian o Postmark DMARC li trasformano in un riepilogo settimanale.

Come la vedo io

Tratto le email come un pezzo del prodotto, non come un dettaglio da sistemare alla fine. Nel mio flusso il template nasce in MJML ed è versionato su Git, le prove passano da Mailpit in locale, l'invio avviene tramite API con le chiavi nelle variabili d'ambiente, e ogni modifica si prova in un'anteprima prima di arrivare online, come faccio per il resto del sito con GitHub e Netlify. Il dominio ha SPF, DKIM e DMARC prima ancora del primo invio, non dopo il primo reclamo.

È anche una questione di poche dipendenze: per le transazionali basta un servizio di invio con una buona API, non una piattaforma di marketing con tutto incluso. Quando un sito lascia WordPress per un'architettura più leggera, come racconto in da WordPress a Nuxt.js, GitHub e Netlify, le email sono uno dei punti da ripensare con più attenzione, perché spesso erano affidate a un plugin che nessuno ricordava più di avere.

Perché affidarlo a me

Sviluppo siti e applicazioni dal 1999 e ho visto le email passare dall'HTML scritto a mano ai componenti, e dai server senza autenticazione ai domini firmati e monitorati. Posso progettare i template, integrare l'invio con il gestionale, l'e-commerce o il CRM, configurare SPF, DKIM e DMARC e capire perché un messaggio non arriva. Se il tuo progetto ha email che finiscono nello spam o che nessuno ha mai davvero provato, scrivimi o guarda il servizio di integrazioni API e automazioni.