Sicurezza Posta Elettronica

SPF, DKIM e DMARC Spiegati Semplice: Come Proteggere il Dominio Aziendale dallo Spam

SPF, DKIM e DMARC spiegati semplice: come proteggere il dominio aziendale dallo spam

Due mesi fa un mio cliente mi chiama. "Carlo, i nostri clienti dicono che le nostre email finiscono nello spam. Qualcuno dice che non le riceve proprio." Azienda manifatturiera, 30 dipendenti, dominio attivo da sei anni. Mai avuto problemi. Fino a quel momento.

Il primo controllo che faccio sempre e verificare i record di autenticazione email. SPF: assente. DKIM: mai configurato. DMARC: inesistente. Il dominio era nudo. Qualunque server al mondo poteva mandare email fingendo di essere @quellaazienda.it, e nessuno poteva distinguere le email vere da quelle false. E qualcuno lo stava facendo. Ma ci arrivo tra poco.

Se il tuo dominio aziendale non ha SPF, DKIM e DMARC configurati, non e questione di se avrai problemi. E questione di quando. Questa guida ti spiega cosa sono, come funzionano e come configurarli -- senza gergo da RFC, senza teoria inutile. Solo quello che serve per proteggere il tuo dominio.

Il problema che non sai di avere: qualcuno sta mandando email a tuo nome

Il protocollo email -- SMTP -- e stato progettato negli anni '80. In un'epoca in cui Internet era una rete accademica dove tutti si fidavano di tutti. Il risultato e che chiunque puo mandare un'email fingendo che arrivi da qualsiasi indirizzo. Non serve hackerare niente. Non serve rubare credenziali. Basta un server di posta e cinque righe di configurazione.

Questo si chiama spoofing, ed e la base di quasi ogni truffa via email. Il tuo fornitore riceve una fattura "da te" con un IBAN diverso? Spoofing. I tuoi clienti ricevono offerte commerciali "dalla tua azienda" che non hai mai mandato? Spoofing. Ne ho parlato con casi concreti nell'articolo sul phishing aziendale -- la dinamica e sempre la stessa.

SPF, DKIM e DMARC esistono per risolvere questo problema. Sono tre protocolli che lavorano insieme per dire al mondo: "le email vere dal mio dominio hanno queste caratteristiche. Tutto il resto, scartatelo." Non sono un optional. Sono l'equivalente digitale di avere una serratura sulla porta dell'ufficio.

SPF: chi e autorizzato a spedire per conto tuo

SPF sta per Sender Policy Framework. Il concetto e semplice: pubblichi nel DNS del tuo dominio un elenco dei server autorizzati a mandare email a tuo nome. Quando un server destinatario riceve un'email "da @tuodominio.it", controlla il record SPF e verifica se il server che l'ha spedita e nella lista. Se non c'e, l'email e sospetta.

In pratica, e un record TXT nel tuo DNS che assomiglia a questo:

v=spf1 include:_spf.google.com ~all

Tradotto: "le email dal mio dominio possono essere spedite solo dai server di Google Workspace. Tutto il resto e probabilmente falso." Se usi Microsoft 365, il record sara diverso:

v=spf1 include:spf.protection.outlook.com ~all

SPF verifica il server di invio, non il contenuto dell'email. E il primo livello di protezione: dice "da dove possono partire le email legittime". Ma non basta da solo -- perche non garantisce che il contenuto non sia stato modificato durante il transito.

DKIM: la firma digitale che certifica il contenuto

DKIM sta per DomainKeys Identified Mail. Se SPF verifica il server, DKIM verifica il messaggio. Funziona cosi: quando il tuo server di posta invia un'email, ci aggiunge una firma crittografica invisibile. Nel DNS del tuo dominio c'e la chiave pubblica corrispondente. Il server del destinatario usa quella chiave per verificare che l'email non sia stata alterata tra l'invio e la ricezione.

Pensa a DKIM come a un sigillo di ceralacca digitale. Se qualcuno intercetta l'email e cambia anche una sola virgola -- l'IBAN di una fattura, il testo di un contratto, un link -- la firma non corrisponde piu e il destinatario lo sa. Questo e fondamentale per proteggersi dalla manipolazione in transito, un tipo di attacco che descrivo nell'articolo sulla crittografia email aziendale.

Il record DKIM nel DNS e un record TXT con una chiave pubblica. Non devi generarlo a mano: il tuo provider email (Google Workspace, Microsoft 365, o chi per loro) ti fornisce il valore esatto da inserire. Lo vediamo nella sezione configurazione.

DMARC: il vigile che decide cosa fare

DMARC sta per Domain-based Message Authentication, Reporting and Conformance. E il terzo pezzo del puzzle, e forse il piu importante. Senza DMARC, SPF e DKIM possono solo segnalare problemi. DMARC dice ai server destinatari cosa fare quando un'email fallisce i controlli.

Un record DMARC base:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@tuodominio.it

Tre opzioni per la policy (il parametro p=):

  • none -- non fare niente, ma mandami i report. Utile come primo passo per monitorare senza rompere nulla.
  • quarantine -- metti in spam le email che falliscono i controlli. E il livello che consiglio come primo obiettivo concreto.
  • reject -- rifiuta le email che falliscono i controlli. Il livello massimo di protezione. Ci si arriva dopo aver verificato che tutto funziona.

Il parametro rua= dice a DMARC dove mandare i report aggregati. Questi report sono preziosi: ti dicono chi sta mandando email usando il tuo dominio, da quali server, e se passano o falliscono i controlli. E il modo piu diretto per scoprire se qualcuno sta abusando del tuo dominio.

Come funzionano insieme: il flusso completo

Ecco cosa succede quando mandi un'email a un cliente, in ordine:

  1. Il tuo server di posta (Google, Microsoft, o altro) invia l'email e ci aggiunge la firma DKIM.
  2. Il server del destinatario riceve l'email e fa due controlli: verifica SPF (il server che ha spedito e autorizzato?) e verifica DKIM (la firma corrisponde?).
  3. Il server consulta il record DMARC del tuo dominio per sapere cosa fare con il risultato: se entrambi i controlli falliscono, segue la policy (none, quarantine o reject).
  4. Se la policy e "quarantine", l'email sospetta finisce nello spam. Se e "reject", viene rifiutata. Se e "none", passa comunque ma il report viene inviato a te.

Tre protocolli, un sistema. SPF dice "chi puo spedire". DKIM dice "il contenuto e autentico". DMARC dice "cosa fare se qualcosa non torna". Togliene uno e il sistema non regge.

Configurare SPF, DKIM e DMARC su Google Workspace

Se usi Google Workspace, la configurazione e relativamente semplice. Hai bisogno dell'accesso al pannello di amministrazione Google e al pannello DNS del tuo dominio.

SPF

Vai nel pannello DNS del tuo registrar. Aggiungi un record TXT con questo valore:

v=spf1 include:_spf.google.com ~all

Se usi anche altri servizi che mandano email per conto tuo (un CRM, un sistema di fatturazione, una piattaforma di email marketing), devi aggiungere anche i loro include. Esempio:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

DKIM

Vai nella console di amministrazione Google Workspace (admin.google.com). Naviga in App > Google Workspace > Gmail > Autentica email. Seleziona il tuo dominio e clicca su "Genera nuovo record". Google ti da un record TXT da inserire nel DNS. Il nome del record sara qualcosa come google._domainkey.tuodominio.it. Copia il valore e inseriscilo nel DNS. Torna nella console Google e clicca "Avvia autenticazione".

DMARC

Aggiungi un record TXT nel DNS con nome _dmarc.tuodominio.it e valore:

v=DMARC1; p=none; rua=mailto:dmarc-reports@tuodominio.it

Parti con p=none per le prime 2-4 settimane. Leggi i report. Quando sei sicuro che tutte le email legittime passano i controlli, passa a p=quarantine. Dopo altre 2-4 settimane senza problemi, valuta p=reject.

Configurare SPF, DKIM e DMARC su Microsoft 365

Su Microsoft 365, il processo e analogo con piccole differenze.

SPF

Nel pannello DNS, aggiungi un record TXT:

v=spf1 include:spf.protection.outlook.com ~all

DKIM

Vai nel portale Microsoft 365 Defender (security.microsoft.com). Naviga in Criteri e regole > Criteri per le minacce > Impostazioni di autenticazione email > DKIM. Seleziona il tuo dominio. Microsoft genera due record CNAME da inserire nel DNS. I nomi saranno tipo selector1._domainkey.tuodominio.it e selector2._domainkey.tuodominio.it. Inserisci entrambi nel DNS, torna nel portale e attiva la firma DKIM.

DMARC

Stesso procedimento di Google: record TXT con nome _dmarc.tuodominio.it. Il valore e identico perche DMARC non dipende dal provider, dipende dal tuo dominio:

v=DMARC1; p=none; rua=mailto:dmarc-reports@tuodominio.it

Per entrambi i provider, dopo aver inserito i record DNS, servono da qualche minuto a 48 ore per la propagazione. In pratica, nella maggior parte dei casi, 15-30 minuti sono sufficienti. Se hai Outlook configurato con il tuo dominio, le email successive alla propagazione avranno gia la firma DKIM attiva.

Come verificare che tutto funzioni

Configurare e meta del lavoro. Verificare che funzioni e l'altra meta. Ecco gli strumenti che uso con i miei clienti.

MXToolbox

Vai su mxtoolbox.com e usa i tre test specifici: SPF Record Lookup, DKIM Lookup, DMARC Record Lookup. Inserisci il tuo dominio e verifica che tutti e tre i record siano presenti e validi. Se MXToolbox segnala errori, li descrive in modo chiaro con suggerimenti per risolverli.

Google Admin Toolbox (Check MX)

toolbox.googleapps.com/apps/checkmx -- inserisci il dominio e controlla tutti i record email in un colpo solo. Utile anche se non usi Google Workspace.

Test con email reale

Il modo piu affidabile: manda un'email a un indirizzo Gmail e apri il messaggio ricevuto. Clicca sui tre punti > "Mostra originale". Vedrai gli header con i risultati di SPF, DKIM e DMARC. Devono dire tutti "PASS". Se uno dice "FAIL" o "SOFTFAIL", c'e un problema da risolvere. Se le email non arrivano proprio, ho scritto una guida completa al troubleshooting dei problemi di ricezione che copre tutti gli scenari.

Gli errori che vedo ogni settimana

Dopo anni di configurazioni per PMI, questi sono gli errori ricorrenti. Li vedo cosi spesso che li ho messi in checklist.

SPF con troppi include

SPF ha un limite di 10 lookup DNS. Ogni include: conta come un lookup. Se usi Google Workspace, un CRM, un sistema di fatturazione, una piattaforma newsletter e un servizio di ticketing, potresti superare il limite senza saperlo. Risultato: l'SPF fallisce silenziosamente e le tue email finiscono nello spam. La soluzione e consolidare gli include o usare un servizio di SPF flattening.

DKIM non ruotato

La chiave DKIM andrebbe ruotata almeno una volta all'anno. Google Workspace lo rende facile: generi una nuova chiave nella console admin e aggiorni il DNS. La maggior parte delle aziende configura DKIM una volta e non lo tocca mai piu per anni. Non e un rischio immediato, ma e una pratica di igiene crittografica che riduce l'impatto in caso di compromissione della chiave.

DMARC in modalita none per sempre

Questo e l'errore piu comune in assoluto. L'azienda configura DMARC con p=none come primo passo -- corretto. Poi non passa mai a quarantine o reject. La policy none non blocca niente. Genera solo report. Se resti in none per sempre, e come mettere una telecamera di sorveglianza senza collegare l'allarme: vedi i ladri, ma non li fermi.

Record SPF duplicati

Il DNS deve avere un solo record SPF per dominio. Vedo spesso aziende che durante una migrazione aggiungono il nuovo record SPF senza rimuovere il vecchio. Risultato: due record SPF che si contraddicono e nessuno dei due funziona. MXToolbox segnala questo errore immediatamente.

Non includere tutti i servizi che mandano email

L'azienda configura SPF per Google Workspace ma dimentica che il gestionale manda fatture via email da un altro server, o che il sito web manda email di contatto da un terzo server. Tutte quelle email falliscono SPF perche il server non e nella lista. La soluzione: prima di configurare SPF, fai un inventario completo di tutti i servizi che mandano email dal tuo dominio.

Il mio protocollo di implementazione per i clienti

Questo e l'ordine che seguo sempre. Non e casuale -- ogni passo prepara il successivo.

  1. Inventario email -- Elenco di tutti i servizi che mandano email dal dominio: provider principale (Google, Microsoft), CRM, gestionale, sito web, piattaforme di marketing, PEC se separata. Se hai alias email, verifica da quali server vengono gestiti.
  2. SPF -- Configuro il record SPF includendo tutti i server identificati al punto 1. Verifico su MXToolbox che il numero di lookup sia sotto il limite di 10.
  3. DKIM -- Attivo la firma DKIM nel provider principale. Verifico con un'email di test che la firma sia presente negli header.
  4. DMARC in modalita none -- Configuro DMARC con policy none e indirizzo per i report. Aspetto 2-4 settimane e analizzo i report: verifico che tutte le email legittime passino i controlli e che non ci siano servizi dimenticati.
  5. DMARC in modalita quarantine -- Passo a quarantine. Monitoro per altre 2-4 settimane. Se non ci sono problemi con le email legittime, procedo.
  6. DMARC in modalita reject -- Arrivo a reject solo quando sono sicuro che tutto funziona. A questo punto, le email false che usano il dominio del cliente vengono bloccate prima di arrivare al destinatario.

Tempo totale: dalle 4 alle 8 settimane, dipende dalla complessita. Il lavoro tecnico vero e al punto 1 -- l'inventario. Se sbagli li, tutto il resto ne risente. Costo per il cliente: meno di una giornata di consulenza per l'implementazione, poi il sistema lavora da solo.

Il cliente che si e trovato in blacklist senza sapere perche

Torno al caso che ho aperto all'inizio. L'azienda manifatturiera con le email che finivano nello spam. Quando ho controllato il dominio su MXToolbox, oltre ai record di autenticazione mancanti ho trovato una sorpresa: il dominio era in due blacklist.

Come ci era finito? Senza SPF, DKIM e DMARC, il dominio era completamente esposto. Un attaccante lo stava usando per mandare spam -- email di phishing che arrivavano ai destinatari come se partissero da @quellaazienda.it. I server destinatari, non avendo modo di distinguere le email vere da quelle false, hanno fatto l'unica cosa sensata: hanno messo il dominio in blacklist. Risultato: anche le email vere dell'azienda venivano bloccate.

Il danno era doppio. Da un lato, i clienti dell'azienda ricevevano email truffa che sembravano arrivare da loro -- danno reputazionale. Dall'altro, le comunicazioni legittime dell'azienda non arrivavano -- danno operativo. L'azienda non sapeva nemmeno che stesse succedendo finche i clienti non hanno iniziato a lamentarsi.

La risoluzione ha richiesto tre passaggi: configurazione completa di SPF, DKIM e DMARC (una mattina di lavoro), richiesta di delisting dalle blacklist (48-72 ore per la rimozione), e monitoraggio per le due settimane successive per verificare che la deliverability tornasse alla normalita. Totale: meno di una settimana per risolvere un problema che si trascinava da mesi.

Se il cliente avesse avuto quei tre record configurati dall'inizio, l'attaccante non avrebbe potuto usare il dominio. O meglio: avrebbe potuto provarci, ma i server destinatari avrebbero rifiutato le email false. Zero spam inviato, zero blacklist, zero clienti arrabbiati.

La lezione e semplice: proteggere il dominio costa meno di un'ora di configurazione. Non proteggerlo costa settimane di problemi, clienti persi e reputazione danneggiata.

Chiusura della collana: da dove continuare

Questo articolo chiude la collana di emailaziendali.it. Venti articoli che coprono tutto quello che una PMI italiana deve sapere sulla gestione delle email aziendali, dalla configurazione iniziale del dominio fino ai protocolli di autenticazione che hai appena letto.

Se sei arrivato qui direttamente, ecco la mappa completa per orientarti:

Partire da zero:

Configurazione e migrazione:

Sicurezza:

Compliance e gestione:

Operativita quotidiana:

Ogni articolo e pensato per essere letto da solo, ma insieme formano un sistema completo. Se hai una PMI e gestisci email aziendali, da qualche parte in questa collana c'e la risposta alla tua domanda.

Se dopo aver letto vuoi qualcuno che configuri tutto al posto tuo -- SPF, DKIM, DMARC, provider, migrazione, formazione del team -- e quello che faccio di mestiere. Un servizio di consulenza IT specializzata per PMI trasforma queste guide in infrastruttura funzionante. Una mattina di lavoro, e il tuo dominio e protetto per anni.

Potrebbe interessarti