Resend ha richiamato l’attenzione sui requisiti Gmail per i mittenti di grandi volumi, cioè chi consegna più di 5.000 messaggi al giorno agli account Gmail. La soglia funziona bene come titolo. Il lavoro vero inizia sotto quel numero: autenticazione del dominio, allineamento, sicurezza del trasporto, gestione delle disiscrizioni e monitoraggio dei reclami devono concordare.
Per questo la conformità email va trattata come un sistema operativo, non come una checklist DNS.
L’autenticazione deve descrivere il percorso reale
Le linee guida Google richiedono ai bulk sender SPF e DKIM, un record DMARC, TLS, DNS diretto e inverso validi e messaggi conformi agli standard Internet. Le email di marketing e quelle basate su iscrizione devono inoltre offrire la disiscrizione con un click e un link ben visibile nel messaggio.
SPF indica quali server possono inviare per un dominio. DKIM firma il messaggio affinché il destinatario possa verificare il dominio firmatario e rilevare modifiche. DMARC collega questa autenticazione al dominio visibile nel campo From e definisce una policy per i fallimenti.
I record sono semplici solo quando lo è l’architettura di invio. Un’azienda può usare un provider transazionale, una piattaforma marketing, un help desk e un vecchio sistema interno. Aggiungere servizi alla cieca può superare il limite di lookup SPF o lasciare una sorgente dimenticata senza autenticazione. Prima viene l’inventario.
La disiscrizione con un click è una funzione backend
Inserire un link nel footer non equivale a supportare il one-click unsubscribe. Per i messaggi interessati Gmail si aspetta il meccanismo standardizzato, con elaborazione rapida della richiesta. Serve un endpoint capace di riconoscere l’iscrizione in sicurezza, registrare la soppressione e rispondere senza imporre un login.
Il token nell’URL dovrebbe essere firmato, limitato allo scopo e avere una scadenza documentata. L’handler deve essere idempotente: scanner automatici e persone possono aprirlo più volte. Non deve esporre l’indirizzo nei log né permettere di disiscrivere altri utenti modificando la query string.
La soppressione deve poi propagarsi. Se il database marketing registra la scelta ma un job settimanale legge un vecchio export, il protocollo ha funzionato mentre il prodotto ha fallito.
La reputazione è un segnale continuo
Google chiede di mantenere le segnalazioni spam sotto lo 0,3%. È un limite massimo, non un obiettivo. Reclami, bounce, ritardi di consegna e fallimenti di autenticazione vanno osservati per flusso e dominio. Le ricevute transazionali non dovrebbero condividere ogni decisione reputazionale con una lista promozionale trascurata.
Superare 5.000 messaggi non è il momento in cui iniziare. Google classifica i mittenti in base al volume osservato e le stesse abitudini servono molto prima. Neppure inviare 4.999 email è una strategia: requisiti e filtri proteggono i destinatari, e la conformità tecnica da sola non garantisce mai la inbox.
Serve un release check per l’email
Una modifica all’email merita la stessa disciplina di una release applicativa. Prima di aumentare il volume:
- verificare SPF, DKIM e allineamento DMARC sulle intestazioni realmente consegnate;
- testare TLS e DNS per ogni servizio di invio;
- eseguire richieste one-click e controllare che la soppressione sia immediata e idempotente;
- ispezionare versioni testuali e HTML nei client rappresentativi;
- monitorare Postmaster Tools ed eventi provider senza conservare dati personali inutili;
- tenere separati i test di staging dai destinatari production.
Le dashboard dei provider aiutano, ma la casella ricevente resta il test finale di integrazione. Un pannello verde non mostra che un inoltro ha rotto l’allineamento o che una coda ha ignorato la tabella delle soppressioni.
Le regole Gmail non sono un ostacolo una tantum posto su una soglia di traffico. Descrivono la forma minima di un sistema capace di sapere chi ha inviato un messaggio, perché lo ha inviato e come fermarlo. I team che codificano queste risposte nel lavoro quotidiano hanno meno probabilità di scoprirle durante un incidente di deliverability.