Perché le email transazionali della tua app finiscono nello spam (e come risolvere)

Perché la consegna delle email transazionali è un'altra storia

C'è una distinzione fondamentale tra email di marketing ed email transazionali che molti sviluppatori si perdono quando iniziano a occuparsi seriamente di deliverability. Le email di marketing — newsletter, campagne promozionali, annunci — vanno a iscritti che hanno dato il consenso. Tollerano ritardi occasionali e persino il fatto di finire di tanto in tanto nello spam. Se una newsletter finisce nello spam per il 2% della tua lista è un peccato, ma l'attività va avanti.

Le email transazionali sono un'altra cosa. Link di verifica, reimpostazioni della password, conferme d'acquisto, codici a due fattori, avvisi di sicurezza dell'account: arrivano in momenti critici del percorso dell'utente. Una reimpostazione della password che finisce nello spam significa un utente bloccato fuori dal proprio account, che con buona probabilità aprirà un ticket di supporto o, peggio, non tornerà mai più. Un'email di verifica nello spam significa che un nuovo utente non può completare la registrazione e che il tuo funnel di acquisizione ha una perdita silenziosa e invisibile.

Eppure le email transazionali vengono spesso configurate con meno cura delle campagne di marketing. Molti sviluppatori usano il codice di invio che offre il framework invece di costruire con cura il sistema di email di verifica, lo puntano a un server SMTP condiviso, fanno il deploy, testano una volta con la propria casella — che ha soglie antispam generose — e passano oltre. I problemi emergono solo quando utenti reali su Gmail, Outlook o Yahoo segnalano email mai arrivate. A quel punto il guasto sta fallendo silenziosamente in produzione da settimane.

SPF: le fondamenta dell'autenticazione email

Il Sender Policy Framework (SPF) è un record DNS TXT sul tuo dominio di invio che dichiara al mondo quali mail server sono autorizzati a inviare email a tuo nome. Quando Gmail riceve un'email che dichiara di arrivare da [email protected], esegue una query DNS sul record SPF del tuo dominio. Se l'indirizzo IP del server che ha effettivamente inviato l'email è elencato nel record SPF, l'email supera il controllo SPF. Se non esiste alcun record SPF — o se il server mittente non è elencato — l'email viene trattata con sospetto prima che inizi qualsiasi valutazione del contenuto.

Configurare SPF è semplice, una volta capito cosa serve. Aggiungi un record TXT al DNS del tuo dominio. Il valore dipende dal tuo provider di invio. Con SendGrid: v=spf1 include:sendgrid.net ~all. Con AWS SES: v=spf1 include:amazonses.com ~all. Con Mailgun: v=spf1 include:mailgun.org ~all. La documentazione del provider indica il valore include esatto. Il suffisso ~all è un "soft fail": le email da server non elencati vengono segnalate ma non rifiutate subito. Quando sei certo che il record SPF sia completo e corretto, puoi passare a -all (hard fail), che istruisce i server riceventi a rifiutare del tutto la posta non autorizzata.

Una trappola frequente: il limite di 10 lookup DNS. I record SPF che concatenano più direttive include: possono superare questo limite, facendo fallire SPF anche se tutti i tuoi server sono tecnicamente elencati. Usa MXToolbox per controllare il record SPF: segnala chiaramente i problemi di conteggio dei lookup. Il modo in cui SPF, DKIM e DMARC si intrecciano è spiegato bene nella documentazione di SendGrid sull'autenticazione email.

DKIM: la prova crittografica che l'email non è stata manomessa

DomainKeys Identified Mail (DKIM) aggiunge una firma crittografica a ogni email che invii. La firma viene generata con una chiave privata custodita dal tuo provider di invio, e i server riceventi la verificano usando una chiave pubblica che tu pubblichi come record DNS TXT. Se la firma è valida, due cose sono dimostrate: l'email proviene davvero dalla tua infrastruttura di invio e il contenuto non è stato modificato tra invio e ricezione.

Senza DKIM configurato diventa molto più facile per un malintenzionato falsificare il tuo dominio, cioè inviare email che sembrano arrivare da [email protected] ma sono state spedite da qualcun altro. È esattamente il meccanismo delle campagne di phishing. Anche i filtri antispam lo sanno, ed è per questo che un'email priva di firma DKIM valida proveniente da un dominio che dovrebbe averla viene trattata con sospetto elevato. Spamhaus e altri servizi di reputazione includono lo storico delle firme DKIM nei punteggi di reputazione del dominio.

La configurazione di DKIM si fa dal tuo provider di invio. Il provider genera una coppia di chiavi, conserva quella privata sulla propria infrastruttura e ti fornisce una chiave pubblica da aggiungere al DNS come record TXT. Una volta pubblicato e propagato quel record, ogni email inviata a tuo nome porterà automaticamente una firma DKIM valida. La maggior parte dei provider principali — SendGrid, Mailgun, Amazon SES, Postmark — ti guida in questo processo durante la configurazione iniziale. Se hai saltato il passaggio, torna indietro e configuralo ora.

DMARC: il livello di policy che tiene insieme tutto

DMARC (Domain-based Message Authentication, Reporting and Conformance) si appoggia a SPF e DKIM definendo cosa devono fare i server riceventi quando un'email non supera quei controlli. Introduce inoltre il concetto di "allineamento": richiede che il dominio nell'header From dell'email corrisponda effettivamente al dominio che ha superato SPF o DKIM. Questo impedisce a un attaccante di superare il controllo SPF su un dominio mentre ne falsifica un altro nell'indirizzo From visibile.

L'approccio corretto a DMARC è procedere per gradi. Inizia con una policy di solo monitoraggio: v=DMARC1; p=none; rua=mailto:[email protected]. Il p=none dice ai server riceventi di non intervenire in caso di fallimento, ma solo di inviarti i report. Questi report aggregati ti mostreranno quali server inviano email a tuo nome e se superano SPF e DKIM. Esaminali per qualche settimana prima di modificare la policy.

Quando sei sicuro che tutto il traffico legittimo passa, spostati su p=quarantine (le email che falliscono vanno nello spam) e infine su p=reject (le email che falliscono vengono rifiutate del tutto). Questa progressione protegge la reputazione del dominio dallo spoofing dandoti al tempo stesso il tempo di individuare eventuali fonti di invio legittime dimenticate. Una policy DMARC con p=reject insieme a SPF e DKIM superati rende quasi impossibile per un attaccante impersonare efficacemente il tuo dominio.

Reputazione IP: perché conta il tuo server di invio

Anche con SPF, DKIM e DMARC perfetti, le tue email possono finire nello spam se l'indirizzo IP da cui partono ha una cattiva reputazione. I server riceventi mantengono — o consultano servizi terzi che mantengono — blocklist e punteggi di reputazione per gli IP mittenti. Un IP con uno storico di invio spam, o che compare nelle blocklist di servizi come Spamhaus, vedrà le proprie email in uscita trattate con sospetto indipendentemente da quanto sia curata la tua autenticazione.

Se usi un indirizzo IP condiviso di un hosting condiviso o di un servizio SMTP economico, la tua reputazione è legata a quella di tutti gli altri che usano lo stesso IP. Un solo spammer nello stesso pool condiviso può affossare la deliverability di tutti i mittenti su quell'IP. È uno degli argomenti più forti a favore di un provider dedicato di email transazionale — SendGrid, Amazon SES, Postmark, Mailgun — invece di inviare direttamente dal server applicativo o tramite un SMTP condiviso.

Su un IP di invio nuovo dovrai anche "scaldarlo" gradualmente. Un picco improvviso di volume da un IP appena creato appare come comportamento da spammer agli occhi dei server riceventi. Parti da volumi bassi e aumenta progressivamente nel corso di giorni o settimane. Gran parte dei provider email dedicati gestisce automaticamente il warm-up se sei su un pool di invio condiviso, oppure fornisce calendari di riscaldamento se usi un IP dedicato.

Contenuto e oggetto: cosa fa scattare i filtri

Oltre ad autenticazione e reputazione IP, anche il contenuto dell'email viene valutato dai filtri antispam. Alcuni schemi fanno scattare la classificazione come spam in modo affidabile. Le parole trigger nell'oggetto — "GRATIS", "GARANTITO", "AGISCI SUBITO", punti esclamativi in eccesso, TUTTO MAIUSCOLO — sono quelle ovvie, che la maggior parte degli sviluppatori evita. Meno ovvio: oggetti troppo vaghi ("Messaggio importante per te"), troppo urgenti ("Il tuo account sarà chiuso") o troppo promozionali per qualcosa che dovrebbe essere un'email transazionale.

Conta anche il rapporto testo/immagini. Un'email fatta quasi solo di immagini con pochissimo testo è uno schema classico dello spam: chi invia in massa usa le immagini per nascondere le parole chiave ai filtri basati sul testo. Le email transazionali dovrebbero essere prevalentemente testuali, con pochissime immagini. HTML rotto — tag non chiusi, attributi malformati — è un altro segnale d'allarme. Invia sempre un'alternativa in testo semplice insieme alla versione HTML. I filtri antispam guardano con maggiore sospetto le email solo HTML, e i sistemi di posta aziendali spesso rimuovono completamente l'HTML.

Testare la consegna delle email — nel modo giusto

Il metodo di test più rapido e pratico per la consegna delle email è questo: invia un'email di prova a una casella di email temporanea appena creata e controlla sia la posta in arrivo sia la cartella spam. Ottieni un riscontro immediato e senza ambiguità sul fatto che l'email raggiunga la inbox o venga filtrata. A differenza del test con il tuo account Gmail — che potrebbe già averti in whitelist come mittente frequente — un indirizzo temporaneo nuovo non ha alcuno storico con il tuo dominio, e quindi simula in modo molto più fedele il primo contatto di un nuovo utente.

Dovresti verificare che l'email di verifica arrivi davvero ogni volta che modifichi qualcosa che possa influenzare la consegna: cambio di provider email, modifica sostanziale del template HTML, cambio del dominio di invio, aggiunta di un nuovo sottodominio di invio o deploy su un nuovo ambiente (staging, produzione). Richiede due minuti e fornisce una prova definitiva. L'alternativa — aspettare che gli utenti segnalino il problema — significa che i tuoi guai di deliverability stanno già fallendo in silenzio da un periodo imprecisato.

Oltre al controllo inbox/spam, usa il verificatore di salute email di MXToolbox per controllare lo stato generale del dominio: SPF, DKIM, DMARC, presenza nelle blacklist e configurazione dei record MX, tutto in un unico posto. Rendilo parte della tua checklist pre-lancio per ogni nuova applicazione o dominio di invio. Consulta anche le linee guida OWASP sulle best practice email legate alla sicurezza.

Tasso di bounce e segnalazioni di spam: le metriche che contano

Due metriche hanno un effetto sproporzionato sulla deliverability nel lungo periodo: il tasso di bounce e il tasso di segnalazioni di spam. Un tasso di bounce superiore al 2% comunica ai server riceventi e al tuo provider che stai inviando a molti indirizzi non validi o inesistenti — uno schema associato alle liste acquistate e alle operazioni di spam. Anche se tutto il resto è a posto, un tasso di bounce alto ti creerà problemi di consegna. Rimuovi gli hard bounce dalla lista di invio immediatamente e in modo definitivo.

Un tasso di segnalazioni superiore allo 0,1% (una segnalazione ogni mille email inviate) è la soglia oltre la quale la maggior parte dei provider comincia a limitare il tuo account. I Postmaster Tools di Gmail riportano il tasso di segnalazioni direttamente, se li hai configurati. Monitora queste metriche dalla dashboard del tuo provider di invio. Se le segnalazioni aumentano, indaga sul perché: stai scrivendo a utenti che non hanno dato un consenso esplicito? Le tue email sono troppo frequenti? C'è uno scarto tra ciò che gli utenti si aspettavano e ciò che ricevono?

Checklist completa di deliverability

• Record SPF: record DNS TXT sul dominio di invio che elenca tutti i server autorizzati. Verificalo con MXToolbox.
• DKIM: firma crittografica configurata tramite il provider di invio, chiave pubblica pubblicata nel DNS.
• DMARC: parti dal monitoraggio con p=none, passa a p=quarantine e poi a p=reject dopo aver esaminato i report aggregati.
• Provider di invio dedicato: usa SendGrid, SES, Postmark o Mailgun — non il server applicativo né un SMTP condiviso.
• Oggetti puliti: specifici, pertinenti, senza parole trigger, senza punteggiatura o maiuscole eccessive.
• HTML + testo semplice: includi sempre entrambi. Non inviare mai email solo HTML.
• Nessun accorciatore di URL: usa URL complete e dirette nel corpo dell'email e nei link di verifica.
• Link di disiscrizione: includilo anche nelle email transazionali dove è appropriato — alcuni provider lo richiedono.
• Indirizzo fisico: richiesto da CAN-SPAM e da normative analoghe in molte giurisdizioni.
• Gestione degli hard bounce: rimuovili subito; non ritentare mai un hard bounce.
• Monitoraggio delle segnalazioni: configura i Gmail Postmaster Tools; controlla il tasso di segnalazioni nella dashboard.
• Test in inbox: invia email di prova a caselle temporanee nuove prima di ogni deploy e dopo ogni modifica di template o configurazione.
• Controllo di salute MXToolbox: inseriscilo nella checklist pre-lancio per ogni nuovo dominio e ambiente.

Quando usare un servizio dedicato di email transazionale

Se la tua applicazione invia una qualsiasi email che l'utente deve ricevere perché il prodotto funzioni — link di verifica, reimpostazioni della password e le ricevute che chiudono un percorso completo di registrazione e pagamento — dovresti usare un provider dedicato di email transazionale sin dal primo giorno. Il costo è basso (spesso gratuito fino a decine di migliaia di email al mese), l'affidabilità è enormemente superiore a un SMTP fatto in casa, e l'infrastruttura di deliverability — pool di IP condivisi con reputazione gestita, firma DKIM automatica, gestione di bounce e segnalazioni — è mantenuta da team il cui unico lavoro è tenere le email nelle inbox.

L'errore fai-da-te più comune è far girare un mail server sullo stesso IP dell'applicazione web, oppure usare il servizio SMTP incluso da un hosting economico. Questi IP finiscono regolarmente nelle blocklist di servizi come Spamhaus, perché l'ambiente di hosting è condiviso con soggetti malevoli. Passare a un provider transazionale dedicato richiede in genere un pomeriggio di lavoro e ha un impatto positivo immediato sulla deliverability. È uno degli interventi infrastrutturali con la leva più alta che un piccolo team possa fare. I team attenti alla privacy dovrebbero inoltre leggere le indicazioni della Electronic Frontier Foundation sulla gestione responsabile dei dati degli utenti quando è coinvolta l'email. In aggiunta, controllare gli indirizzi contro i database di violazioni note tramite Have I Been Pwned può integrare la tua prevenzione delle frodi al momento della creazione di nuovi account.