Il punto è questo: SPF, DKIM e DMARC non servono a “mettere il bollino” sulla posta. Servono a dichiarare, verificare e monitorare l’identità tecnica delle email aziendali.
Se ciò che è scritto nei DNS non corrisponde a ciò che accade davvero, DMARC comincia a mostrare il problema.
Quando DMARC segnala un fallimento, di solito ha ragione
DMARC non è capriccioso: confronta quello che il dominio dichiara con quello che i server riceventi osservano. Se una newsletter parte da una piattaforma non autorizzata, DMARC rileva un fallimento. Se un gestionale invia email senza DKIM configurato correttamente, DMARC rileva un fallimento. Se un account viene usato tramite il server SMTP sbagliato, DMARC rileva un fallimento. Se un vecchio server interno continua a spedire posta — anche se nessuno lo considera più parte dell’infrastruttura ufficiale — DMARC rileva un fallimento.
In altre parole, DMARC non scopre solo gli attacchi. Scopre anche il disordine.
E nelle aziende, il disordine della posta elettronica è molto più comune di quanto sembri.
Il problema dei vecchi server e delle configurazioni ereditate
Molte infrastrutture email aziendali non sono state progettate da zero in modo ordinato. Sono state costruite nel tempo: un provider cambiato, un server migrato, un gestionale aggiunto, una newsletter esternalizzata, un dominio secondario, un sistema di ticketing, un vecchio applicativo che manda notifiche automatiche, un server SMTP interno rimasto attivo “perché tanto serve ancora”.
Questa stratificazione genera debito tecnico. Non solo codice vecchio o software non aggiornato: anche una configurazione che nessuno ha più il coraggio, il tempo o la memoria storica per toccare. La posta continua a funzionare, quindi non viene analizzata. Ma nel frattempo i criteri antispam si sono irrigiditi, i grandi provider valutano con maggiore attenzione l’autenticazione, i clienti sono più esposti a tentativi di frode e i domini aziendali sono diventati asset reputazionali da proteggere.
Una configurazione email vecchia non è per forza sbagliata. Va verificata. Il rischio reale è che l’azienda continui a ragionare come se esistesse un solo server di posta, mentre nella realtà le email escono da molti sistemi diversi.
Open relay, server mal configurati e relay permissivi
Un tema spesso sottovalutato riguarda i relay. Un open relay è un server che consente a soggetti non autorizzati di inviare posta verso terzi: una configurazione che da decenni dovrebbe essere evitata, perché può essere sfruttata per spam e invii non controllati. Oggi un mailserver ben gestito non dovrebbe accettare traffico da open relay e dovrebbe affidarsi anche a controlli reputazionali, blacklist e meccanismi di blocco.
Ma non esistono solo gli open relay evidenti. Ci sono anche configurazioni meno appariscenti ma comunque problematiche: server con comportamenti troppo permissivi, MTA installati frettolosamente, vecchie macchine lasciate attive, applicativi che usano credenziali generiche, account configurati in modo da usare sempre lo stesso server SMTP anche quando il mittente appartiene a un dominio diverso.
In questi casi il problema può non sembrare grave: l’invio parte, il messaggio arriva, l’utente non vede errori. Ma dal punto di vista dell’autenticazione, quella posta può non essere coerente. Ed è qui che nascono molti fallimenti difficili da diagnosticare.
Il caso degli account multipli e del server di uscita sbagliato
Un esempio molto comune riguarda i client di posta configurati con più account. Un utente gestisce cinque, dieci, a volte decine di caselle condivise o alias. Se il client usa sempre lo stesso server SMTP di uscita — oppure se l’account principale spedisce messaggi per identità diverse senza controlli adeguati — il risultato può essere tecnicamente incoerente.
Dal punto di vista dell’utente è tutto normale: seleziona il mittente, scrive e invia. Dal punto di vista del server ricevente, però, il messaggio racconta un’altra storia: un dominio nel campo mittente, un server di invio non previsto, una firma DKIM assente o non allineata, una policy DMARC che non trova corrispondenza tra ciò che viene dichiarato e ciò che sta accadendo.
Un mailserver ben configurato dovrebbe governare queste situazioni. Ma molte infrastrutture non lo fanno, soprattutto quando sono nate per accumulo o per urgenza.
Le newsletter sono spesso il punto in cui il problema emerge
Le piattaforme newsletter rappresentano uno dei casi più frequenti. Un’azienda decide di inviare comunicazioni commerciali o informative usando una piattaforma esterna. Il reparto marketing carica i contatti, crea il template, imposta il mittente con il dominio aziendale e inizia a spedire. Tutto sembra funzionare.
Ma se la piattaforma non è stata autorizzata correttamente in SPF, se DKIM non è configurato sul dominio, se il dominio di ritorno non è allineato, o se DMARC è già impostato in modo restrittivo, la newsletter può generare fallimenti, finire nello spam o danneggiare la reputazione del dominio.
Il punto non è “la newsletter è fatta male”. Il punto è che ogni piattaforma che invia email per conto dell’azienda deve essere trattata come parte dell’infrastruttura email aziendale. CRM, ERP, gestionali, sistemi di marketing automation, portali per preventivi, software di assistenza, piattaforme di fatturazione e strumenti di ticketing devono essere mappati, verificati e configurati in modo coerente.
DMARC senza monitoraggio è un’occasione sprecata
Uno degli errori più frequenti è pubblicare DMARC e poi non leggere i report. Questo approccio trasforma DMARC in una semplice riga nel DNS, non in uno strumento di sicurezza operativo.
I report DMARC servono a ricostruire cosa accade al dominio: quali server stanno inviando email, quali passano SPF o DKIM, quali falliscono, quali sorgenti sono legittime ma non ancora configurate, quali invii sembrano sospetti. I report aggregati offrono il quadro complessivo; quelli di fallimento — quando disponibili e supportati dal sistema ricevente — forniscono informazioni più granulari sui singoli messaggi.
Questo significa che non basta “mettere l’indirizzo dei report”. Serve qualcuno, o qualcosa, che li riceva, li analizzi e li trasformi in decisioni operative.
Un dominio può avere DMARC attivo e continuare a essere configurato male. Un dominio può ricevere report pieni di segnali utili senza che nessuno li guardi. Un dominio può mostrare tentativi di abuso, sorgenti dimenticate o invii non conformi — e l’azienda se ne accorge solo quando il problema diventa visibile a un cliente, a un fornitore o a un sistema antispam.
I segnali tecnici: SpamAssassin, DMARC e l’intelligence operativa
In molte infrastrutture, i sistemi antispam non si limitano a decidere se una mail è buona o cattiva. Raccolgono segnali, applicano regole, verificano reputazione, autenticazione, contenuto e comportamento. SpamAssassin, per esempio, include un plugin DMARC che verifica se i messaggi rispettano la policy dichiarata e richiede che siano abilitati anche i controlli SPF e DKIM. In base alla configurazione, questi sistemi possono contribuire a rendere disponibili dati utili sui fallimenti.
Il principio è importante: l’autenticazione email produce segnali tecnici che possono essere raccolti, analizzati e usati per capire cosa accade davvero. Senza monitoraggio, quei segnali restano rumore. Con il monitoraggio, diventano intelligence operativa.
Il rischio più serio non è lo spam: è l’impersonificazione
Quando si parla di SPF, DKIM e DMARC, molte aziende pensano prima di tutto alla recapitabilità. “Mi serve per non finire nello spam.” È vero, ma è solo una parte del problema.
Il tema più serio è l’impersonificazione. Se un attaccante riesce a inviare email che sembrano provenire dal dominio aziendale, può tentare frodi verso clienti, fornitori, amministrazione, direzione o reparti sensibili: una falsa richiesta di pagamento, una modifica IBAN, una comunicazione tecnica contraffatta, una richiesta urgente del management.
Quando l’attacco è rivolto a figure apicali o soggetti ad alto valore, si parla spesso di whaling — una forma mirata di phishing. In questo contesto, DMARC non elimina il rischio, ma può ridurre la possibilità che email non allineate al dominio vengano considerate legittime dai server riceventi, e può aiutare a ricostruire tentativi di abuso attraverso i report.
Il punto non è poter dire “avevamo DMARC”. Il punto è poter dimostrare che il dominio è stato configurato, monitorato e governato in modo coerente nel tempo.
Il falso senso di sicurezza: “abbiamo Microsoft 365” o “abbiamo Google Workspace”
Microsoft 365 e Google Workspace offrono strumenti solidi per la gestione della posta, ma non risolvono automaticamente tutto ciò che ruota intorno al dominio aziendale. Se tutte le email partissero solo da Microsoft o solo da Google, la situazione sarebbe più semplice. Ma raramente è così.
Molte aziende usano piattaforme esterne per newsletter, CRM, fatturazione, ticketing, preventivi, gestionali, e-commerce, portali clienti, sistemi di notifica, software verticali. Alcune usano più domini. Altre hanno sottodomini. Altre ancora hanno vecchi server interni che continuano a inviare email per applicativi legacy.
La domanda giusta non è: “Uso Microsoft 365 o Google Workspace, sono a posto?”
La domanda giusta è: tutte le email che sembrano uscire dal mio dominio passano davvero da sorgenti autorizzate, firmate e monitorate?
Cosa dovrebbe controllare un’azienda
Un controllo serio della posta elettronica aziendale non si limita a verificare se SPF, DKIM e DMARC esistono. Deve ricostruire il perimetro reale. In concreto, bisogna verificare quali domini e sottodomini inviano email, quali server sono autorizzati da SPF, se il record SPF supera o rischia di superare il limite dei 10 lookup DNS, quali piattaforme esterne inviano email per conto dell’azienda e se tutte firmano correttamente con DKIM. Vanno verificati l’allineamento DKIM al dominio mittente, la policy DMARC attiva (osservazione, quarantena o rifiuto), dove arrivano i report e chi li interpreta con quale frequenza. Non vanno trascurati i vecchi server SMTP, MTA, relay, inoltri o applicativi legacy, né i client di posta con account multipli che potrebbero usare server di uscita incoerenti. Vanno mappati newsletter, CRM, ERP e gestionali, e vanno analizzati i segnali di spoofing, abuso o configurazioni non autorizzate.
Questa analisi non serve solo a “mettere a posto la posta”. Serve a ridurre una superficie di rischio che spesso resta invisibile finché non produce un danno reale.
Cosa succede quando si passa troppo presto a DMARC reject
Impostare DMARC con policy p=reject può essere la scelta giusta, ma solo quando l’infrastruttura è stata mappata e verificata. Passare troppo presto a una policy restrittiva può bloccare email legittime: newsletter, notifiche di gestionali, messaggi automatici, comunicazioni da CRM, sistemi di ticketing o applicativi verticali.
Per questo l’approccio corretto è progressivo: prima si osserva, poi si mappano le sorgenti, poi si correggono SPF e DKIM, poi si analizzano i report, poi — con ragionevole certezza che gli invii legittimi siano allineati — si passa a una policy più restrittiva.
DMARC non deve essere usato come interruttore. Deve essere usato come processo.
Una configurazione email va mantenuta, non solo realizzata
La posta elettronica aziendale non è un impianto che si configura una volta e poi si dimentica. Ogni nuovo servizio può cambiare lo scenario. Ogni nuovo CRM può aggiungere una sorgente di invio. Ogni nuova piattaforma newsletter può richiedere una firma DKIM. Ogni cambio provider può modificare SPF. Ogni vecchio server lasciato acceso può continuare a produrre traffico non documentato. Ogni report DMARC ignorato può nascondere un segnale importante.
La sicurezza della posta elettronica deve entrare nella manutenzione ordinaria dell’infrastruttura IT — non come attività estetica, ma come presidio di sicurezza, continuità operativa e reputazione digitale.
In sintesi
SPF, DKIM e DMARC sono strumenti fondamentali, ma non bastano se vengono trattati come semplici record DNS da pubblicare una volta e dimenticare. Il tema centrale è la coerenza tra ciò che il dominio dichiara e ciò che l’azienda fa davvero quando invia email. Se la posta esce da server vecchi, piattaforme non censite, CRM non configurati, newsletter senza firma DKIM, account multipli con SMTP incoerenti o relay gestiti male, DMARC fa emergere il problema. E se nessuno legge i report, il problema resta lì.
Una configurazione email che funzionava dieci anni fa non è automaticamente adeguata oggi. Nel frattempo sono cambiati i rischi, i controlli, le aspettative dei provider, la complessità delle infrastrutture e il valore del dominio come identità digitale.
La posta elettronica non va solo fatta funzionare. Va governata.
Parla con Alchimie Digitali per una verifica della configurazione email aziendale. Se vuoi capire se la tua posta aziendale è davvero configurata in modo coerente, non limitarti a controllare che “funzioni”. Verifica da dove escono le email, chi le firma, quali server sono autorizzati e chi sta leggendo i segnali che DMARC produce.
