Le email continuavano a sparire. Abbiamo spostato la posta del negozio su Google Workspace: i dettagli hanno fatto la differenza

La segnalazione è arrivata come arrivano sempre queste segnalazioni: vaga. Alcuni clienti non ricevevano mai le nostre risposte. Chi usava Gmail non aveva problemi. Ogni tanto un messaggio tornava indietro come non recapitato. E un fornitore, un grossista da cui il negozio si rifornisce, riusciva a scrivere al negozio senza problemi, ma il negozio non riusciva a rispondergli.

Il negozio è una piccola attività specializzata di cui ci occupiamo. Un'unica casella aziendale condivisa con anni di storico, alcune persone che la leggono da computer e telefono e un negozio online che invia le conferme d'ordine dallo stesso indirizzo. Nessuno di loro vuole doversi preoccupare delle email. Vogliono che arrivino.

Questo è il racconto, anonimizzato, di come abbiamo risolto il problema: i passaggi seguiti, le insidie evitate e i controlli successivi che consigliamo per qualsiasi migrazione di questo tipo. La versione breve: abbiamo spostato la casella su Google Workspace e lasciato il sito sul suo hosting; sono cambiate solo le impostazioni di posta. La versione lunga è quella che vale la pena leggere, perché il grosso del lavoro si è concentrato sui dettagli che richiedevano più attenzione: il passaggio dei DNS, decine di migliaia di vecchi messaggi, la cartella Posta inviata (Sent) e le notifiche del negozio.

Tutti i controlli erano superati, ma le email continuavano a sparire

La prima cosa che si controlla è l'autenticazione, e così abbiamo fatto anche noi. SPF superato. DKIM superato. DMARC superato, con la policy p=none, che chiede ai destinatari di non intervenire in caso di mancato superamento di DMARC. Sulla carta il dominio era configurato correttamente, eppure i problemi duravano da mesi nonostante quei controlli superati.

La risposta era un livello più in là. Tutto ciò che il negozio aveva, i DNS del dominio, il sito e la casella di posta, si trovava presso un unico provider di hosting condiviso. La posta in uscita non partiva dal server del negozio. Passava dal relay di uscita condiviso del provider, lo stesso piccolo gruppo di server usato da molti altri clienti. E l'indirizzo del relay da cui partivano i messaggi del negozio era presente in una blocklist antispam pubblica.

Il comportamento delle consegne era coerente con quella presenza in lista: i destinatari che consultano queste liste rifiutano o spostano nello spam la posta proveniente da un indirizzo segnalato, per quanto sia firmata correttamente, mentre Gmail si basa soprattutto sui propri dati di reputazione. Non abbiamo mai visto il messaggio di rifiuto del grossista, ma il suo sistema si comportava esattamente come un filtro che usa quella lista.

L'autenticazione non è mai stata il problema. Lo era la reputazione del relay condiviso.

Se vuoi fare la stessa diagnosi sul tuo dominio, questi comandi coprono buona parte delle verifiche. L'indirizzo IP si ricava dalla riga Received: che il server destinatario ha aggiunto a un messaggio inviato a un tuo indirizzo Gmail (aprilo, poi scegli Mostra originale (Show original)).

# Chi riceve la tua posta e che cosa dicono SPF e DMARC?
dig +short MX example-shop.com
dig +short TXT example-shop.com | grep -i spf
dig +short TXT _dmarc.example-shop.com

# Il server che ha inviato il tuo messaggio è in una blocklist?
# Solo un esempio: inverti l'IP reale di invio, 203.0.113.25 diventa 25.113.0.203
dig 25.113.0.203.bl.spamcop.net A +noall +comments +answer
# status NOERROR con 127.0.0.2 = presente in lista; status NXDOMAIN = non presente al momento;
# SERVFAIL, REFUSED o un timeout = nessuna risposta, prova la ricerca sul sito della lista

Un'avvertenza pratica: alcune blocklist, tra cui Spamhaus, rifiutano le richieste che passano dai grandi resolver DNS pubblici e rispondono invece con un codice di errore. E una ricerca verifica una sola lista in un dato momento, non la tua capacità complessiva di recapitare la posta.

Perché abbiamo spostato la posta, e soltanto la posta

La posta elettronica e l'hosting del sito sono servizi separati che vengono semplicemente venduti insieme. Trasferire un sito è un progetto che comporta il rischio di interruzioni, il riempimento della cache e molti elementi da coordinare. Trasferire la posta richiede una modifica ai DNS e un'importazione. Il sito del negozio funzionava, quindi lo abbiamo lasciato sul suo hosting e abbiamo risolto il problema che causava davvero il danno.

Abbiamo valutato quattro opzioni:

Consiglieremmo entrambe le grandi piattaforme. Abbiamo scelto Workspace per un motivo semplice: le persone che usano la casella conoscevano già Gmail, e meno cose deve imparare un piccolo team, prima il cambiamento entra nella routine.

Abbiamo anche mantenuto la casella aziendale come utente Workspace autonomo, anziché unirla all'account privato di qualcuno. Un indirizzo aziendale che vive nel Gmail privato di una persona è difficile da passare ad altri, da sottoporre a verifica e da riprendere quando quella persona se ne va. Se più persone hanno bisogno di accedere ciascuna con il proprio account, anziché con uno condiviso, la delega di Gmail permette ai singoli account di lavorare nella casella condivisa. Abbiamo trattato il tema degli accessi nell'articolo su che cosa succede quando un dipendente se ne va ma i suoi accessi restano.

Prima di toccare i DNS: la preparazione

Il passaggio in sé richiede pochi minuti. È la preparazione a decidere se quei minuti saranno tranquilli o movimentati.

• Salva una copia dell'intera zona DNS. Esportala o annota ogni record, così potrai ripristinare quelli vecchi esattamente com'erano. Ricorda che tornare indietro cambia soltanto la destinazione della nuova posta: tutto ciò che nel frattempo è stato consegnato a Google rimane lì.
• Elenca tutti gli indirizzi che ricevono posta. Caselle, alias, inoltri, gruppi, regole catch-all. Quando il record MX punta a Google, ciascuno di questi deve esistere anche lì, altrimenti la posta viene respinta. Questo negozio aveva una sola casella e nient'altro, quindi l'elenco era breve.
• Elenca tutto ciò che invia posta a nome del tuo dominio. Client di posta su computer e telefoni, negozio online (conferme d'ordine, modulo di contatto, reimpostazione delle password), strumenti di fatturazione, account sui marketplace. Tutto deve continuare a funzionare dopo il passaggio.
• Abbassa il TTL del record MX a 300 secondi con un giorno di anticipo. Il record MX del negozio aveva un TTL di quattro ore: gli altri server di posta potevano quindi conservare in memoria la vecchia destinazione per quattro ore dopo la modifica.
• Aggiungi il record TXT di verifica di Google e completa l'attivazione di Gmail nella Console di amministrazione (Admin console). Il record di verifica si affianca al record SPF. Un dominio può avere molti record TXT, ma solo uno può essere un record SPF.
• Attiva la verifica in due passaggi per l'amministratore Workspace e per l'utente della casella, e conserva i codici di backup in un posto sicuro, prima che la posta inizi ad arrivare.

Il passaggio, record per record

Queste sono le modifiche, con i nomi del negozio sostituiti da segnaposto.

Nel record SPF mantieni tutti i meccanismi ancora necessari ai mittenti attivi e aggiungi accanto l'include di Google; un solo record SPF per nome e non più di dieci ricerche DNS complessive, contando tutti gli include.

Due dettagli meritano un paragrafo a parte. Primo: la chiave DKIM supera i 255 caratteri che può contenere una singola stringa di testo DNS. Deve comunque restare un unico record TXT: alcuni pannelli DNS la dividono automaticamente in più stringhe tra virgolette all'interno del record, altri richiedono che lo faccia tu. Confronta il valore pubblicato con quello nella Console di amministrazione, carattere per carattere, poi premi Avvia autenticazione (Start authentication) in Applicazioni (Apps), Google Workspace, Gmail, Autentica email (Authenticate email). Su un account Workspace appena creato, Google può richiedere un giorno o più prima di permetterti di generare la chiave.

Secondo: non fidarti del tuo resolver per capire se il passaggio è riuscito. Interroga direttamente ogni nameserver autoritativo:

# Chiedi a ogni nameserver del dominio quale MX restituisce in questo momento
for ns in $(dig +short NS example-shop.com.); do
  printf '%s\n' "$ns"
  dig @"$ns" example-shop.com. MX +norecurse +noall +comments +answer
done
# Cerca il flag "aa" (risposta autoritativa) e il nuovo MX in ogni blocco

Quando lo abbiamo fatto, un nameserver ha risposto con Google nel giro di pochi secondi. Gli altri tre hanno continuato a restituire il vecchio MX per circa venti minuti, con lo stesso numero seriale di zona. Non abbiamo mai scoperto perché. Se avessimo controllato solo il nostro resolver, avremmo considerato il lavoro concluso senza accorgerci di venti minuti di posta ancora diretta al vecchio server.

Un nameserver ha risposto con Google in pochi secondi. Gli altri tre hanno impiegato circa venti minuti.

Metti in conto anche una coda di consegne. I server di posta che hanno cercato il vecchio MX prima della modifica, o che hanno messaggi in coda da ritentare, possono continuare a consegnare alla vecchia casella per un po'. Mantieni quindi entrambe le caselle attive durante la sovrapposizione, controlla quella vecchia e ripeti l'importazione finché non vi arriva più nulla di nuovo. Sui pannelli di hosting come cPanel controlla anche l'impostazione di routing della posta del dominio: se l'account di hosting pensa ancora di gestirne la posta, i messaggi inviati dal sito al tuo stesso indirizzo possono essere consegnati localmente alla vecchia casella.

Spostare 40.000 messaggi senza perderne uno

La vecchia casella conteneva 39.840 messaggi in 27 cartelle, circa 13 GB in tutto, accumulati negli anni: fatture dei fornitori, ordini dai marketplace, avvisi dei corrieri, conversazioni con i clienti. Perderne anche solo una parte era fuori discussione, così come passare una settimana con cartelle importate a metà.

L'importazione è la parte facile. È il confronto finale che permette di dire che non si è perso nulla.

Abbiamo iniziato con lo strumento di migrazione dei dati integrato di Google, che si collega al vecchio server via IMAP e copia tutto. Funziona, ma su questa casella ha presentato tre problemi:

• Velocità. Circa 2.400 messaggi all'ora, che per questa casella significavano oltre sedici ore. Per quanto abbiamo potuto osservare, recuperava un solo messaggio per sessione IMAP, e lo strumento non offre impostazioni per la velocità.
• Lacune. Diverse cartelle segnalavano un "crawl failure" con un errore interno di sincronizzazione, e il consiglio era di eseguire un'altra migrazione più avanti.
• Date sbagliate. 925 messaggi provenivano da un mittente il cui sistema di posta scrive un'intestazione Date non valida (secondi senza lo zero iniziale e nessun fuso orario, per esempio 2 Apr 2024 18:36:4), e altri due non avevano proprio l'intestazione Date. La migrazione assegnava loro la data e l'ora dell'importazione, così messaggi vecchi di anni apparivano in cima alla posta in arrivo come se fossero arrivati quella mattina.

Abbiamo quindi completato il lavoro con un nostro strumento di importazione, basato sull'API di importazione di Gmail, di cui controllavamo ogni passaggio:

• Sola lettura all'origine. La vecchia casella veniva aperta in sola lettura e ogni messaggio recuperato senza impostare il flag "seen". Nulla cambiava sul vecchio server, che rimaneva quindi una valida soluzione di ripiego.
• Saltare ciò che era già arrivato. Il Message-ID di ogni messaggio veniva confrontato con quelli già presenti in Gmail, così lo strumento non copiava ciò che la migrazione di Google aveva già trasferito.
• Le cartelle diventano etichette. Una vecchia cartella come INBOX.Invoices diventava l'etichetta Gmail Invoices, così il team ritrovava tutto dove si aspettava.
• Possibilità di riprendere. Un file di stato registrava l'avanzamento, così dopo un'interruzione si ripartiva dal punto raggiunto, mai da zero.
• La data del messaggio. I messaggi con un'intestazione Date valida prendevano posto nella cronologia in base a quella, non al giorno dell'importazione.

Un altro dettaglio che si nota il primo giorno: i contrassegni. I messaggi speciali, quelli con la stella, non sono passati con l'importazione, e un team che usa le stelle da anni come elenco di cose da fare se ne accorge subito. Abbiamo abbinato i 530 messaggi contrassegnati nella vecchia casella alle loro copie in Gmail e rimesso le stelle.

La cartella Posta inviata richiedeva un piano a sé

Dopo il recapito, questo era l'aspetto che stava più a cuore al titolare del negozio. Con il passaggio a Gmail, nella Posta inviata si sono presentati tre problemi distinti.

1. Gmail decideva che cosa considerare inviato

In questa casella, ogni messaggio importato che aveva come mittente l'indirizzo della casella stessa appariva in Posta inviata, e in seguito abbiamo osservato lo stesso comportamento con le copie ricevute attraverso il relay. Dopo l'importazione, questo comprendeva anni di notifiche automatiche del negozio, perché le conferme d'ordine erano sempre partite dall'indirizzo aziendale. All'improvviso Posta inviata conteneva circa 1.950 messaggi che nessuno aveva scritto, mescolati alle vere risposte del team.

Abbiamo identificato i messaggi generati dal negozio tramite le intestazioni del software di invio e li abbiamo spostati tutti e 1.959 da Posta inviata alle etichette di competenza, con il comando IMAP di spostamento. In questa casella, spostare un messaggio fuori dalla cartella Posta inviata ne rimuoveva l'etichetta Posta inviata, proprio ciò che ci serviva; prima lo abbiamo provato su un piccolo gruppo di messaggi. Posta inviata è tornata a contenere soltanto email scritte dalle persone.

Gmail archiviava le notifiche del negozio in Posta inviata. Spostarle ha restituito al team una cartella utilizzabile.

2. Le nuove email del negozio l'avrebbero riempita di nuovo

Il modo più immediato per far inviare un negozio online attraverso Google è dargli le credenziali della casella su smtp.gmail.com. Funziona, e da quel giorno ogni conferma d'ordine finisce di nuovo in Posta inviata. Il negozio usa invece il servizio di relay SMTP di Google (smtp-relay.gmail.com), che un amministratore configura nella Console di amministrazione in Applicazioni, Google Workspace, Gmail, Routing:

• Mittenti consentiti (Allowed senders): Solo indirizzi nei miei domini (only addresses in my domains)
• Richiedi autenticazione SMTP (Require SMTP authentication)
• Richiedi crittografia TLS (Require TLS encryption)

L'impostazione di amministrazione "Comprehensive mail storage", in Gmail, Conformità (Compliance), era disattivata in questo account, e i messaggi inoltrati dal relay non apparivano nella Posta inviata del mittente. Attivarla salva copie della posta inoltrata dal relay nelle caselle degli utenti; se hai obblighi di conservazione, questa impostazione e Google Vault sono gli strumenti da valutare.

3. Ma il team vuole comunque vedere che cosa ha inviato il negozio

Una Posta inviata pulita va bene finché un cliente non chiama per chiedere che cosa diceva la sua conferma. Così, grazie a un piccolo intervento di codice personalizzato nel negozio, ogni messaggio inviato correttamente genera ora una copia diretta a un indirizzo con suffisso più della casella principale (office+shop@). La copia proviene da un indirizzo separato del dominio (shop@) che non corrisponde ad alcuna casella. Il nome visualizzato elenca i destinatari originali ("A: customer@...") e il Reply-To punta al cliente, così la risposta va alla persona giusta.

Un filtro Gmail su deliveredto:office+shop@example-shop.com esclude la copia dalla Posta in arrivo (Inbox), la segna come letta e applica un'etichetta chiamata Posta inviata - negozio. Perché un indirizzo mittente diverso? Per il punto 1: in questa casella, le copie provenienti dall'indirizzo della casella stessa finivano in Posta inviata anche quando arrivavano attraverso il relay. Anche le notifiche che il negozio invia al proprio personale partono da shop@, così finiscono in Posta in arrivo, dove qualcuno le leggerà davvero.

C'è un limite da conoscere: Gmail non permette di inserire un'etichetta dentro Posta inviata. Posta inviata - negozio si trova accanto, nell'elenco delle etichette, una soluzione che il titolare del negozio ha accettato una volta chiarito il motivo.

Client di posta per computer

Alcune impostazioni hanno fatto la differenza tra "Thunderbird è lento da quando abbiamo cambiato" e un client che funziona bene:

• Sincronizza meno. Gmail mostra ogni etichetta come cartella IMAP, quindi uno stesso messaggio può essere scaricato più volte. Nelle impostazioni di Gmail, in Etichette (Labels), togli la spunta a "Mostra in IMAP" (Show in IMAP) per le cartelle che il team non usa sul computer, come Importanti (Important). Attenzione a Tutti i messaggi (All Mail): i messaggi archiviati si trovano soltanto lì, quindi, se il team archivia in Gmail, mantieni visibile Tutti i messaggi e limita invece il download offline del client.
• Non lasciare che il client salvi una seconda copia della posta inviata. Per gli account che inviano attraverso Gmail, Gmail conserva già ogni messaggio inviato. Verifica che un messaggio di prova appaia in Posta inviata, poi disattiva il salvataggio della copia da parte del client, che altrimenti carica ogni messaggio una seconda volta.
• Dismetti il vecchio account nel client. Rimuovilo dopo l'ultima importazione, o almeno rinominalo così nessuno risponde per abitudine dal vecchio server.

La posta del negozio, nelle impostazioni di PrestaShop

Qualunque sia la piattaforma del tuo negozio, le impostazioni del relay hanno lo stesso significato. In PrestaShop 1.7 e 8 le trovi in Parametri avanzati, E-mail (Advanced Parameters, E-mail); le diciture possono variare leggermente tra le versioni:

L'indirizzo email del negozio, configurato in Parametri negozio (Shop Parameters), deve appartenere al tuo dominio, altrimenti il relay lo rifiuta. Invia l'email di prova dalla stessa pagina di impostazioni, aprila in Gmail, scegli Mostra originale e cerca tre esiti positivi: SPF, DKIM firmato con il tuo dominio e DMARC. La copia di archivio descritta sopra non fa parte di queste impostazioni: per questo negozio è servito codice personalizzato, e PrestaShop non lo fa di serie. Per un quadro più ampio delle impostazioni di posta di PrestaShop, leggi la nostra guida alla configurazione email in PrestaShop: SMTP, Gmail ed email transazionali.

Dopo il passaggio: chiudere i vecchi accessi

Una migrazione è finita quando nulla dipende più dal vecchio sistema e nessuno può usarlo per sbaglio. Questa è la checklist che seguiamo dopo un trasferimento come questo:

• Rendi SPF più restrittivo quando alcuni giorni tranquilli confermano che nulla invia più attraverso il vecchio server: rimuovi l'include del vecchio provider.
• Conserva un'esportazione indipendente della vecchia casella prima di disdire il vecchio servizio e assegna alla vecchia casella una password lunga e casuale, così nessuno continua a usarla per abitudine.
• Revoca tutte le credenziali temporanee usate per il trasferimento: password per le app di importazione, client API, token dell'hosting.
• Assicurati che i report DMARC arrivino davvero (il record deve contenere un indirizzo per i report), leggili per alcune settimane, poi passa dalla policy p=none a quarantine.
• Valuta Google Postmaster Tools per monitorare il tasso di spam e la reputazione su Gmail. Un mittente con volumi ridotti potrebbe trovarci pochi dati, quindi continua a controllare i mancati recapiti e ciò che ti riferiscono i destinatari.
• Documenta dove si trova tutto: DNS, amministratore Workspace, impostazioni del relay, filtri. La prossima persona che dovrà metterci mano te ne sarà grata, anche se sarai tu fra due anni.

Il risultato

Ora la posta del negozio parte dall'infrastruttura di Google, firmata con il dominio del negozio. SPF, DKIM e DMARC sono superati, il grossista riceve di nuovo le risposte e le segnalazioni di mancato recapito sono cessate. L'unico messaggio respinto nei primi giorni dopo il passaggio è stato un'email di conferma dell'account diretta a un indirizzo falso che un bot aveva inserito nel modulo di registrazione: un mancato recapito che è giusto ricevere.

La posta in arrivo del team si presenta come prima, con ogni vecchio messaggio dove se lo aspettano. Posta inviata contiene ciò che hanno scritto le persone. Le notifiche del negozio hanno una propria etichetta, a un clic di distanza quando chiama un cliente.

E una nota di trasparenza: il primo giorno, i nostri stessi messaggi di prova alla nuova casella sono finiti in Spam. Provenivano da un nostro piccolo server con un'autenticazione impeccabile e pochissimo storico di invio. Non possiamo conoscere le ragioni di Gmail, ma lo storico ridotto è quella più probabile, ed è la stessa lezione di tutta questa storia: superare l'autenticazione non equivale a essere considerati affidabili.

Domande frequenti

Fonti

• Google: configurare i record MX per Google Workspace
• Google: instradare i messaggi del relay SMTP in uscita via Google
• Google: limiti di invio Gmail in Google Workspace
• Google: attiva DKIM
• Google: archivio email completo
• API Gmail: importare messaggi