Le email transazionali sono quelle che l'utente si aspetta perché le ha provocate con un'azione: una conferma d'ordine, un codice di accesso, il link per reimpostare la password, la ricevuta di un pagamento, l'avviso di un nuovo accesso all'account. Hanno caratteristiche molto diverse dalle newsletter. Sono attese, spesso urgenti, e quando non arrivano l'utente non pensa «non mi interessa», pensa «il servizio non funziona». Per questo meritano un'attenzione dedicata.
Perché sono diverse
Rispetto alle campagne promozionali, le transazionali hanno:
- tassi di apertura molto alti e segnalazioni di spam quasi nulle;
- tempi critici: un codice che arriva dopo dieci minuti è spesso già scaduto;
- volumi irregolari, legati all'attività degli utenti e non a un calendario;
- destinatari che non si possono escludere: anche chi ha disiscritto dalla newsletter deve ricevere la propria ricevuta.
Questi tratti ne fanno il traffico con la reputazione migliore. Il rischio principale è contaminarlo con quello promozionale.
Separare i flussi
La regola più importante è non mescolare transazionali e promozionali sulla stessa identità di invio. Se una campagna genera molte segnalazioni o colpisce delle spam trap, il danno di reputazione non deve ritardare i reset password.
La separazione si costruisce su più livelli:
| Livello | Esempio |
|---|---|
| sottodominio di invio | account.example.com per le transazionali, news.example.com per le campagne |
| firma DKIM | chiave e dominio di firma distinti per ciascun flusso |
| Return-Path | dominio di ritorno distinto, per gestire rimbalzi separati |
| IP o pool | se la piattaforma lo consente, flussi su pool diversi |
| piattaforma | in alcuni casi, servizi diversi per i due tipi di traffico |
Va detto con chiarezza: la reputazione del dominio principale resta collegata ai sottodomini. La separazione riduce la propagazione dei problemi, non la elimina. Il modo più sicuro per proteggere le transazionali resta gestire bene anche le campagne.
Inviare dall'applicazione senza perdere messaggi
Molti problemi delle email transazionali non riguardano i filtri antispam, ma il modo in cui l'applicazione le genera.
Non inviare dentro la richiesta dell'utente
Se l'applicazione si collega al server di posta mentre l'utente aspetta il caricamento della pagina, un rallentamento del servizio di invio diventa un rallentamento del sito, e un errore temporaneo diventa un messaggio perso. È meglio mettere il messaggio in una coda e farlo inviare da un processo separato, che può ritentare in caso di errore.
Gestire errori e tentativi
Le piattaforme di invio, sia via SMTP sia via API, possono rispondere con errori temporanei. Il processo che svuota la coda deve:
- ritentare gli errori temporanei con attese crescenti;
- non ritentare all'infinito gli errori permanenti;
- registrare ogni tentativo con un identificativo, per poter rispondere a un utente che dice di non aver ricevuto nulla.
Evitare il server di posta locale non configurato
Un errore frequente nei siti piccoli è lasciare che il CMS invii con la funzione di posta predefinita del server web. Quei messaggi partono spesso da un IP senza reputazione, senza DKIM, con un mittente non allineato, e finiscono nello spam o vengono rifiutati. Configurare l'invio tramite un servizio autenticato è quasi sempre il primo intervento da fare.
Contenuto: chiaro, breve, senza promozioni
Un'email transazionale deve fare una cosa sola. Alcune indicazioni pratiche:
- oggetto descrittivo: «Il tuo codice di accesso» o «Conferma dell'ordine 4821»;
- mittente coerente con il nome del servizio che l'utente conosce;
- informazione principale in alto: il codice, il link, l'importo;
- versione in testo semplice accanto a quella HTML;
- nessun contenuto promozionale invadente, che cambierebbe la natura del messaggio agli occhi dei filtri e, in molti casi, delle norme sulle comunicazioni commerciali.
Per i codici e i link di reimpostazione conviene indicare la durata di validità e ricordare cosa fare se la richiesta non è stata fatta dall'utente.
Monitorare quello che non si vede
Il problema delle transazionali è che nessuno si lamenta finché non è troppo tardi. Conviene quindi controllare in modo attivo:
- il tempo tra la generazione e la consegna, per individuare ritardi;
- i rimbalzi e i rifiuti, divisi per provider;
- il volume giornaliero, con un allarme se scende a zero: spesso significa che la coda si è bloccata;
- la ricezione su alcune caselle di prova presso i provider principali.
Nel mio lavoro, l'allarme sul volume a zero ha individuato più guasti di qualunque altro controllo: un'integrazione rotta dopo un aggiornamento non genera errori, smette semplicemente di inviare.
In sintesi
- Le transazionali sono attese e urgenti: un ritardo viene percepito come un guasto del servizio.
- Vanno separate dalle campagne con sottodomini, firme DKIM e, se possibile, IP distinti.
- L'applicazione deve inviare tramite una coda con tentativi, non durante la richiesta dell'utente.
- Il contenuto deve essere breve, chiaro e senza promozioni invadenti.
- Un allarme sul volume giornaliero a zero individua i guasti silenziosi.
