Quando le email finiscono nello spam, la causa non è quasi mai un solo parametro. Bisogna controllare autenticazione del dominio, reputazione, modalità di invio, contenuto, volume, destinatari e risposta del provider. SPF, DKIM e DMARC sono fondamentali, ma non garantiscono da soli che ogni messaggio venga inserito nella Posta in arrivo.
Gmail, Outlook e gli altri provider valutano numerosi segnali prima di accettare e classificare un messaggio. Lo stesso dominio può consegnare correttamente a un destinatario e finire nello spam presso un altro, perché cambiano cronologia dei contatti, regole personali, reputazione percepita, contenuto e infrastruttura di ricezione.
Questa guida mostra come diagnosticare il problema senza modificare record DNS a caso e senza inviare ripetutamente lo stesso messaggio durante i test. Quando le email finiscono nello spam, la procedura deve partire dall’esito reale e dalle intestazioni.
Prima distinzione: spam, rifiuto o mancata consegna
Prima di intervenire identifica l’esito reale:
| Esito | Che cosa significa | Primo controllo |
|---|---|---|
| Messaggio nello spam | Il server lo ha accettato ma lo ha classificato come indesiderato | Autenticazione, reputazione, contenuto e comportamento del destinatario |
| Messaggio rifiutato | Il server remoto non lo ha accettato | Codice SMTP e testo completo dell’errore |
| Messaggio differito | La consegna è stata rimandata e verrà ritentata | Track Delivery e motivo temporaneo |
| Messaggio accettato ma non visibile | Può trovarsi in spam, quarantena, regole o cartelle automatiche | Ricerca completa nella casella destinataria |
| Messaggio non presente nei log | Il sito o il client potrebbe non averlo affidato al server | Configurazione SMTP, log applicativo e Track Delivery |
Per ricostruire la consegna consulta Track Delivery in cPanel. Una risposta SMTP positiva dimostra che il server remoto ha accettato il messaggio, ma non garantisce la cartella finale scelta dal provider.
Controlla SPF, DKIM e DMARC
L’autenticazione consente al destinatario di verificare se il messaggio proviene da un sistema autorizzato per il dominio visualizzato nel mittente.
- SPF elenca i server autorizzati a inviare per il dominio usato nel percorso SMTP;
- DKIM aggiunge una firma crittografica verificabile tramite DNS;
- DMARC controlla l’allineamento con il dominio visibile nel campo From e definisce una policy.
Apri cPanel → Email → Email Deliverability e verifica che non siano segnalati problemi. Segui la guida Email Deliverability in cPanel e, per DMARC, DMARC: come configurarlo senza bloccare le email.
Non creare un secondo record SPF. Un dominio deve pubblicare un solo record SPF, nel quale vanno riunite le sorgenti autorizzate. Due record SPF separati possono produrre un errore permanente.
Verifica tutte le sorgenti che inviano per il dominio
Molte configurazioni risultano corrette per la Webmail ma non per il sito, il gestionale o la piattaforma newsletter. Elenca ogni sorgente reale:
- Webmail e client configurati sul server Xlogic;
- moduli di contatto WordPress;
- e-commerce e notifiche degli ordini;
- CRM e gestionali;
- servizi di fatturazione;
- piattaforme newsletter;
- server VPS o applicazioni esterne;
- inoltri e mailing list.
Ogni sorgente deve essere autorizzata correttamente e deve firmare o allineare il messaggio. Un servizio esterno dimenticato può abbassare il tasso di autenticazione e rendere difficile applicare una policy DMARC restrittiva.
Reputazione del dominio e dell’indirizzo IP
I provider costruiscono una reputazione nel tempo. Un dominio nuovo, inattivo per mesi o improvvisamente usato per molti messaggi può essere trattato con prudenza. Anche segnalazioni spam, destinatari inesistenti, invii a liste acquistate e picchi improvvisi sono segnali negativi.
La reputazione non si corregge cambiando continuamente oggetto o record DNS. Occorre:
- inviare solamente a destinatari che si aspettano il messaggio;
- rimuovere indirizzi inesistenti e contatti non più attivi;
- aumentare gradualmente i volumi;
- mantenere regolarità negli invii;
- evitare segnalazioni e reclami;
- usare un processo di disiscrizione chiaro per comunicazioni promozionali;
- separare, quando opportuno, posta transazionale e newsletter.
Su un hosting condiviso non bisogna utilizzare script generici per campagne massive. Per newsletter e grandi volumi è preferibile una piattaforma specializzata che gestisca reputazione, disiscrizioni, bounce e conformità.
Contenuto e struttura del messaggio
Non esiste una lista universale di parole vietate. I filtri analizzano il messaggio nel suo insieme e il comportamento storico. Alcuni elementi aumentano però il rischio:
- oggetto ingannevole o non coerente con il contenuto;
- messaggio composto quasi esclusivamente da un’immagine;
- link abbreviati o domini diversi e poco riconoscibili;
- allegati eseguibili o archivi sospetti;
- HTML non valido, eccessivamente complesso o copiato da editor inadatti;
- mittente e firma non identificabili;
- assenza di una versione testuale leggibile;
- richieste urgenti di credenziali o pagamenti.
Per i test usa un messaggio semplice, con oggetto chiaro, testo reale, firma completa e pochi link diretti al dominio aziendale. Non inviare dieci copie identiche allo stesso destinatario: il comportamento stesso può sembrare anomalo.
Controlla il dominio del mittente e il Reply-To
Il campo From dovrebbe utilizzare un dominio controllato e coerente con l’attività. Un modulo che mostra come mittente l’indirizzo inserito dal visitatore può causare fallimenti SPF o DMARC. Nei moduli del sito imposta come mittente una casella del tuo dominio e usa l’indirizzo del visitatore nel campo Reply-To.
Esempio corretto:
- From: sito@tuodominio.it;
- Reply-To: indirizzo inserito dal visitatore;
- destinatario: la casella aziendale che riceve il modulo.
In questo modo il server invia per un dominio che può autenticare, mentre la risposta viene comunque indirizzata al visitatore.
Reverse DNS e invio da VPS o server dedicati
Se la posta parte da un VPS o server dedicato, controlla hostname, record A, reverse DNS o PTR, HELO/EHLO e certificato del servizio. Il PTR deve essere configurato dal gestore dell’indirizzo IP e dovrebbe risolvere verso un hostname coerente.
Questi controlli non sono normalmente gestiti dal cliente per la posta inclusa nei piani hosting condivisi, ma diventano essenziali quando si amministra direttamente un server di posta.
Inoltri e modifiche dei messaggi
Gli inoltri possono complicare SPF perché il server che inoltra non è necessariamente autorizzato dal dominio originale. Inoltre mailing list, filtri e gateway possono modificare il corpo e invalidare una firma DKIM. DMARC valuta l’allineamento e può quindi fallire anche quando il messaggio iniziale era legittimo.
Quando il problema riguarda solo messaggi inoltrati, confronta le intestazioni del messaggio originale e di quello ricevuto dopo l’inoltro. Non modificare la policy DMARC dell’intero dominio basandoti su un singolo inoltro senza averne identificato il percorso.
Procedura di diagnosi consigliata
- invia un messaggio semplice da Webmail a una casella di test;
- controlla Track Delivery e conserva il codice SMTP;
- verifica SPF, DKIM e DMARC in Email Deliverability;
- apri le intestazioni complete del messaggio ricevuto;
- controlla i risultati di autenticazione e il dominio allineato;
- ripeti il test dal sito o dal servizio che presenta il problema;
- confronta le due sorgenti senza cambiare più impostazioni insieme;
- verifica contenuto, link, volume e qualità dei destinatari;
- attendi che la reputazione migliori dopo le correzioni, evitando invii aggressivi.
Quando aprire un ticket Xlogic
Apri un ticket quando Track Delivery mostra un rifiuto che non riesci a interpretare, quando Email Deliverability segnala problemi non correggibili dal pannello o quando la consegna fallisce sistematicamente da Webmail.
Invia dominio, mittente e destinatario mascherati se necessario, data e ora, oggetto, codice SMTP, intestazioni complete e modalità di invio. Non inviare password, codici 2FA o contenuti riservati.
Fonti tecniche ufficiali
Domande frequenti sulle email nello spam
SPF, DKIM e DMARC garantiscono la Posta in arrivo?
No. Dimostrano l’autenticità e l’allineamento del messaggio, ma i provider considerano anche reputazione, contenuto, volume, reclami e comportamento del destinatario.
Perché la stessa email arriva su Gmail ma finisce nello spam su Outlook?
Ogni provider utilizza filtri, reputazione e regole differenti. Bisogna confrontare intestazioni, codice SMTP e classificazione senza presumere che l’esito debba essere identico.
Devo aggiungere un altro record SPF per il servizio esterno?
No. Deve esistere un solo record SPF. Le sorgenti autorizzate vanno riunite nello stesso record seguendo le indicazioni del servizio e rispettando i limiti DNS di SPF.
Quanto tempo serve per uscire dallo spam?
Non esiste un tempo garantito. Le correzioni DNS possono propagarsi rapidamente, mentre la reputazione migliora gradualmente con invii regolari, destinatari validi e assenza di reclami.