Problemi di ricezione email aziendale: troubleshooting DNS e configurazione in 10 passaggi

Un martedi mattina di due mesi fa mi chiama un cliente -- impresa metalmeccanica, 22 dipendenti, ufficio commerciale che vive di email. Il tono e calmo, troppo calmo: "Carlo, da quando sono arrivate le email stamattina? Perche un cliente ci ha detto che ci scrive da venerdi e noi non abbiamo ricevuto niente." Tre giorni. Tre giorni lavorativi senza ricevere email, e nessuno se n'era accorto. Non perche fossero distratti -- perche le email in uscita funzionavano perfettamente. Mandavano, ricevevano conferme di lettura, tutto normale. Solo che dall'esterno, niente arrivava.

Quando sono entrato nella diagnostica, il problema era un record MX cancellato per errore durante un aggiornamento DNS fatto dal loro hosting per rinnovare il certificato SSL del sito. Un record cancellato, tre giorni di silenzio. E il bello e che il provider non aveva notificato nulla. Per loro era tutto a posto.

Questa storia la racconto perche riassume il 90% dei problemi di ricezione email che gestisco: il sintomo e invisibile, la causa e tecnica, e il danno si misura in affari persi. In questo articolo ti spiego i 10 problemi piu comuni e come li risolvo, nell'ordine esatto in cui li cerco.

Il mio protocollo di troubleshooting: l'ordine in cui controllo le cose

Quando un cliente mi dice "non ricevo email", non parto a caso. Ho un ordine preciso, costruito in quindici anni di interventi. Lo seguo sempre, perche i problemi piu comuni sono anche i piu facili da risolvere -- e non ha senso cercare una blacklist se il record MX non esiste.

Ecco la sequenza:

1. Record MX — esistono? Puntano al server giusto? Hanno la priorita corretta?
2. Record SPF — e pubblicato? Include il server di posta corretto?
3. Record DKIM — la firma e configurata? Il selettore esiste nel DNS?
4. Record DMARC — c'e una policy? Sta rifiutando email legittime?
5. Blacklist — l'IP del server e in qualche lista nera?
6. Quota casella — la casella e piena?
7. Filtri e regole — c'e un filtro che sposta o cancella le email?
8. Certificato SSL/TLS — il certificato del server di posta e scaduto?
9. Timeout del server — il server risponde entro i tempi previsti?
10. Problema lato mittente — e il mittente che ha un problema, non tu?

Questo ordine non e casuale. I primi quattro punti (DNS) coprono il 70% dei problemi che incontro. Li controllo in cinque minuti con MXToolbox. Se li escludo tutti, passo ai successivi. Se trovo il problema al punto 2, non perdo tempo col punto 9.

I 10 problemi di ricezione piu comuni e come risolverli

1. Record MX assenti o errati

Sintomo: non ricevi nessuna email da nessun mittente. Le email rimbalzano al mittente con errore "host not found" o "no MX record".

Causa: i record MX del tuo dominio non esistono, sono stati cancellati (come nel caso del mio cliente metalmeccanico), oppure puntano a un server sbagliato -- succede spesso dopo una migrazione email quando qualcuno aggiorna il sito ma dimentica la posta.

Soluzione: apri MXToolbox, inserisci il tuo dominio, controlla la sezione MX Lookup. Se non ci sono record MX, accedi al pannello DNS del tuo registrar e aggiungili. Se ci sono ma puntano al server sbagliato, correggili. La propagazione richiede da 5 minuti a 48 ore, a seconda del TTL impostato. Nel frattempo, le email rimbalzate dal mittente sono perse -- il mittente dovra reinviarle.

2. Record SPF non valido

Sintomo: ricevi email da alcuni mittenti ma non da altri. Le email mancanti finiscono nello spam del mittente con errore "SPF fail" oppure vengono rifiutate silenziosamente.

Causa: il record SPF del dominio del mittente non include il suo server di posta, oppure il tuo server applica un controllo SPF rigido e rifiuta le email con SPF non valido. Se hai cambiato provider email e non hai aggiornato il record SPF, le email che mandi tu avranno lo stesso problema -- ma dall'altra parte.

Soluzione: controlla il record SPF con nslookup -type=TXT tuodominio.it oppure con MXToolbox SPF Lookup. Verifica che includa tutti i server autorizzati a inviare email per il tuo dominio. Un record SPF troppo permissivo (+all) e un rischio sicurezza; uno troppo restrittivo (-all senza tutti i server inclusi) blocca email legittime. Il bilanciamento corretto e ~all (soft fail) durante la fase di test, poi -all (hard fail) quando sei sicuro che tutto funziona.

3. DKIM non configurato o non corrispondente

Sintomo: le email arrivano ma finiscono nello spam. Nell'header trovi "dkim=fail" o "dkim=none".

Causa: il record DKIM nel DNS non corrisponde alla chiave con cui il server firma le email. Oppure DKIM non e stato configurato affatto -- cosa che vedo spesso su hosting italiani che non lo attivano di default. Ne ho parlato anche nell'articolo sull'hosting italiano vs cloud internazionale: la qualita della configurazione email varia enormemente tra i provider.

Soluzione: verifica il selettore DKIM con MXToolbox DKIM Lookup (ti serve il nome del selettore, che trovi nel pannello del tuo provider email). Se il record non esiste nel DNS, aggiungilo. Se esiste ma non corrisponde, rigeneralo dal pannello del provider e aggiorna il DNS. Dopo la modifica, manda un'email di test a mail-tester.com per verificare che il punteggio DKIM sia positivo.

4. Policy DMARC troppo restrittiva

Sintomo: le email da certi mittenti non arrivano. Il mittente riceve un bounce con "DMARC policy" nel messaggio di errore. Oppure le email arrivano a caselle su un provider ma non su un altro.

Causa: il dominio del mittente ha una policy DMARC con p=reject, ma il suo server non ha SPF e DKIM allineati correttamente. Oppure tu hai una policy DMARC con p=reject e stai rifiutando email che falliscono sia SPF che DKIM -- incluse email legittime da servizi di email marketing o mailing list che inoltrano messaggi.

Soluzione: controlla il record DMARC con nslookup -type=TXT _dmarc.tuodominio.it. Se la policy e p=reject e stai avendo problemi, abbassala temporaneamente a p=quarantine o p=none e attiva i report (rua=mailto:dmarc@tuodominio.it) per capire quali email stanno fallendo e perche. Non lasciare p=none per sempre -- e come non avere DMARC. Ma usalo come strumento diagnostico per capire cosa sta succedendo prima di applicare una policy restrittiva.

5. IP del server in blacklist

Sintomo: le email da alcuni domini non arrivano. I mittenti ricevono errori come "blocked" o "listed in DNSBL". Il problema e intermittente -- non tutti i mittenti sono colpiti.

Causa: l'indirizzo IP del tuo server email e finito in una o piu blacklist. Succede se qualcuno ha usato il server per inviare spam (anche involontariamente, per esempio dopo un attacco di phishing), se il server e su un IP condiviso con altri utenti che hanno fatto spam, o se il provider ha avuto un problema di reputazione.

Soluzione: controlla il tuo IP su MXToolbox Blacklist Check. Se sei in una o piu liste, segui la procedura di delisting di ciascuna (ogni blacklist ha la propria). Le piu comuni -- Spamhaus, Barracuda, SpamCop -- hanno form di richiesta rimozione. Prima di chiedere la rimozione, assicurati di aver risolto la causa: se il server continua a mandare spam, vieni ri-listato nel giro di ore. Se sei su un hosting condiviso e l'IP e in blacklist per colpa di altri utenti sullo stesso server, l'unica soluzione reale e cambiare provider o ottenere un IP dedicato.

6. Casella piena

Sintomo: non ricevi email. I mittenti ricevono un bounce con "mailbox full" o "quota exceeded". Oppure le email piu recenti arrivano ma non riesci a scaricare gli allegati.

Causa: la casella ha raggiunto il limite di spazio. Con hosting che offrono caselle da 1-2 GB, basta un anno di allegati per riempire tutto. Il problema e che molti provider non inviano avvisi prima del raggiungimento del limite -- scopri che la casella e piena quando i clienti ti chiamano per dire che le loro email rimbalzano.

Soluzione: libera spazio: cancella email con allegati pesanti, svuota il cestino e la cartella spam, archivia le email vecchie in locale (ne parlo nell'articolo sul backup delle email aziendali). Se il problema si ripresenta spesso, e il momento di valutare un provider con piu spazio o un piano superiore. Un trucco che insegno ai clienti: configura una regola che sposta automaticamente le email piu vecchie di 6 mesi in una cartella di archivio locale su Outlook o Thunderbird.

7. Filtri e regole che cancellano o spostano email

Sintomo: non ricevi email da un mittente specifico o su un argomento specifico. Tutto il resto funziona normalmente.

Causa: una regola lato server o lato client sta spostando le email in una cartella che non controlli, oppure le sta cancellando direttamente. A volte sono regole create mesi fa e dimenticate. A volte e il filtro antispam del provider che e troppo aggressivo. Ho avuto un cliente che non riceveva le email dal suo fornitore principale da due settimane: una regola creata da un ex dipendente spostava tutto quello che conteneva la parola "offerta" nella cartella cestino.

Soluzione: controlla tutte le regole attive -- sia nella webmail che nel client desktop. Controlla le cartelle spam e cestino. Controlla i filtri del provider (molti hanno un pannello antispam con whitelist e blacklist). Se usi un server con filtro antispam avanzato (SpamAssassin, per esempio), controlla i log per vedere se le email vengono classificate come spam prima di raggiungere la casella.

8. Certificato SSL/TLS scaduto

Sintomo: il client email mostra errori di sicurezza. Non riesci a connetterti al server. Alcune email rimbalzano con errori TLS.

Causa: il certificato SSL/TLS del server di posta e scaduto. I server mittenti che usano TLS obbligatorio rifiutano di consegnare le email a un server con certificato scaduto. Il problema e piu comune di quanto si pensi, soprattutto su server gestiti con hosting economici che non rinnovano automaticamente il certificato della posta (rinnovano quello del sito web ma dimenticano quello del mail server).

Soluzione: verifica il certificato con openssl s_client -connect mail.tuodominio.it:993 (per IMAP) o :465 / :587 (per SMTP). Se e scaduto, contatta il provider per il rinnovo. Se gestisci il server direttamente, rinnova con Let's Encrypt o il certificato del tuo fornitore. Imposta un promemoria per il rinnovo -- meglio ancora, configura il rinnovo automatico.

9. Timeout del server di posta

Sintomo: le email arrivano con ritardo di ore o giorni. Oppure i mittenti ricevono "connection timed out" dopo tentativi ripetuti.

Causa: il server di posta e sovraccarico, ha un problema di rete, o e semplicemente spento. Con hosting condivisi a basso costo, un picco di traffico sugli altri siti ospitati sullo stesso server puo rallentare il servizio email fino al timeout. A volte il problema e un firewall che blocca le connessioni sulla porta 25 (SMTP).

Soluzione: testa la raggiungibilita del server con telnet mail.tuodominio.it 25 (o Test-NetConnection su PowerShell). Se il server non risponde, contatta il provider. Se risponde ma lentamente, il problema e di performance -- e spesso la soluzione e cambiare provider. Un server email che fa timeout regolarmente e un server email che perde le tue email. Non e accettabile per un'azienda.

10. Il problema e il mittente, non tu

Sintomo: non ricevi email da un mittente specifico, ma da tutti gli altri si. Il mittente giura di averla mandata. Tu giuri di non averla ricevuta. Entrambi avete ragione.

Causa: il server del mittente ha un problema -- SPF non valido, IP in blacklist, casella di invio piena, DMARC che blocca. Oppure l'email e partita ma e rimasta in coda sul server del mittente. Oppure -- e questo lo vedo sempre piu spesso -- il mittente usa un servizio di email marketing che invia da un dominio diverso dal suo, e quel dominio ha problemi di reputazione.

Soluzione: chiedi al mittente di mandarti l'email originale come allegato (non come inoltro -- l'inoltro perde gli header). Se riesce a farlo, analizza gli header (vedi sezione successiva). Se non riesce nemmeno a mandartela come allegato, il problema e sicuramente lato suo. Suggeriscigli di controllare la coda di invio del suo server, il record SPF del suo dominio, e lo stato del suo IP sulle blacklist. Se non sa come fare, ha bisogno di un consulente -- non di insistere che "da me funziona tutto".

Come leggere un header email per capire dove si blocca la consegna

L'header di un'email e la scatola nera del messaggio. Contiene tutto il percorso che l'email ha fatto dal mittente al destinatario, con timestamp, server attraversati, e risultati dei controlli di autenticazione. Imparare a leggerlo ti risparmia ore di tentativi alla cieca.

Per visualizzare l'header completo: in Gmail clicchi "Mostra originale", in Outlook "Visualizza origine messaggio", in Thunderbird "Visualizza > Sorgente del messaggio". Quello che ti trovi davanti e un blocco di testo che sembra incomprensibile. Ecco le righe che contano:

Received: ogni riga "Received:" e un salto tra server. Si leggono dal basso verso l'alto -- l'ultima in fondo e il primo server che ha gestito l'email, la prima in cima e l'ultimo (il tuo). Se ci sono gap temporali di ore tra due "Received:", il problema e sul server che ha trattenuto il messaggio.

Authentication-Results: questa riga ti dice in un colpo solo se SPF, DKIM e DMARC hanno passato il controllo. Cerchi tre parole: spf=pass, dkim=pass, dmarc=pass. Se trovi "fail" su qualsiasi di questi, hai trovato il problema.

X-Spam-Status: se il server usa SpamAssassin o un filtro simile, questa riga ti dice il punteggio spam e le regole che si sono attivate. Un punteggio sopra 5 significa che l'email e stata classificata come spam. Le regole attivate ti dicono perche.

Se l'analisi manuale degli header ti sembra troppo complessa, usa Google Admin Toolbox (Messageheader): incolli l'header e ti restituisce una timeline visiva del percorso dell'email con i tempi di ogni passaggio. E gratuito e funziona con qualsiasi email, non solo Gmail.

Gli strumenti diagnostici che uso ogni settimana

Strumento	Cosa fa	Quando lo uso
MXToolbox	Controllo MX, SPF, DKIM, DMARC, blacklist, SMTP diagnostics	Sempre. E il primo tool che apro per qualsiasi problema email. La versione gratuita copre il 90% delle esigenze
Google Admin Toolbox	Analisi header email (Messageheader), Check MX, HAR Analyzer	Quando devo analizzare un header email o diagnosticare problemi su domini con Google Workspace
nslookup / dig	Query DNS dirette per verificare record MX, SPF, DKIM, DMARC	Quando ho bisogno di controllare un record DNS specifico dalla riga di comando, senza interfaccia web
telnet / Test-NetConnection	Test di connettivita verso il server di posta su porte specifiche (25, 465, 587, 993)	Quando sospetto un problema di raggiungibilita del server o un firewall che blocca le porte
mail-tester.com	Punteggio di deliverability: SPF, DKIM, DMARC, blacklist, contenuto, in un unico report	Dopo aver risolto un problema, per verificare che la configurazione sia pulita. Mando un'email di test all'indirizzo temporaneo e leggo il report

Questi cinque strumenti coprono il 95% della diagnostica email. Non servono tool a pagamento per il troubleshooting base. MXToolbox e mail-tester.com da soli ti danno un quadro completo della salute della tua configurazione email.

Prevenzione: come evitare che il problema si ripresenti

Il troubleshooting risolve il problema di oggi. La prevenzione evita quello di domani. Ecco cosa configuro per i miei clienti dopo ogni intervento di troubleshooting:

Monitoraggio DNS. Imposto un controllo automatico dei record MX, SPF e DKIM con MXToolbox Monitoring (versione gratuita: un dominio, controllo settimanale; versione a pagamento: piu domini, controllo giornaliero). Se un record cambia o sparisce, ricevo un alert prima che il cliente se ne accorga.

Monitoraggio blacklist. Stesso principio: controllo periodico dell'IP del server sulle principali blacklist. Se vieni listato, lo sai entro 24 ore, non dopo una settimana di email rimbalzate.

Alert quota casella. Configuro gli avvisi di quota al 80% su tutti i provider che lo permettono. Google Workspace e Microsoft 365 lo fanno nativamente. Sugli hosting italiani, spesso bisogna configurarlo manualmente o controllare periodicamente.

Documentazione DNS. Tengo un file con tutti i record DNS del dominio -- MX, SPF, DKIM, DMARC, A, CNAME -- con data dell'ultima modifica e motivo. Quando qualcuno tocca il DNS (per il sito, per un nuovo servizio, per qualsiasi motivo), controlla prima quel file per non rompere qualcosa che funziona. Il mio cliente metalmeccanico avrebbe evitato tre giorni di email perse se il tecnico dell'hosting avesse avuto quel file davanti.

Autenticazione completa. Non mi accontento di "funziona". Configuro SPF, DKIM e DMARC su ogni dominio che gestisco, con 2FA attivo su tutte le caselle. La crittografia email aggiunge un ulteriore livello di protezione. Un dominio con autenticazione completa ha meno problemi di deliverability, punto. E se domani cambi provider, hai gia tutto documentato per la migrazione.

Se vuoi capire come imposto la configurazione email completa per le PMI -- DNS, autenticazione, monitoraggio, tutto il pacchetto -- qui spiego il mio metodo di lavoro. E se il tuo problema di ricezione viene da un cambio provider recente andato male, la guida sulla migrazione email aziendale ti spiega come evitare che succeda di nuovo. Per chi invece e in fase di scelta del provider e vuole partire con il piede giusto, ho scritto confronti dettagliati tra Zoho Mail e Google Workspace e tra hosting italiano e cloud internazionale -- perche molti problemi di ricezione nascono da una scelta iniziale sbagliata.