Cosa valutare prima di scegliere
Documentazione da leggere prima di pagare
Per chi scrive codice la documentazione è il prodotto. Prima di aprire un account leggi come funzionano autenticazione, errori, limiti di richieste e gestione dei tentativi ripetuti, e se ci sono esempi nel linguaggio che usi. Controlla anche la cronologia delle modifiche: un’API che cambia senza preavviso rompe il tuo prodotto di notte. Verifica nella documentazione se esistono chiavi di idempotenza, così un tentativo ripetuto non spedisce due volte lo stesso messaggio.
Webhook per rimbalzi, segnalazioni e disiscrizioni
Il tuo database deve sapere quando un indirizzo rimbalza, quando qualcuno segnala spam e quando si disiscrive. Guarda quali eventi arrivano via webhook, come si verifica che la chiamata venga davvero dal fornitore e se i webhook sono compresi nel piano che usi: in alcuni listini compaiono solo ai piani a pagamento. Salva ogni evento con data e identificativo del messaggio, così puoi ricostruire che cosa è successo a un utente.
Chiavi, ambienti e prove in locale
Tieni chiavi diverse per sviluppo, collaudo e produzione, e non scrivere mai una chiave in un file che finisce nel repository. Controlla se il fornitore offre un modo per simulare invii e rimbalzi senza toccare utenti veri. In locale cattura i messaggi con uno strumento di posta di prova invece di spedirli: un collaudo che invia davvero alla lista clienti è l’incidente più imbarazzante, e capita anche ai più esperti.
Limiti di invio e coda
Un limite giornaliero basso va bene per sviluppare e diventa un problema il giorno del lancio. Il gratuito di Resend ha un massimo di 100 email al giorno, quello di Postmark 100 al mese: confronta questi numeri con il picco che aspetti. Metti sempre una coda tra la richiesta dell’utente e la chiamata all’API, con tentativi ripetuti a intervalli crescenti, così un rallentamento del fornitore non blocca la registrazione di nessuno.
Dominio autenticato e reputazione
Configura SPF, DKIM e DMARC seguendo la guida del fornitore, e usa sottodomini diversi per i messaggi di sistema e per il marketing, così un problema delle campagne non danneggia le ricevute. Controlla i documenti pubblicati da Google e Yahoo sui requisiti per i mittenti di grandi volumi e verifica che ti riguardino. Prova gli invii su Gmail, Outlook, Apple Mail, Libero e Virgilio: in Italia molti utenti usano ancora i provider locali.
Dati personali nei log e nei database
Indirizzi, nomi e storico dei messaggi finiscono nei tuoi log, negli strumenti di monitoraggio e nel fornitore. Decidi per quanto tempo li tieni, e fai in modo che la cancellazione di un account si propaghi anche allo strumento email. Chiedi il DPA, dove si trovano i dati e come il fornitore tratta le richieste di cancellazione. Il principio di protezione dei dati fin dalla progettazione vale anche per il tuo codice: fai valutare le scelte al tuo DPO o consulente.
Domande frequenti
Meglio un solo fornitore o due, per email di sistema e marketing?
Un solo fornitore significa un account, un DPA e un solo elenco di contatti da tenere pulito; due fornitori significano reputazioni separate e un guasto che non coinvolge tutto. Se il prodotto è piccolo e il rischio è basso, scegli uno solo e separa almeno i sottodomini. Quando il volume cresce o un incidente sulle campagne costerebbe caro, separa. Qualunque scelta fai, decidi chi è la fonte unica delle disiscrizioni e come l’altro sistema la riceve.
Posso inviare dal mio server con SMTP e senza fornitore?
Tecnicamente sì, ma ti assumi un lavoro continuo: reputazione dell’indirizzo IP, record inversi, elenchi di blocco, gestione dei rimbalzi e dei limiti imposti dai provider di posta. Per volumi piccoli il tempo speso supera di molto il risparmio. Se vuoi comunque provare, tieni la configurazione dietro un’interfaccia semplice, così potrai passare a un fornitore senza cambiare il resto del codice, e controlla le regole dei principali provider sui mittenti di massa.
Quali eventi conservo, e per quanto tempo?
Rimbalzi definitivi, segnalazioni di spam e disiscrizioni vanno conservati finché serve a non riscrivere a quell’indirizzo. Aperture e clic hanno un valore minore e un rischio maggiore: poco affidabili e, collegati a una persona, sono dati di comportamento. Scegli un periodo di conservazione breve, scrivilo nel registro dei trattamenti e cancella dopo. Per l’assistenza basta sapere se un messaggio è stato consegnato; la storia completa di ogni utente raramente serve.
Che cosa succede allo strumento email se un utente cancella l’account?
Dipende da come l’hai collegato, quindi va deciso nel codice. Alla cancellazione dell’account chiama l’API per eliminare il contatto o anonimizzarlo, ma tieni un elenco di soppressione dei disiscritti, se serve a non riscrivere a chi ha chiesto di non ricevere più messaggi. Chiedi al DPO come bilanciare cancellazione e soppressione, e verifica nella documentazione del fornitore se l’eliminazione toglie anche lo storico degli invii. Prova il flusso con un account di prova.
I modelli dei messaggi stanno meglio nel codice o nello strumento?
Nel codice se sono messaggi di sistema che cambiano di rado e vuoi versionarli, rivederli come ogni modifica e collaudarli; nello strumento se li scrive o li modifica chi non programma, come le campagne. Evita una terza via, cioè lo stesso modello copiato in due posti, perché nessuno saprà quale è quello vero. Per ogni modello scrivi chi lo possiede, dove vive e come si collauda: bastano tre colonne in un foglio condiviso.
Come collaudo l’aspetto dei messaggi sui client di posta italiani?
Invia una prova a caselle vere: Gmail, Outlook, Apple Mail, Libero e Virgilio, sul telefono e sul computer. Guarda immagini, pulsanti, modalità scura e dove atterra il messaggio, nella posta principale o tra i promozionali. Servizi come Litmus o Email on Acid mostrano molte anteprime insieme, ma non sostituiscono le caselle vere. Prepara un breve elenco di controlli, e ripetilo ogni volta che cambi il modello di base.
Chi è titolare dei dati se il mio prodotto è per altre aziende?
Dipende dal rapporto. Per i dati dei tuoi clienti aziendali, come referenti e fatturazione, il titolare spesso sei tu. Per gli utenti finali che ogni cliente carica nel prodotto, di solito sei tu il responsabile del trattamento per conto del cliente, e serve un accordo scritto. Il fornitore di email diventa tuo sub-responsabile, e va elencato. Non è una questione da risolvere con intuito: fai tracciare ruoli e flussi di dati al DPO o a un legale prima di inviare messaggi agli utenti dei tuoi clienti.
Quali errori tecnici conviene evitare subito?
Chiamare l’API di invio dentro la richiesta dell’utente, così un fornitore lento blocca la registrazione. Non registrare i fallimenti, e scoprire dopo settimane che le conferme non partivano. Scrivere l’indirizzo mittente nel codice, invece che in una configurazione. Lasciare una chiave di prova in produzione. Non controllare mai l’elenco dei disiscritti prima di un invio promozionale. Metti un avviso automatico se i rimbalzi di un giorno superano di molto il solito, e provalo una volta.
Come capisco che il dominio ha un problema di reputazione?
Cerca i segnali: più rimbalzi del solito, messaggi che arrivano con ore di ritardo su un solo provider, risposte dei clienti che dicono di non aver ricevuto la conferma, segnalazioni di spam nel pannello del fornitore. Controlla che SPF, DKIM e DMARC risultino superati nelle intestazioni di un messaggio vero. Se usi Gmail come destinazione, gli strumenti per i mittenti messi a disposizione da Google mostrano il quadro. Per i requisiti dei grandi mittenti verifica i documenti ufficiali dei provider.