⚡ Lancio in corso — Iscriviti ora come Founding Scout: accesso completo e gratuito, nessuna carta di credito. Entra gratis →
← Tutti gli articoli

Email che finiscono in spam o non arrivano: SPF, DKIM e DMARC

In breve

Da febbraio 2024 Gmail e Yahoo, e da maggio 2025 Microsoft, controllano che chi spedisce a nome di un dominio sia autorizzato a farlo. I controlli si chiamano SPF, DKIM e DMARC e si configurano nei DNS: se mancano o sono scritti male, le email finiscono in spam o vengono rifiutate, e di solito se ne accorge chi doveva riceverle. Verificarli richiede dieci minuti e una casella Gmail.

Ti è capitato di sollecitare un preventivo dopo una settimana di silenzio e sentirti rispondere dal cliente che la tua mail l’ha trovata solo in quel momento, nella cartella spam, in mezzo alle offerte di criptovalute e ai finti avvisi di consegna? È fastidioso, ma è ancora il caso fortunato, perché la mail almeno è arrivata. Sempre più spesso succede qualcosa di peggio: il cliente non la trova né in posta in arrivo né nello spam, mentre dal tuo lato risulta inviata regolarmente, con l’allegato e l’orario giusto, e la prima reazione è pensare che il problema sia suo. In entrambi i casi la causa è spesso la stessa, e non riguarda la casella ma il modo in cui il tuo dominio dichiara chi è autorizzato a spedire posta a suo nome.

Negli ultimi due anni i grandi provider di posta hanno smesso di chiudere un occhio su questa dichiarazione, e il risultato è che moltissime aziende piccole, che per anni hanno spedito senza problemi, si ritrovano con email che finiscono in spam o che vengono rifiutate in silenzio. In questo articolo vediamo cosa è cambiato, cosa controllano esattamente i tre meccanismi di cui si parla (SPF, DKIM e DMARC) e come verificare in pochi minuti se il tuo dominio è a posto, senza bisogno di essere un sistemista.

Cosa è cambiato, e perché le email che prima arrivavano adesso finiscono in spam o spariscono

Per molti anni la posta elettronica ha funzionato su un presupposto di fiducia piuttosto ingenuo: chiunque poteva spedire un messaggio scrivendo nel campo del mittente preventivi@tuazienda.it, e il server che lo riceveva non aveva un modo standard di verificare che fosse vero. Gli strumenti per farlo esistono da quasi vent’anni, ma erano facoltativi, e un’azienda che non li configurava non subiva conseguenze visibili, perché i filtri antispam si basavano soprattutto sul contenuto dei messaggi e sulla reputazione dei server.

A febbraio 2024 Google e Yahoo hanno reso questi controlli un requisito. Per chiunque spedisca verso un indirizzo Gmail è diventato obbligatorio avere almeno uno dei due meccanismi di autenticazione, SPF oppure DKIM, oltre a una connessione cifrata e a un tasso di segnalazioni come spam molto basso. Chi spedisce più di 5.000 messaggi al giorno verso Gmail deve invece averli entrambi, più un record DMARC e un link per disiscriversi con un solo clic. Per più di un anno Google ha applicato queste regole in modo graduale, spostando nello spam una parte dei messaggi non conformi; da novembre 2025 ha cominciato a rifiutarli, con errori temporanei o definitivi, il che significa che il messaggio non arriva proprio, né in posta in arrivo né nella cartella spam. Da maggio 2025 anche Microsoft applica regole simili agli invii massivi verso Outlook.com, Hotmail e Live, e anche in questo caso i messaggi non conformi vengono respinti invece che filtrati.

Vale la pena fermarsi su una distinzione che molti articoli sull’argomento mescolano, spaventando le piccole aziende più del necessario. Se sei una PMI che spedisce qualche decina di email al giorno, le regole pensate per chi fa newsletter a centinaia di migliaia di contatti non ti riguardano direttamente: ti basta che il dominio superi i controlli di base. Il guaio è che moltissimi domini aziendali non superano nemmeno quelli, spesso senza che nessuno lo sappia, perché la configurazione è stata fatta anni fa, da qualcuno che non lavora più con l’azienda, per un servizio di posta che nel frattempo è cambiato.

C’è poi un dettaglio che spiega perché nessuno se ne accorge per tempo. Quando un messaggio viene rifiutato, il server del destinatario rimanda indietro una notifica di mancata consegna, ma se la mail è partita da un modulo del sito o da un gestionale quella notifica va a un indirizzo tecnico che nessuno legge, e anche quando arriva nella casella di chi ha spedito è scritta in inglese, piena di codici, e viene scambiata facilmente per spam a sua volta. Così l’unica persona che si accorge del problema è il cliente che aspettava una risposta e non l’ha ricevuta.

Cosa controllano SPF, DKIM e DMARC

I tre meccanismi funzionano tutti allo stesso modo nella sostanza: il proprietario del dominio pubblica delle informazioni nei DNS, cioè nella configurazione pubblica del dominio che chiunque può interrogare, e il server che riceve una mail le consulta per decidere se fidarsi. Cambia quello che ciascuno verifica.

SPF (Sender Policy Framework) è un elenco dei server autorizzati a spedire posta per il tuo dominio. Si scrive come un record di testo che comincia con v=spf1 e prosegue con i nomi dei servizi che usi: se la tua posta passa da Google Workspace, nel record ci sarà un riferimento ai server di Google; se il gestionale delle fatture spedisce a nome tuo, dovrà esserci anche il suo. Quando arriva un messaggio, il server del destinatario guarda da quale macchina proviene e controlla se quella macchina compare nell’elenco. Il limite di SPF è che verifica il server di partenza e non il messaggio, e che si rompe facilmente quando una mail viene inoltrata, perché a quel punto il server che la consegna non è più quello originale.

DKIM (DomainKeys Identified Mail) aggiunge a ogni messaggio una firma digitale, calcolata dal tuo servizio di posta con una chiave che conosce solo lui. La chiave corrispondente, quella pubblica, la pubblichi nei DNS, e chi riceve la mail la usa per verificare che la firma sia autentica e che il messaggio non sia stato modificato durante il viaggio. A differenza di SPF, la firma resta attaccata al messaggio anche quando viene inoltrato. Un dettaglio che sorprende molti: né Google Workspace né Microsoft 365 firmano con il tuo dominio in modo automatico. In Workspace la chiave va generata dalla console di amministrazione e poi pubblicata nei DNS; in Microsoft 365, finché non la attivi, i messaggi vengono firmati con il dominio tecnico onmicrosoft.com, che non è il tuo e quindi non conta ai fini dei controlli.

DMARC è il livello che tiene insieme gli altri due. È un record pubblicato all’indirizzo _dmarc.tuazienda.it che dice ai server di posta due cose: cosa fare con un messaggio che non supera i controlli (lasciarlo passare, metterlo in quarantena nello spam oppure rifiutarlo) e a quale indirizzo mandarti dei resoconti periodici su chi sta spedendo a nome del tuo dominio. DMARC introduce anche il concetto di allineamento, che è la parte meno intuitiva e quella che causa più problemi: non basta che SPF o DKIM passino, bisogna che passino per lo stesso dominio che il destinatario vede come mittente. Se il tuo servizio di newsletter firma i messaggi con il proprio dominio invece che con il tuo, DKIM risulta valido ma non allineato, e per DMARC è come se non ci fosse.

Detto in pratica: SPF risponde alla domanda «questo server può spedire per questo dominio?», DKIM alla domanda «questo messaggio è stato davvero firmato da chi dice di averlo spedito, e non è stato alterato?», DMARC alla domanda «e se uno dei due controlli fallisce, cosa vuole il proprietario del dominio che succeda?».

I quattro casi in cui la posta di una PMI si rompe

Nella maggior parte dei casi la posta scritta a mano da una persona, dalla sua casella di Google Workspace o Microsoft 365, supera i controlli senza problemi, soprattutto se il servizio è stato configurato con un minimo di cura. I guai arrivano da tutto il resto, cioè dai programmi che spediscono mail a nome dell’azienda senza che nessuno ci pensi più.

Il modulo contatti del sito. È di gran lunga il caso più frequente. Un sito WordPress, per impostazione predefinita, spedisce le email del modulo contatti usando il server dell’hosting, e molti temi e plugin mettono come mittente l’indirizzo aziendale, per esempio info@tuazienda.it. Ma la posta aziendale sta su un altro servizio, e il server dell’hosting non compare nel record SPF: il messaggio parte da una macchina non autorizzata, non ha una firma DKIM del tuo dominio, e DMARC lo boccia. Il risultato è che le richieste dei clienti arrivano nello spam della casella aziendale, oppure non arrivano affatto, e l’azienda conclude che il sito non porta contatti. La soluzione corretta non è aggiungere l’hosting all’SPF, ma installare un plugin che spedisca le mail autenticandosi sulla casella vera, via SMTP, oppure tramite un servizio transazionale configurato con il tuo dominio.

Gestionali, fatturazione, prenotazioni, newsletter. Ogni servizio che spedisce mail «a nome tuo» deve essere autorizzato a farlo. Il software di fatturazione che manda le fatture di cortesia, la piattaforma che invia le conferme di prenotazione, lo strumento di newsletter: tutti questi, per superare i controlli, devono comparire nel record SPF oppure firmare i messaggi con una chiave DKIM del tuo dominio, e quasi tutti hanno una pagina di impostazioni che spiega quali record aggiungere. Se nessuno l’ha fatto, i messaggi partono lo stesso, e la cosa più insidiosa è che magari arrivano ai clienti che usano un provider meno severo e non a quelli che usano Gmail, rendendo il problema intermittente e difficile da diagnosticare.

Due record SPF, o quello vecchio rimasto lì. Un dominio deve avere un solo record SPF. Quando si aggiunge un servizio nuovo capita spesso che qualcuno crei un secondo record invece di modificare quello esistente, e in quel caso il controllo non fallisce solo per il nuovo servizio: fallisce per tutti, perché due record SPF rendono l’intera configurazione non valida. Una variante dello stesso problema si presenta quando l’azienda cambia fornitore di posta, per esempio passando da un provider italiano a Google Workspace, e il vecchio SPF resta al suo posto senza il riferimento al servizio nuovo.

Troppi servizi nello stesso SPF. Il protocollo pone un limite di dieci consultazioni DNS per ogni verifica SPF, e ogni servizio che aggiungi con include: ne consuma almeno una, spesso di più perché a sua volta rimanda ad altri record. Un’azienda che usa posta, CRM, newsletter, fatturazione, helpdesk e piattaforma di e-commerce può superare il limite senza accorgersene, e da quel momento SPF restituisce un errore per tutti i messaggi. Se il record è diventato una fila di include: lunga due righe, conviene farlo verificare.

Come controllare in dieci minuti se il tuo dominio è a posto

Il controllo più semplice non richiede strumenti particolari. Dalla tua casella aziendale manda una mail a un indirizzo Gmail qualsiasi, anche personale, poi aprila da Gmail sul computer, clicca sui tre puntini in alto a destra del messaggio e scegli «Mostra originale». Si apre una pagina che in cima riporta tre righe, una per SPF, una per DKIM e una per DMARC, ciascuna con l’esito del controllo: quello che vuoi vedere è PASS su tutte e tre. Se una riga dice FAIL, SOFTFAIL o NONE, o se la riga di DMARC manca, hai trovato il punto da cui partire.

Poi ripeti lo stesso test per ogni cosa che spedisce a nome dell’azienda: compila il modulo contatti del sito facendo arrivare la notifica a un indirizzo Gmail, fatti mandare una fattura di prova dal gestionale, iscriviti alla tua stessa newsletter. È il passaggio che quasi nessuno fa ed è quello che trova i problemi veri, perché come abbiamo visto la posta scritta a mano di solito funziona, mentre è il resto a rompersi. Per un quadro più completo puoi inserire il nome del dominio in uno strumento di verifica gratuito come MXToolbox, che legge i record pubblicati e segnala errori di sintassi, record SPF doppi e limite di consultazioni superato.

Se c’è qualcosa da sistemare, l’ordine in cui farlo conta, perché intervenire su DMARC prima di aver messo a posto gli altri due significa bloccare la tua stessa posta. Prima si sistema SPF, con un unico record che elenca tutti i servizi che spediscono davvero per te. Poi si attiva DKIM su ciascuno di quei servizi, a cominciare dalla casella principale: Google Workspace, Microsoft 365 e i provider italiani più diffusi, Aruba compresa, hanno una guida dedicata che indica il record da copiare nei DNS. Solo alla fine si pubblica DMARC, e lo si pubblica in modalità di sola osservazione, con p=none, che non cambia nulla nel modo in cui i messaggi vengono trattati ma ti fa arrivare i resoconti. Dopo qualche settimana di resoconti, che sono file tecnici ma si leggono facilmente caricandoli in uno dei tanti servizi gratuiti che li traducono in tabelle, saprai se c’è qualche mittente legittimo che ti eri dimenticato. A quel punto puoi passare a p=quarantine e poi, se vuoi, a p=reject, che è anche la protezione più efficace contro chi prova a spedire email truffa usando il nome della tua azienda.

Per le agenzie: di chi è il problema

Se fai siti per i clienti, c’è una ragione precisa per cui questo tema ti riguarda anche se la posta dei clienti non la gestisci tu. I record SPF, DKIM e DMARC vivono nella zona DNS del dominio, e la zona DNS si modifica dal pannello di chi ha registrato il dominio o di chi ne gestisce i DNS. In moltissime piccole aziende il dominio l’ha preso l’agenzia che ha fatto il primo sito, anni fa, e sta ancora nel suo account; la posta è su un servizio che il cliente ha attivato per conto suo; il sito sta su un hosting ancora diverso. Ognuno dei tre soggetti ha in mano un pezzo del problema e nessuno dei tre pensa che sia suo.

Il risultato tipico lo conosci: il cliente si lamenta che il modulo contatti non funziona, l’agenzia verifica che il modulo invia correttamente e chiude la segnalazione, il fornitore di posta risponde che la casella funziona, e le richieste continuano a perdersi. Nessuno ha torto sulla propria parte, ma la configurazione che fa funzionare le tre parti insieme non era nel perimetro di nessuno.

Per un’agenzia la prima cosa da sistemare è il contratto. Se gestisci i DNS di un cliente, la configurazione dell’autenticazione della posta va messa per iscritto come attività tua, oppure va scritto esplicitamente che non lo è e chi se ne occupa. E quando prendi in carico un cliente nuovo, il test descritto sopra (una mail dal modulo del sito verso un indirizzo Gmail e la lettura di «Mostra originale») dovrebbe far parte dei primi controlli, insieme alla verifica di chi è intestatario del dominio e di chi ha accesso ai DNS. Richiede cinque minuti, e spesso fa emergere un problema che il cliente aveva da mesi e attribuiva a un sito che «non porta contatti».

Ogni settimana mandiamo una mail agli Esploratori con i domini .it che tornano liberi e qualche nota pratica come questa. Se ti è stata utile, ci si iscrive qui.