Un preventivo inviato che non arriva, una fattura finita nella cartella indesiderata o un cliente che riceve un messaggio fraudolento apparentemente spedito dal tuo indirizzo: i problemi di posta elettronica possono tradursi in lavoro perso e danni alla reputazione. Quando succede, la prima reazione è spesso cambiare programma o server. Ma una causa frequente è più a monte: il dominio non dimostra in modo affidabile quali sistemi sono autorizzati a spedire email per conto dell’azienda.
SPF, DKIM e DMARC sono tre meccanismi complementari di autenticazione. Non sono un interruttore che garantisce l’arrivo nella posta in arrivo: aiutano i sistemi riceventi a verificare il mittente e a gestire meglio i messaggi sospetti. La reputazione del dominio, il contenuto, il volume, i reclami e le regole del destinatario continuano a contare. Per una PMI in Ticino, però, configurare correttamente questi controlli è una base concreta per ridurre lo spoofing e diagnosticare più seriamente i problemi di recapito.
Prima diagnosi: è davvero un problema SPF, DKIM o DMARC?
Prima di modificare il DNS, raccogli esempi precisi. Annota mittente, destinatario, data e ora, oggetto e risultato: rifiuto, ritardo, spam oppure messaggio apparentemente contraffatto. Se il problema riguarda solo un destinatario o è iniziato dopo un cambio di piattaforma, il sintomo da solo non identifica la causa.
Chiedi all’amministratore della posta o al destinatario un estratto delle intestazioni complete del messaggio. In molti servizi si possono controllare righe come Authentication-Results, con esiti spf=pass/fail, dkim=pass/fail e dmarc=pass/fail. Non condividere pubblicamente intestazioni che contengono indirizzi, identificativi o altri dati aziendali: inviale solo al tecnico incaricato usando un canale appropriato.
Se tutte le email finiscono nello spam, verifica anche reputazione del dominio e dell’IP, eventuali blocchi del provider, configurazione del relay, DNS, TLS, tasso di rimbalzo e reclami. SPF/DKIM/DMARC sono fondamentali, ma non spiegano ogni problema di consegna.
SPF: quali server possono spedire per il tuo dominio
SPF, Sender Policy Framework, è una regola pubblicata nel DNS che elenca le sorgenti autorizzate a inviare email per un dominio. Il server destinatario confronta la sorgente che ha consegnato il messaggio con la policy SPF e registra un risultato. In questo modo diventa più difficile per un estraneo falsificare il dominio nel percorso di invio verificato.
Il record SPF è un record TXT. La parte iniziale identifica la versione; il resto dichiara le sorgenti autorizzate e il comportamento finale. Non copiare un record generico trovato online: il valore corretto dipende da tutti i sistemi che inviano davvero per l’azienda, per esempio Microsoft 365, una piattaforma newsletter, un gestionale, un sito che invia notifiche o un servizio di fatturazione.
Errori SPF che capitano spesso
- Più record SPF sullo stesso nome DNS. In genere va pubblicato un solo record SPF per dominio. Record separati possono produrre un risultato
permerror. - Dimenticare un mittente legittimo. Una newsletter o il sito aziendale possono spedire da un servizio diverso da Microsoft 365. Se non è autorizzato, alcuni messaggi falliscono il controllo.
- Aggiungere inclusioni senza verificarle. SPF prevede un limite di dieci ricerche DNS per valutazione. Catene di
includetroppo lunghe possono portare a un errore di limite. - Applicare subito una policy restrittiva senza inventario. Se non hai identificato tutte le fonti legittime, una modifica può rifiutare posta autentica.
Prima di pubblicare una modifica, raccogli l’elenco dei servizi mittenti con chi amministra il dominio e segui le istruzioni aggiornate di ciascun provider. Non incollare record DNS proposti automaticamente senza verificare che riflettano l’infrastruttura reale.
DKIM: firma crittografica del messaggio
DKIM, DomainKeys Identified Mail, aggiunge una firma digitale alle email. Il destinatario recupera la chiave pubblica indicata dal messaggio attraverso il DNS e verifica la firma. Se la verifica riesce, il risultato fornisce un segnale che il messaggio è stato autorizzato dal dominio che firma e che le parti firmate non sono state alterate durante il transito.
La configurazione richiede di abilitare DKIM presso il provider di posta e pubblicare nel DNS i record richiesti, spesso associati a uno o più selector. I valori sono specifici del tenant o del servizio: non sono intercambiabili fra aziende. In Microsoft 365, per esempio, si seguono i record mostrati nell’amministrazione del proprio tenant e si controlla che lo stato DKIM diventi abilitato per il dominio personalizzato.
Un messaggio può essere firmato da un dominio tecnico del fornitore invece che dal dominio visibile al cliente. Ciò non rende automaticamente DKIM inutile, ma l’allineamento del dominio è rilevante anche per DMARC. Per i servizi terzi, verifica che il provider supporti la firma con il tuo dominio e completa l’eventuale procedura di verifica.
DMARC: una policy e un modo per ricevere rapporti
DMARC usa i risultati SPF e DKIM e controlla anche l’allineamento con il dominio visibile nell’intestazione From. Se almeno uno dei due meccanismi passa e il relativo dominio è allineato secondo la policy, il messaggio può superare DMARC. Il titolare del dominio pubblica inoltre una policy che comunica al ricevente come trattare i messaggi che non superano i controlli e può indicare una casella per ricevere rapporti aggregati.
Le policy comuni sono none (monitoraggio), quarantine (trattamento sospetto, spesso spam) e reject (richiesta di rifiuto). La progressione deve essere prudente: partire dal monitoraggio permette di scoprire sorgenti legittime non censite. Passare a una policy più severa senza analizzare i rapporti può bloccare comunicazioni reali, incluse fatture o conferme generate da servizi aziendali.
I rapporti DMARC possono essere voluminosi e tecnici. Una PMI dovrebbe stabilire chi li riceve, come vengono conservati e chi li interpreta, tenendo conto dei dati contenuti. Se la casella di report non è monitorata o i dati non vengono analizzati, il record da solo non costituisce un processo di controllo.
Un percorso prudente in cinque passaggi
- Mappa tutti gli invii. Elenca posta ordinaria, newsletter, sito, CRM, fatturazione, scanner e applicazioni. Per ogni servizio identifica il dominio del mittente e il referente.
- Controlla SPF e DKIM attuali. Verifica il DNS autorevole e invia messaggi di prova verso caselle di test controllate, poi leggi
Authentication-Results. Non modificare ancora una policy se non sai quali sistemi spediscono. - Abilita le firme DKIM previste dai provider. Copia i record esatti dal pannello del servizio, attendi la propagazione DNS e verifica le firme su messaggi reali di test.
- Pubblica DMARC in modalità di osservazione. Configura un indirizzo di report gestito e analizza i risultati nel tempo. Confronta i mittenti osservati con l’inventario aziendale, distinguendo servizi autorizzati da invii sospetti.
- Risolvi le sorgenti e irrigidisci gradualmente. Correggi o dismetti i sistemi legittimi che non risultano allineati. Solo dopo aver compreso il traffico, valuta con un tecnico una policy più restrittiva e monitora eventuali effetti sui messaggi validi.
La propagazione DNS può richiedere tempo e i risultati dipendono dai resolver e dai destinatari. Verifica usando più di un messaggio e più di un servizio ricevente, senza concludere che tutto sia risolto solo perché una singola prova mostra pass.
Microsoft 365 e altri servizi: perché l’inventario è essenziale
Molte imprese usano Microsoft 365 per la posta ma inviano anche messaggi da strumenti esterni. Aggiungere una newsletter, spostare il sito o cambiare gestionale può introdurre una nuova sorgente. Se il dominio non viene aggiornato o DKIM non viene abilitato per il nuovo servizio, alcuni messaggi possono fallire o risultare non allineati.
Quando l’azienda migra la posta o cambia provider, aggiorna con attenzione SPF, DKIM e DMARC insieme ai record MX e agli altri record DNS. Non cancellare il vecchio SPF o cambiare i nameserver alla cieca: prima individua tutti i mittenti e programma la transizione. Per un controllo strutturato della posta, dei DNS e della configurazione Microsoft 365, può essere utile coinvolgere un tecnico di assistenza IT in Ticino, con supporto locale a Mendrisio e Chiasso.
SPF, DKIM e DMARC migliorano l’affidabilità, non promettono inbox
Una configurazione corretta riduce la possibilità che terzi usino il tuo dominio per impersonare l’azienda e dà ai destinatari più elementi per valutare un messaggio. Non garantisce, da sola, che ogni email arrivi nella posta in arrivo. Anche un messaggio autenticato può finire nello spam a causa di reputazione, contenuto, reclami, liste non aggiornate, invii improvvisi o regole specifiche del ricevente.
Perciò tieni separate due verifiche: autenticazione (il mittente è autorizzato e allineato?) e recapito (il destinatario accetta e colloca il messaggio correttamente?). Se i test di autenticazione passano ma la posta continua a finire nello spam, analizza reputazione, volume e contenuto, e chiedi dati al provider o al destinatario. Cambiare ripetutamente DNS senza una diagnosi può peggiorare la situazione.
Checklist finale per il titolare di una PMI
- Conosci tutti i servizi che inviano email usando il tuo dominio?
- Hai un solo record SPF coerente con quei mittenti e senza superare i limiti di lookup?
- DKIM è attivo per Microsoft 365 e per i servizi terzi che inviano per tuo conto?
- Hai DMARC e qualcuno analizza i rapporti aggregati?
- Le modifiche DNS sono documentate e testate dopo la propagazione?
- Hai distinto un errore di autenticazione da un problema di reputazione o contenuto?
Se non sai rispondere, non applicare una policy reject per tentativi. Parti da un inventario e da controlli osservabili, quindi pianifica la correzione con il gestore del dominio e della posta.
FAQ
SPF, DKIM e DMARC fanno sempre uscire le email dallo spam?
No. Migliorano autenticazione e protezione contro lo spoofing, ma non garantiscono la collocazione in inbox. Contano anche reputazione, contenuto, comportamento d’invio e regole del provider destinatario.
Devo avere per forza una policy DMARC reject?
Non necessariamente subito. Inizia monitorando i risultati e assicurati che i mittenti legittimi siano configurati e allineati. Una policy restrittiva è una decisione da prendere dopo aver analizzato il traffico e aver verificato l’impatto.
Posso pubblicare più record SPF?
La configurazione standard prevede un singolo record SPF per nome di dominio. Se ci sono più servizi, le autorizzazioni devono essere consolidate correttamente nel record, rispettando i limiti SPF.
Un plugin o un sito web può influire sulla posta aziendale?
Sì. Moduli di contatto e applicazioni possono spedire notifiche usando il dominio aziendale. Devono essere configurati con un metodo di invio autenticato e inclusi nell’inventario dei mittenti; evitare di autorizzare sorgenti senza verificarle.
Come controllo se Microsoft 365 firma con DKIM?
Usa le indicazioni correnti nel centro di amministrazione Microsoft 365 per il tuo dominio e verifica i record richiesti e lo stato del selector. Completa poi una prova controllata leggendo gli header di autenticazione del messaggio ricevuto.
Fonti tecniche
- Google: linee guida per i mittenti di email
- Microsoft Learn: autenticazione della posta elettronica in Microsoft 365
- RFC 7489: DMARC
Per migliorare la sicurezza del dominio e ridurre gli errori di configurazione, richiedi una verifica dei sistemi di posta e dei record DNS al team di assistenza IT in Ticino, Mendrisio o Chiasso.




