Consegna delle email per gli annunci per adulti: perché il codice di verifica non arriva mai

Il guasto per cui nessuno riceve un avviso

Un nuovo utente si registra, inserisce un indirizzo email e aspetta il codice a sei cifre che gli permette di completare la verifica dell'età. Non arriva entro il minuto in cui dovrebbe. Magari finisce nella cartella spam dieci minuti dopo, molto tempo dopo che l'utente ha rinunciato e ha chiuso la scheda. Magari il server di posta ricevente lo rifiuta direttamente al momento dell'invio, con un messaggio di rimbalzo che scorre in un log che nessuno sta guardando. In entrambi i casi, niente nell'esperienza dice all'operatore che qualcosa è andato storto. Il funnel di registrazione mostra semplicemente un visitatore in più che ha inserito un indirizzo email e non è più tornato, indistinguibile da chi ha semplicemente cambiato idea.

Quell'ambiguità è il vero problema, più di qualunque singola causa tecnica. La maggior parte dei siti controlla se un'email è stata inviata, un segno di spunta verde su una dashboard, non se è stata davvero messa davanti a un essere umano. Sono due eventi diversi, e il divario fra loro è esattamente dove un problema di consegna si nasconde per mesi. Un operatore che non ha mai avuto un'interruzione di hosting o un blocco del processore di pagamento può comunque star perdendo una quota reale di nuove registrazioni per un problema di posta che non ha modo di notare, perché non c'è un incidente, non c'è un ticket di assistenza, non c'è una dashboard che diventa rossa.

Questo è un tipo di rischio fornitore diverso da quello che chiude un account di hosting con un avviso che cita una clausola che nessuno rilegge dal giorno della firma. Un host sospeso è rumoroso: il sito si spegne, e l'operatore lo scopre entro pochi minuti perché i clienti lo segnalano e anche la dashboard lo segnala. Un problema di consegna è silenzioso per costruzione. L'account di invio resta aperto, la fattura mensile continua ad arrivare, e l'unico sintomo visibile è un funnel di registrazione che perde persone all'ultimo passaggio per motivi che, dal lato dell'operatore, sembrano un normale abbandono e non un guasto tecnico risolvibile.

La causa di fondo resta comunque lo stesso tipo di attrito di categoria che si presenta con host, banche e processori di pagamento. I provider di posta e i servizi di invio email valutano questa categoria come più rischiosa della media, alcuni esplicitamente e per nome, e un dominio nuovo senza storico di invio parte ogni messaggio con uno svantaggio che non ha nulla a che fare con ciò che il messaggio dice davvero.

Perché questa categoria viene filtrata più delle altre

I filtri antispam e i servizi di posta non trattano tutti i settori allo stesso modo, ed è meglio leggere le differenze prima di iscriversi che dopo che un account viene segnalato. La politica pubblicata da SendGrid sui contenuti vietati elenca, come voci separate, «pornografia o contenuto sessualmente esplicito» e, distintamente, «servizi di escort, ricerca di spose o coniugi per corrispondenza, agenzie matrimoniali internazionali e servizi simili». Quella seconda categoria non riguarda cosa contiene l'email. Nomina l'attività stessa come motivo di esclusione, il che significa che un codice di verifica in puro testo inviato da una directory di escort può restare fuori dalla policy solo per la categoria, indipendentemente da quanto sobrio sia il messaggio.

La politica sull'uso accettabile di Mailgun traccia il confine altrove. La sua sezione sui contenuti vietati è limitata a materiale che costituisce o promuove lo sfruttamento di minori, la zoofilia o atti non consensuali, senza una clausola separata che nomini le attività per adulti o i servizi di escort come categoria. È una restrizione molto più stretta di quella di SendGrid, mirata a ciò che è illegale piuttosto che a quale settore sta inviando. Due grandi provider generalisti, raggiungibili con lo stesso tipo di modulo di iscrizione, tracciano il confine in punti davvero diversi, e un operatore che ne sceglie uno senza leggere oltre la pagina dei prezzi non ha modo di sapere da che parte di quel confine si trova il proprio account finché una revisione non lo segnala.

È lo stesso vuoto di verifica preliminare che coglie di sorpresa gli operatori davanti a una clausola di risoluzione di un hosting o di una CDN che non hanno mai letto, un livello più in basso nella pila. La domanda da porsi prima di scegliere un provider di posta non è se tecnicamente accetta di inviare posta per questo tipo di attività in generale. È se la policy scritta del provider nomina specificamente la categoria dell'attività, per iscritto, prima che parta il primo codice di verifica, non dopo che una revisione antiabuso lo scopre.

Un dominio di invio nuovo aggrava tutto questo, qualunque cosa il provider consenta. I filtri pesano molto la storia e il volume di un dominio, e un dominio comparso di recente che comincia subito a inviare codici automatici a volume assomiglia, per un filtro senza altri segnali, al modello di un account creato per uno scopo ristretto e abbandonato una volta segnalato. Non è un giudizio sull'attività; è una corrispondenza di schema che qualunque dominio nuovissimo innesca, annunci per adulti o no, e svanisce solo con il tempo e un comportamento di invio coerente.

Il minimo tecnico che ogni provider di posta impone ormai a tutti

Anche un provider la cui policy accoglie l'account senza riserve non può da solo far arrivare un'email nella posta in arrivo. Dal primo febbraio 2024, Google richiede a ogni mittente che invia posta a indirizzi Gmail, indipendentemente dal volume, di rispettare una base documentata: come minimo, SPF o DKIM configurati correttamente sul dominio di invio. SPF elenca quali server sono autorizzati a inviare per conto del dominio; DKIM firma ogni messaggio così che il server ricevente possa confermare che non è stato alterato durante il transito. I mittenti che raggiungono le 5.000 email al giorno verso indirizzi Gmail devono superare una soglia più alta: sia SPF sia DKIM insieme, più DMARC pubblicato sul dominio, come minimo in modalità di monitoraggio. Un sito di annunci che invia codici di verifica dell'età, reset di password e ricevute di pagamento a una scala reale supera in fretta quella soglia di 5.000 messaggi, perché ognuno di questi conta ai fini del totale.

Le linee guida pubblicate da Google fissano un numero preciso sopra l'autenticazione: i mittenti di qualunque dimensione devono mantenere il tasso di reclami segnalato tramite Postmaster Tools di Google sotto lo 0,30 per cento, e le stesse linee guida raccomandano di restare sotto lo 0,10 per cento come margine di sicurezza reale, invece di trattare lo 0,30 per cento come un obiettivo su cui stare vicini. Il mancato rispetto si traduce in due guasti distinti e documentati separatamente, non in una penalità vaga. La posta che fallisce SPF, DKIM o DMARC può essere segnalata come spam o rifiutata direttamente con l'errore SMTP 5.7.26. I mittenti che superano la quota di invio consentita da Google incontrano un muro diverso, un errore di limitazione 4.7.28. Nessuno dei due annuncia «questo settore non è benvenuto qui». Entrambi sembrano, dalla dashboard di uno sviluppatore, un normale guasto tecnico, ed è esattamente per questo che tendono a essere notati settimane dopo invece di essere risolti il giorno in cui cominciano.

Yahoo, la cui infrastruttura serve anche gli indirizzi AOL, pubblica indipendentemente lo stesso tipo di requisito: sia SPF sia DKIM, una policy DMARC di almeno p=none che deve superare la verifica, e lo stesso tetto dello 0,30 per cento sul tasso di reclami, in vigore sulla stessa tempistica dal febbraio 2024. Un operatore che risolve questo problema per Gmail e presume che Yahoo e AOL seguiranno di conseguenza di solito ha ragione sulla meccanica, dato che i due provider sono convergiti su numeri quasi identici, ma i due sistemi tracciano e applicano le regole separatamente, quindi un dominio in regola con uno non è automaticamente in regola con l'altro.

Un requisito di questo insieme è scritto in modo volutamente ristretto. L'annullamento dell'iscrizione a un clic, tramite l'intestazione List-Unsubscribe, si applica specificamente ai messaggi di marketing e ai messaggi sottoscritti, nelle parole stesse di Google. Un codice di verifica o una ricevuta di pagamento non sono né l'uno né l'altro, quindi non è a questo che punta quella riga in particolare. I requisiti di autenticazione e reputazione sopra di essa, SPF, DKIM, DMARC e il tetto sui reclami, non sono limitati in questo modo: si applicano a ogni messaggio che un dominio invia, transazionale incluso.

L'errore che trascina giù anche la posta importante

Il modo più comune con cui un operatore danneggia le proprie email di verifica è inviare posta di marketing dallo stesso dominio che invia i codici di verifica e le ricevute di pagamento. La reputazione viene tracciata soprattutto a livello di dominio e sottodominio di invio, ed è per questo che separare i flussi aiuta, ma l'isolamento fra sottodomini non è assoluto: un'impennata di reclami su un sottodominio può comunque riflettersi sul dominio principale, in particolare se entrambi i flussi condividono la stessa identità di firma DKIM dietro le quinte. Un'email promozionale che annuncia una nuova funzione o un'offerta stagionale, inviata a una lista ormai invecchiata, produce esattamente il tipo di impennata di reclami che può far scendere la reputazione di un dominio condiviso, e parte di quel danno raggiunge il codice di verifica che un utente appena registrato sta aspettando proprio ora, un messaggio che non ha nulla a che fare con l'invio di marketing che ha causato il problema.

È anche qui che la disciplina operativa costruita attorno alla verifica dell'età si intreccia con un problema di consegna della posta puramente tecnico in un modo facile da non notare. Un flusso di verifica che dipende da un codice che raggiunge una casella di posta è affidabile solo quanto lo è la reputazione del dominio di invio nel giorno in cui quel codice parte, e la reputazione è una risorsa condivisa fra ogni tipo di messaggio che usa un'infrastruttura correlata, a meno che l'operatore non li tenga deliberatamente separati.

La soluzione è strutturale, non un'impostazione da cambiare dopo che un'impennata di reclami è già successa. Invia la posta transazionale, codici di verifica, conferme di pagamento, reset di password, da un sottodominio dedicato usato per nient'altro, per esempio mail.esempio.com invece del dominio nudo o di un sottodominio di marketing condiviso, e firmala con una chiave DKIM propria invece di una riusata su ogni flusso. Invia i contenuti di marketing o le newsletter da un sottodominio completamente separato, come news.esempio.com, con propri record di autenticazione e propria reputazione, capace di assorbire una brutta settimana di reclami senza trascinare giù la posta che deve arrivare per forza. I due flussi possono passare per lo stesso account presso il provider, ma devono apparire, ed essere firmati, come mittenti nettamente distinti agli occhi del server di posta ricevente.

Cosa controllare davvero questa settimana

Comincia tirando fuori la politica sull'uso accettabile di qualunque servizio stia attualmente inviando la posta transazionale del sito, e trova, per iscritto, se nomina specificamente la categoria dell'attività, allo stesso modo in cui ha funzionato in precedenza il controllo sui contratti di hosting e CDN per i fornitori di infrastruttura. Un provider la cui policy esclude già la categoria per nome non è un provider su cui costruire un flusso di verifica, per quanto affidabile sia stato finora, perché una revisione dell'account può porre fine a quell'affidabilità senza alcun preavviso.

Verifica che SPF, DKIM e DMARC siano davvero pubblicati e superino la verifica sul dominio che invia in questo momento le email di verifica e di ricevuta, invece di darlo per scontato perché qualcuno li ha configurati una volta, anni fa. Un record DNS che era corretto quando è stato scritto può diventare obsoleto dopo una migrazione di provider, e un dominio privo di autenticazione parte ogni messaggio con una possibilità concreta di rifiuto secondo le regole che Google e Yahoo applicano dal febbraio 2024, a prescindere da cosa dica il messaggio.

Separa la posta transazionale da quella di marketing su sottodomini distinti con chiavi di firma distinte, se non lo sono già, e trattalo come lavoro infrastrutturale e non come una decisione del reparto marketing, dato che sbagliare costa un controllo d'identità fallito, non una vendita mancata.

Osserva il tasso di reclami reale tramite i report del provider o tramite Postmaster Tools di Google secondo un calendario fisso, e tratta qualunque avvicinamento allo 0,10 per cento come il punto in cui indagare, non lo 0,30 per cento, dato che lo 0,30 per cento è più vicino al punto in cui la posta comincia a essere rifiutata che a quello in cui comincia un problema. E ogni tanto invia una vera registrazione di prova verso un indirizzo Gmail personale e uno Yahoo personale, e misura quanto tempo impiega il codice ad arrivare e dove arriva, perché una dashboard che segnala un invio riuscito sta segnalando cosa è uscito dal server, non cosa ha effettivamente visto un utente.