Cosa hanno cambiato le regole bulk-sender di Gmail e Yahoo del febbraio 2024

Il 1° febbraio 2024 Google e Yahoo hanno introdotto simultaneamente nuovi requisiti per ogni mittente che superi le 5.000 messaggi al giorno verso le rispettive basi utenti. I due annunci restano i riferimenti canonici — le "Email sender guidelines" di Google e le "Sender best practices" di Yahoo — e rimangono pressoché identici nella sostanza. Le tre richieste:

1. Autenticazione. SPF e DKIM sono obbligatori; DMARC almeno a p=none è obbligatorio. La posta non allineata finisce nello spam o viene rifiutata.
2. Disiscrizione one-click. L'intestazione List-Unsubscribe (RFC 2369, 1998) era già disponibile da tempo; la novità del 2024 è il requisito one-click — l'URL di disiscrizione deve accettare una singola richiesta POST e processarla senza alcun passaggio di conferma (RFC 8058, 2017). L'utente clicca una sola volta nel proprio client di posta e risulta disiscritto.
3. Tetto sul tasso di reclami. I bulk sender devono mantenere il tasso di reclami spam al di sotto dello 0,3% in ogni momento. Tassi più elevati sostenuti nel tempo innescano un declassamento automatico verso la cartella spam.

Prima del 2024 la maggior parte degli operatori self-hosted faceva girare solo SPF + DKIM, saltando il DMARC. L'argomentazione: il DMARC è soltanto una policy sopra agli altri due, e ricevere i report indietro è operativamente fastidioso. Quell'argomentazione oggi non è più sostenibile.

Nel dettaglio, la regola del 2024 esige che il DMARC esista — anche a p=none — e che si allinei. "Allinearsi" in DMARC significa che il dominio From di SPF o il dominio firmatario di DKIM coincide con l'intestazione From: visibile, in modalità strict o relaxed. Un fallimento ricorrente: il mittente usa marketing@suaazienda.com come From visibile ma instrada attraverso un CRM di terze parti che firma DKIM con il dominio del CRM — l'allineamento fallisce, il DMARC fallisce, e Gmail / Yahoo dirottano il messaggio nello spam in silenzio.

Il rimedio è il rollout DMARC standard: pubblicare p=none con reportistica RUA, osservare gli aggregati giornalieri per due o quattro settimane, identificare e correggere gli stream non allineati, salire attraverso p=quarantine, stabilizzarsi su p=reject. Non esistono scorciatoie.

La soglia tecnica è di due intestazioni, entrambe da RFC 8058:

Il client di posta (Gmail, Yahoo, Apple Mail) le interpreta come un link "Annulla iscrizione" one-click nell'intestazione del messaggio. Quando l'utente lo clicca, il client esegue una POST con List-Unsubscribe=One-Click verso l'URL indicato. Il Suo server processa la disiscrizione e risponde 200 OK. Niente pagina di conferma, niente captcha, niente login.

AcelleMail emette entrambe le intestazioni di default per qualsiasi lista di campagna con gestione della disiscrizione abilitata. Dove gli operatori inciampano è nelle integrazioni custom — flussi transazionali che bypassano l'engine di campagna, relay SMTP di terze parti che strippano le intestazioni, o URL di disiscrizione che redirigono attraverso una pagina di conferma del CMS. Ognuno di questi è un colpo alla deliverability.

La verifica più semplice: si invii un test, clicchi su "Mostra originale" in Gmail, cerchi List-Unsubscribe-Post. Se l'intestazione manca o non riporta One-Click, Lei è fuori compliance. Lo corregga prima che il volume superi i 5.000/giorno verso uno dei due provider.

Il tasso di reclami è la percentuale di destinatari che hanno marcato il Suo messaggio come spam, calcolata su base giornaliera in una finestra mobile. L'annuncio di Google chiedeva di restare "sotto lo 0,3%" in modo sostenuto, con "vogliamo vedere il Suo tasso costantemente sotto lo 0,1%" come margine operativo.

Due note implementative:

1. È per dominio, non per account. Se Lei separa il marketing su un sottodominio (es. news.suaazienda.com), il tasso di reclami viene calcolato unicamente contro quel sottodominio. Un sottodominio che supera lo 0,3% non declassa automaticamente il traffico transazionale sul dominio apex, e questa è una delle ragioni per cui la prassi standard è isolare il marketing su un sottodominio. (Si veda /glossary/email-deliverability.)
2. Gmail e Yahoo misurano in modo diverso. Gmail usa il tasso di click sul pulsante spam tra i destinatari che hanno aperto. Yahoo usa una metrica analoga nella propria interfaccia. Entrambi i numeri dovrebbero seguirsi entro ~0,05%; divergenze marcate indicano uno sbilanciamento di audience più che un problema del mittente.

Per ottenere visibilità, si iscriva ai Google Postmaster Tools (gratuito, richiede verifica DNS del dominio) e al Complaint Feedback Loop di Yahoo. Entrambi espongono numeri giornalieri di tasso di reclami. AcelleMail consuma il feed di reclamo a livello SES via webhook SNS (app/SendingServers/Webhooks/ComplaintReceived.php), che è la fonte di verità a livello di sending server. I tassi di Gmail / Yahoo sono post-delivery; quello SES è at-acceptance.

A rigore le regole del 2024 si applicano solo ai bulk sender — >5.000/giorno verso Gmail o Yahoo. Sotto quella soglia i requisiti sono "best practice" e non obbligatori.

Nella pratica, però, la distinzione è priva di sostanza. I mittenti sotto i 5.000 finiscono comunque in spam per mancanza di DMARC, mancanza di disiscrizione one-click, o tasso di reclami elevato. L'euristica applicata dai provider è in larga parte la stessa; la differenza è che sopra i 5.000 i provider La pubblicano in una coda "bulk sender" con automazioni più rigide, mentre sotto si finisce in un binario manual-review / engagement-driven. In entrambi i casi, ignorare le regole sotto i 5.000 produce una perdita misurabile di deliverability.

L'inquadramento corretto: le regole del 2024 hanno codificato quella che era già la soglia de facto presso i principali provider. Non hanno inventato nuovi requisiti; hanno reso espliciti e obbligatori i requisiti esistenti. Gli operatori self-hosted sotto i 5.000/giorno dovrebbero trattare quelle regole come la soglia operativa di riferimento, indipendentemente dal volume.

Tre pattern sono saltati in scala tra febbraio e marzo 2024 e continuano oggi a causare perdita misurabile di deliverability:

1. Forwarder-DMARC-fail. Gli operatori con mailing list che inoltravano la posta verso indirizzi personali degli iscritti (il classico pattern "list service") si sono visti rifiutare in massa la posta inoltrata. Il rimedio è riscrivere l'intestazione From sulla posta inoltrata (l'approccio ARC) oppure passare le liste a un invio diretto dal dominio della lista. Mailman 3 e il modulo lista di Postal supportano entrambi questa modalità.
2. Mittenti su CRM di terze parti. Inviare attraverso un relay SMTP agganciato a un CRM che firma con il dominio del CRM rompe l'allineamento DMARC, a meno che il CRM non pubblichi anche il proprio DKIM sotto il Suo sottodominio. SES, Mailgun, SparkPost e SendGrid lo supportano tutti; relay più vecchi o meno mainstream potrebbero non farlo.
3. Flussi transazionali non autenticati. "Mandiamo i reset password tramite Postfix sulla stessa macchina che fa girare l'app, senza DKIM" ha smesso di funzionare a qualsiasi volume significativo. Il rimedio è pubblicare chiavi DKIM per il dominio apex e configurare OpenDKIM sull'installazione Postfix — lavoro one-time che ripaga su tutto il traffico transazionale.

Le regole del 2024 si sono rivelate più significative di quanto sembrasse a prima vista. Non si sono limitate ad alzare l'asticella — l'hanno resa concreta e testabile. Sender Score, Talos, GlockApps, Postmark e i diversi vendor di monitoraggio della deliverability hanno incorporato i tre pilastri nei propri check nel giro di mesi. A metà 2025 l'intero ecosistema commerciale di tooling per la deliverability assumeva DMARC + disiscrizione one-click + tasso di reclami come precondizioni; i vecchi servizi del tipo "La aiutiamo a debuggare il Suo SPF" si sono aggiornati o ritirati silenziosamente.

Per gli operatori self-hosted in particolare, le regole del 2024 hanno accelerato uno spostamento già in corso: dall'"inviare qualunque cosa da ovunque" (la norma self-hosted degli anni 2010) verso "inviare solo posta autenticata, allineata, facilmente disiscrivibile, da un dominio la cui reputazione viene gestita attivamente". Si tratta di una soglia operativa più alta ma di uno stato stazionario a minor rischio. Gli strumenti di AcelleMail per lo stato stazionario — WarmupStrategy, BounceHandler, suppression list, adapter di verifica NeverBounce / ZeroBounce — erano già nel codebase pre-2024; ciò che è cambiato è che sono diventati necessari anziché opzionali.

Se non ha fatto un audit di compliance con le regole 2024 sul Suo dominio mittente negli ultimi sei mesi, oggi è una buona giornata per cominciare. La versione da cinque minuti: si invii un test, "Mostra originale" in Gmail, verifichi tre verdetti pass più l'intestazione List-Unsubscribe-Post: List-Unsubscribe=One-Click. Se tutto torna, è a posto. Altrimenti, il lavoro per arrivarci è ormai ben tracciato.