1) Prima regola: definire “non ricevuto” in modo operativo

“Non ricevuto” può voler dire almeno quattro cose diverse. Se non le separi, rischi di inseguire fantasmi. Dal lato prodotto, la prima azione è trasformare la segnalazione in una categoria:

• Non arrivato in inbox ma presente in spam/promozioni/altre tab.
• Mai consegnato: bounce, rifiuto, blocco, dominio inesistente o policy provider.
• Consegnato in ritardo: code, rate limit, retry, congestione o “greylisting”.
• Inviato “a livello app” ma mai partito davvero: bug, timeout, job non eseguito, provider down.

Queste categorie cambiano completamente le verifiche successive. Per questo, nei flussi email critici (OTP, reset password, magic link), serve una telemetria che ti dica cosa è accaduto end-to-end, non solo “status=sent” nel database applicativo.

2) Mappa il percorso end-to-end: dove può rompersi?

Un Product Team efficace ragiona per “catena del valore”. Un’email transazionale attraversa tipicamente questi passaggi:

1. L’utente genera l’azione (es. “Invia codice”).
2. Il backend valida la richiesta e crea un evento (o job) di invio.
3. Il sistema invia al provider (SMTP o API) e riceve un ID messaggio.
4. Il provider prova a consegnare al dominio destinatario.
5. Il provider del destinatario filtra: inbox, spam, quarantena o rifiuto.
6. L’utente legge (o non vede) il messaggio.

Quando il prodotto mostra “Inviato”, spesso sta confermando solo lo step 2 o 3. Invece, ciò che interessa all’utente è lo step 5. La differenza tra “accettato dal provider” e “consegnato in inbox” è enorme.

3) Il minimo indispensabile: i dati da raccogliere dal primo ticket

Il supporto e il prodotto devono parlare la stessa lingua. Un ticket utile deve contenere campi standardizzati. Se non li hai, aggiungi un template interno e obbliga i campi minimi.

• Email destinatario (hashata): mai in chiaro nei canali non sicuri, ma serve una chiave per correlare.
• Timestamp (con timezone) e “azione” effettuata (OTP, reset, invito, receipt).
• Ambiente: web/app, regione, IP/ASN (se consentito), rete aziendale o domestica.
• Provider destinatario: gmail.com, outlook.com, yahoo, dominio aziendale, iCloud, ecc.
• Esito lato UI: messaggio di conferma, errori, retry fatti, screenshot opzionale.

Per un Product Team, standardizzare questi dati significa dimezzare i tempi di diagnosi. In parallelo, aggiungi nel prodotto un “codice richiesta” o “request_id” visibile (o copiabile) dopo l’invio: è il ponte tra esperienza utente e log tecnici.

4) Osservabilità: cosa devi loggare per non andare “a intuito”

Se vuoi gestire seriamente i casi “sent but not received”, serve un tracciamento a prova di discussione. Idealmente, ogni invio genera un record con:

• request_id (correlazione) e message_id (provider).
• template/version del contenuto e tipo evento (OTP, reset, newsletter, onboarding).
• provider_response: accepted/queued/rejected + motivazione.
• delivery_events: delivered, deferred, bounced, complained, opened (se tracciato).
• timing: latenza tra click utente → enqueue → provider accepted → delivered.

Dal punto di vista prodotto, i timing contano: se il 90° percentile di “delivered” supera, ad esempio, 60 secondi su OTP, l’esperienza utente va in crisi. Non perché “non funziona”, ma perché l’utente percepisce fallimento. La telemetria ti permette di decidere: migliorare l’infrastruttura, cambiare copy, introdurre retry, o offrire un canale alternativo.

5) Diagnosi rapida: checklist in 15 minuti

Quando arriva un caso concreto, ecco una sequenza che funziona bene per isolare la classe di problema senza perdere ore.

Step A: conferma che l’evento sia stato generato

• La richiesta esiste? request_id presente?
• Il backend ha validato e creato il job?
• Ci sono errori di rate limit, captcha, antifrode, o blocchi per troppi tentativi?

Step B: conferma che il provider abbia accettato

• Hai un message_id del provider?
• Risposta “accepted” o “queued”?
• Eventi “rejected” immediati: dominio inesistente, policy, blacklist, mittente non autorizzato.

Step C: consegna e filtering

• Evento “delivered”? Se sì, è quasi sempre filtering (spam/quarantena/tab).
• Evento “deferred”? Potrebbe essere greylisting o reputazione bassa: il provider ritenta.
• Evento “bounced”? Analizza codice e motivo, poi classifica in hard vs soft bounce.

La regola pratica: se arrivi a “delivered” ma l’utente non vede nulla, il problema è quasi sempre posizionamento (spam, promozioni) o UI/ricerca (l’utente cerca male, filtri attivi). Se invece non hai “delivered” e vedi “deferred” o “bounce”, sei nell’area deliverability/reputazione/configurazione.

6) Deliverability per Product Team: le leve che contano davvero

Anche se non sei un deliverability engineer, ci sono concetti chiave che un Product Team deve conoscere perché impattano direttamente KPI e conversione.

Autenticazione: SPF, DKIM, DMARC

Se l’autenticazione è debole o incoerente, molti provider penalizzano o bloccano. A livello prodotto, devi assicurarti che: il dominio mittente sia coerente, i record DNS siano corretti e che il flusso “from/reply-to/return-path” non crei sospetti. Non serve conoscere ogni dettaglio tecnico per capire l’effetto: senza autenticazione solida, il “sent” non vale nulla.

Reputazione: come la rovini senza accorgertene

La reputazione non si rovina solo con spam “intenzionale”. Si rovina anche con: invii improvvisi a grandi volumi, liste sporche, bounce alti, complaint, e contenuti che sembrano phishing. Un Product Team deve monitorare tassi di bounce e complaint come metriche di prodotto, non come numeri “di backend”.

Contenuto: parole e formati che fanno scattare filtri

OTP e reset password dovrebbero essere messaggi minimalisti, coerenti e leggibili. Template troppo “marketing”, link abbreviati sospetti, immagini pesanti o copy aggressivo possono peggiorare il placement. Anche il subject conta: se sembra promozionale, finisce nelle schede sbagliate o in spam.

7) Il caso più comune: OTP che arrivano tardi (o mai)

Dal punto di vista di prodotto, l’OTP è un flusso con requisiti “real-time”. Se l’email arriva dopo 2–3 minuti, per l’utente è equivalente a non arrivare. Ecco i pattern tipici:

• Code interne: job queue congestionata, worker insufficienti, retry e backoff troppo aggressivi.
• Rate limit: troppi invii dallo stesso IP/dominio in poco tempo, soprattutto su provider grandi.
• Greylisting: il server destinatario rimanda l’accettazione per testare la legittimità.
• Contenuto “rischioso”: subject/link che peggiorano la priorità e inducono filtri più severi.

Soluzioni lato prodotto che spesso funzionano: migliorare i worker, introdurre prioritizzazione per OTP, fornire “reinvia dopo X secondi” con un limite intelligente, e mostrare un messaggio di guida più concreto (“controlla spam”, “attendi fino a 60 secondi”, “verifica che l’indirizzo sia corretto”).

8) Anti-abuso vs deliverability: l’equilibrio che il prodotto deve gestire

Molti sistemi falliscono perché cercano di proteggersi da bot e abusi con misure che degradano l’esperienza reale. Rate limit troppo stretto, blocchi su domini temporanei, o regole antifrode aggressive possono creare falsi positivi. Dal punto di vista Product, la domanda è: “quanta frizione posso aggiungere senza perdere utenti buoni?”

Una pratica efficace è segmentare: applicare controlli più severi a pattern sospetti (molti tentativi, IP anomali), ma mantenere un percorso fluido per utenti normali. Se tutto è bloccato “in media”, il tasso di conversione scende.

9) Cosa dire all’utente: copy che riduce tickets e frustrazione

Il modo in cui comunichi “stiamo inviando” cambia l’esito. Un Product Team deve scrivere copy che sia: specifico, empatico e utile, senza scaricare colpe sull’utente.

• Evita: “Controlla lo spam” come unica frase.
• Meglio: “Può richiedere fino a 60 secondi. Controlla Spam/Promozioni. Se non arriva, reinvia tra 30 secondi.”
• Aggiungi: “Hai inserito l’indirizzo corretto?” con opzione “modifica email” senza perdere lo stato.
• Mostra: un indicatore di tempo (“inviato alle 10:21”) e un pulsante “copia request_id” per supporto.

È sorprendente quanto un buon copy riduca il volume dei ticket: molte segnalazioni sono dovute a ritardi normali o a filtri, ma l’utente non ha alcun contesto.

10) Struttura di incident response: quando il problema è sistemico

A volte non è un singolo caso: è un’ondata. Per esempio, un provider cambia policy, o la reputazione peggiora, o un DNS viene modificato. In questi casi, il Product Team deve attivare una risposta da incidente:

1. Definisci impatto: quali flussi (OTP, reset) e quale percentuale utenti?
2. Segmenta: per dominio destinatario, regione, template, endpoint.
3. Mitiga: fallback (reinvia, canale alternativo, estensione validità OTP), riduzione volume marketing.
4. Comunica: status page o banner in-app per ridurre tickets e ansia.
5. Post-mortem: cosa è mancato in osservabilità, configurazione o processi?

Il valore di un Product Team qui è tradurre l’incidente tecnico in priorità e azioni che proteggono l’esperienza utente, senza perdere settimane in discussioni astratte.

11) Misurare i progressi: metriche che hanno senso per il prodotto

Se non misuri, il problema torna. Le metriche utili non sono solo “email inviate”, ma:

• Acceptance rate: quante email vengono accettate dal provider di invio.
• Delivered rate: quante risultano consegnate.
• Time-to-deliver: percentile (p50/p90/p99) del tempo di consegna, soprattutto per OTP.
• Bounce rate: hard vs soft, e distribuzione per dominio destinatario.
• Complaint rate: segnalazioni spam, disiscrizioni (se applicabile).
• Ticket rate: ticket “non ricevuto” per 1000 invii, segmentati per flusso.

Collegare queste metriche a conversione, attivazione e retention ti permette di giustificare investimenti: deliverability non è un vezzo tecnico, è un moltiplicatore di funnel.

12) Chiusura: una mentalità, non un singolo fix

Il debug “sent but not received” non è un pulsante da premere, è un sistema di lavoro: classificare, osservare, segmentare, mitigare e imparare. Dal punto di vista del Product Team, la vittoria non è “risolto quel ticket”, ma ridurre la probabilità che si ripeta e rendere la diagnosi immediata quando accade.

Se implementi anche solo tre cose — request_id visibile, eventi di delivery collegati al messaggio, e metriche di tempo di consegna — avrai già trasformato un problema frustrante in un processo controllabile. E quando il prossimo utente dirà “Non mi è arrivato”, non dovrai più rispondere a tentoni: avrai una traccia, un contesto e una soluzione.