Una prenotazione non finisce quando il cliente paga. Finisce quando legge la conferma.

Immagini la scena: un venerdì di dicembre, una famiglia di Londra prenota una suite in un hotel di Gstaad dal suo sito. Il pagamento va a buon fine. La conferma parte dal server del sito con l’indirizzo dell’hotel, ma quel server non è tra quelli autorizzati a inviare posta a suo nome. Gmail la mette nello spam. La famiglia non la trova. Il sabato scrive alla reception per chiedere se la prenotazione esiste. La domenica, per sicurezza, prenota anche un altro hotel tramite una piattaforma.

Si investe molto perché il cliente prenoti sul sito. Quasi nulla perché arrivi l’e-mail che lo conferma. Eppure quell’e-mail è la prima cosa che il cliente riceve da Lei dopo aver pagato.

Che cosa esige Gmail.

Dal 1° febbraio 2024 Google esige da chiunque invii posta ad account Gmail personali l’autenticazione SPF o DKIM, record DNS diretti e inversi validi, una connessione cifrata e un tasso di spam inferiore allo 0,3%. A chi invia circa 5000 messaggi al giorno o più chiede inoltre SPF e DKIM insieme, un record DMARC, anche con la politica più blanda, un dominio del mittente allineato a quello autenticato e, per le e-mail di marketing, la disiscrizione con un clic gestita entro 48 ore.

Da novembre 2025, secondo Google, Gmail applica queste regole con più rigore: i messaggi che non le rispettano subiscono rifiuti temporanei e definitivi. Quelli non autenticati possono finire nello spam o essere respinti con un codice di errore. Le regole riguardano la posta che arriva agli account Gmail personali, cioè proprio dove si trovano di solito i Suoi pazienti, i Suoi ospiti e le famiglie che Le scrivono.

Il dettaglio che quasi nessuno legge.

Per Gmail la soglia di 5000 messaggi al giorno si conta per dominio principale: gli invii di hotel.ch e quelli di news.hotel.ch si sommano. E chi la raggiunge una sola volta viene classificato come mittente massivo per sempre. Google lo dice chiaramente: questo stato non scade, e cambiare il modo di inviare non lo cambia.

In altre parole, una sola grande newsletter agli ex clienti può cambiare in modo definitivo le regole che devono rispettare le conferme di prenotazione inviate dal Suo sito. C’è una seconda sfumatura utile. Le conferme di prenotazione e di modulo sono esentate dalla disiscrizione con un clic, perché sono e-mail transazionali. Non sono esentate dall’autenticazione.

Che cosa non so.

Google non pubblica quante e-mail respinge per queste regole, e io non ho una cifra affidabile su quante conferme si perdano in cliniche, hotel o agenzie immobiliari. Quello che so è che il guasto è silenzioso. Chi invia non vede la cartella spam di chi riceve, e il cliente telefona di rado per dire che non ha ricevuto nulla. Sospetto che, il più delle volte, semplicemente non torni.

Un’e-mail che non arriva non segnala alcun errore. Lascia un silenzio.

La mia posizione.

Credo che l’e-mail di conferma faccia parte dell’esperienza e non sia un dettaglio tecnico da lasciare al fornitore dell’hosting. Ogni sistema che scrive a nome della Sua azienda, che sia il sito, il motore di prenotazione, il CRM, lo strumento per le newsletter o il software della clinica, deve essere autorizzato, e qualcuno deve leggere i rapporti che DMARC rimanda. Sul mio dominio, DMARC è impostato sulla politica più severa, quella che chiede di respingere tutto ciò che non è autenticato. Una prenotazione non finisce quando il cliente paga. Finisce quando legge la conferma.

Che cosa verificherei.

• Chi invia a Suo nome. Il sito, il motore di prenotazione, il CRM, lo strumento per le newsletter e il gestionale.
• SPF, DKIM e DMARC. Se esistono e coprono tutti questi mittenti, non solo la casella principale.
• Il mittente visibile. Che l’indirizzo che vede il cliente sia del Suo dominio e coincida con quello autenticato.
• Il volume. Se Le è mai capitato di inviare circa 5000 e-mail in un giorno ad account Gmail, contando i sottodomini.
• La prova reale. Una prenotazione di prova verso un account Gmail personale e uno Outlook, guardando anche nella cartella spam.

Da dove cominciare.

1. Questa settimana

   Fare la prova

   Prenotare o scrivere dal sito con un account personale e vedere dove arriva la conferma.

2. Questo mese

   Fare l’inventario

   L’elenco di tutti i sistemi che inviano posta con il Suo dominio, con il rispettivo responsabile.

3. Questo trimestre

   Autenticare e sorvegliare

   SPF, DKIM e DMARC per ogni mittente, e rapporti DMARC che qualcuno legge davvero.

4. A ogni cambio

   Ripetere la prova

   Ogni volta che cambia fornitore, motore di prenotazione o strumento per le newsletter.

Faccia a memoria l’elenco di tutto ciò che invia email a nome della Sua azienda: il sito, il motore di prenotazione, la fatturazione, la newsletter, il CRM, quel modulo che qualcuno ha installato due anni fa. Poi lo confronti con quello del Suo team tecnico.

Se i due elenchi non coincidono, forse ha già un indizio sul perché alcuni clienti dicono di non aver mai ricevuto la conferma. E resta un dubbio peggiore: quanti non l’hanno detto?

Se vuole che verifichi che cosa succede alle email che il Suo sito invia a Suo nome, cominci dalla Diagnosi strategica. Quali sistemi possono scrivere a nome della Sua azienda lo decide la Sua direzione con il Suo team tecnico, non un designer.