In breve
Quando le email del modulo non arrivano, il controllo parte da una prova riconoscibile e segue il percorso fino al destinatario. Occorre distinguere funzionamento del browser, elaborazione sul server, invio della notifica, coda e recapito. Mittente, autenticazione del dominio e filtri della casella sono verifiche separate. Identificatori e orari aiutano l'assistenza a ricostruire il problema senza esportare contenuti personali o condividere credenziali nei messaggi di supporto. La diagnosi resta documentata.
- Seguire una richiesta di prova dal browser alla casella finale, annotando gli esiti distinti.
- Verificare mittente e servizio effettivo di invio prima di intervenire sull'autenticazione del dominio.
- Fornire all'assistenza dati tecnici essenziali e controllare anche le richieste eventualmente registrate.
Creare una prova riconoscibile e delimitare il problema
Annota pagina, data, ora con fuso orario e messaggio mostrato dopo l'invio. Usa un recapito di prova controllato e un testo chiaramente riconoscibile, privo di dati di clienti. Verifica se il problema riguarda tutti i moduli, un solo servizio oppure una particolare casella destinataria.
Raccogli anche l'ultima modifica conosciuta: aggiornamento del sito, nuovo hosting, cambio del fornitore email o sostituzione del destinatario. È un indizio da controllare, non la prova della causa. Una cronologia precisa permette all'assistenza di confrontare eventi vicini nel tempo.
Evita decine di invii consecutivi: complicano la ricerca della prova e possono attivare limiti o protezioni. Se il contatto è temporaneamente inaffidabile, rendi visibile un recapito alternativo effettivamente presidiato, spiegando come utilizzarlo mentre viene verificato il problema.
Capire se il browser invia una richiesta o apre la posta
Un collegamento mailto apre il programma o servizio di posta scelto dall'utente: non è un invio gestito dal server del sito. Come spiega MDN sui collegamenti email, il messaggio deve poi essere composto e inviato nell'applicazione. L'apertura della finestra non dimostra alcun recapito.
Per un modulo vero, chiedi all'assistenza di controllare se parte la richiesta di rete e quale risposta riceve. La documentazione MDN sull'invio dei moduli distingue il trasferimento dei dati dalla loro elaborazione sul server.
Un campo non valido, uno script in errore o una protezione antispam possono fermare il percorso. Il tecnico deve verificare risposta e significato dell'esito, non limitarsi al colore verde del messaggio finale.
Verificare che il servizio del modulo elabori i dati
Il servizio che riceve la richiesta può appartenere al sito oppure a un fornitore esterno. Dopo la ricezione può validare i campi, registrare il contatto, preparare un'email o inoltrare i dati a un gestionale. Individua quali passaggi sono previsti nell'installazione reale.
Chiedi se esiste un identificatore della richiesta e se il sistema conserva i contatti indipendentemente dalla notifica. Quando questa registrazione è prevista, può permettere di recuperare richieste per cui l'email è fallita. Se non esiste, non dare per scontato che i messaggi precedenti siano recuperabili.
Il testo mostrato all'utente deve riflettere l'esito effettivo. Le indicazioni W3C sulle notifiche dei moduli aiutano a comunicare successo ed errori in modo comprensibile. Un controllo grafico del pulsante, da solo, non verifica il trattamento della richiesta.
Identificare il servizio che deve inviare la notifica
Chiarisci se l'email viene inviata attraverso il server dell'hosting, una connessione SMTP autenticata oppure l'API di un servizio dedicato. Il gestore del sito e quello della posta possono essere soggetti differenti. Sapere chi invia evita di aprire una segnalazione al fornitore che gestisce soltanto la casella finale.
Per SMTP, l'assistenza verifica connessione, autenticazione e configurazione richiesta dal fornitore; per un'API controlla autorizzazioni, risposta e stato del servizio. Limiti di invio, account sospesi o parametri modificati sono possibili punti di controllo, da confermare attraverso gli esiti registrati.
Non inserire credenziali in email, screenshot o ticket pubblici. Chiedi al tecnico di usare gli accessi già autorizzati o una modalità di condivisione appropriata. Se viene sostituita una configurazione, conserva il contesto della modifica e ripeti la stessa prova riconoscibile.
Distinguere il mittente della notifica da chi ha compilato il modulo
Un'impostazione da verificare è il campo From, cioè il mittente visibile. Per una notifica generata dal sito è opportuno utilizzare un indirizzo di un dominio controllato e autorizzato presso il servizio di invio. Inserire qui qualsiasi indirizzo digitato dal visitatore può creare incoerenze con l'autenticazione.
Il recapito del visitatore può essere gestito come Reply-To, dopo la validazione: indica dove proporre la risposta, secondo il formato dei messaggi definito dalla RFC 5322. Questa distinzione consente al personale di rispondere alla persona senza attribuire al sito un'identità email che non controlla.
Esempio ipotetico: la notifica parte dall'indirizzo verificato dell'azienda, mostra il nome del modulo nell'oggetto e propone come destinazione della risposta il recapito validato del richiedente. Il tecnico controlla entrambi i passaggi.
Controllare SPF, DKIM e DMARC sul flusso effettivo
L'autenticazione riguarda il dominio e il servizio che inviano davvero il messaggio. Le linee guida di Gmail per i mittenti spiegano il ruolo di questi controlli nel recapito, senza garantire l'arrivo in posta principale.
| Controllo | Che cosa verifica o comunica |
|---|---|
| SPF | Quali server sono autorizzati per il dominio usato nell'identità SMTP verificata. |
| DKIM | Una firma associata a un dominio e alle parti firmate del messaggio. |
| DMARC | Allineamento del dominio From con un esito SPF o DKIM valido e indicazioni di trattamento e report. |
I riferimenti tecnici sono SPF, DKIM e DMARC. Fai verificare l'allineamento sul messaggio concreto. Non copiare record DNS generici né irrigidire le regole senza avere censito gli altri invii aziendali: sito, caselle, gestionali e newsletter possono utilizzare servizi diversi.
Seguire coda, accettazione e possibili rifiuti
Una notifica può essere accettata dal servizio di invio e restare in coda, essere rinviata oppure ricevere un rifiuto dal sistema destinatario. Lo standard SMTP distingue accettazione e responsabilità di inoltro dagli errori temporanei o permanenti. L'accettazione da parte di un intermediario non significa che una persona abbia ricevuto e letto l'email.
Chiedi stato della prova, identificatore del messaggio e codice d'errore, quando disponibili. Se l'esito indica un rinvio, occorre capire chi gestisce i tentativi successivi; se indica un rifiuto, la spiegazione può indirizzare il controllo verso indirizzo, autorizzazioni o regole del destinatario.
Verifica anche dove arrivano gli avvisi di mancato recapito. Un indirizzo tecnico non presidiato può nascondere informazioni utili. Evita di cancellare code o reinviare in massa le notifiche prima di avere chiarito lo stato delle singole richieste.
Controllare la casella finale e le regole del destinatario
Se il servizio registra il passaggio al sistema destinatario, verifica la casella dalla sua interfaccia web, quando disponibile. Controlla posta indesiderata, quarantena aziendale, filtri, inoltri e spazio disponibile. Distingui il problema del programma sul computer da quello della casella: un messaggio può essere presente sul server e non comparire nel dispositivo utilizzato.
Una prova verso una seconda casella controllata, concordata con l'assistenza, aiuta a delimitare il problema. Un esito positivo su un destinatario non dimostra però che tutti gli altri accettino lo stesso flusso. Non disattivare le protezioni antispam complessive per risolvere una singola notifica.
Se il recapito tecnico funziona ma i contatti restano senza seguito, il problema può riguardare assegnazione e gestione. La guida sulle visite che non diventano contatti aiuta a esaminare il percorso più ampio.
Consegnare all'assistenza una segnalazione utile
Prepara una segnalazione sintetica che permetta di ritrovare la prova. Conserva soltanto i dati tecnici necessari, con accessi e tempi di conservazione definiti: è coerente con i principi richiamati dal Garante.
- URL del modulo e orario della prova, compreso il fuso.
- Dispositivo, browser e testo dell'esito visualizzato.
- Identificatore della richiesta o del messaggio, se disponibile.
- Servizio di invio e destinatario interessato, comunicati nel canale appropriato.
- Codice d'errore e cambiamenti recenti pertinenti.
- Verifiche già svolte, con risultato distinto per ogni passaggio.
Non allegare esportazioni complete di log con messaggi di clienti, token o password. Dopo la correzione verifica ricezione effettiva e possibilità di rispondere. Nella manutenzione del sito concorda controlli periodici; nella misurazione dei contatti mantieni distinta l'interazione registrata dall'esito reale della richiesta.
Se anche i preventivi e le risposte spediti dalla casella aziendale finiscono nella posta indesiderata, segui il percorso dedicato alle email aziendali nello spam: aiuta a distinguere un problema del modulo da un problema del dominio o del servizio di posta.
Fonti e approfondimenti
Riferimenti ufficiali per approfondire i criteri descritti nella guida.
- MDN: invio ed elaborazione dei dati dei moduli
- MDN: collegamenti mailto
- W3C WAI: notifiche nei moduli
- Gmail: linee guida per i mittenti di email
- RFC 5321: SMTP, consegna ed errori
- RFC 5322: formato dei messaggi e Reply-To
- RFC 7208: Sender Policy Framework
- RFC 6376: firme DKIM
- RFC 7489: DMARC e allineamento
- Garante Privacy: principi fondamentali del trattamento
La fotografia di apertura è un’immagine illustrativa generata con AI.