# SPF, DKIM e DMARC: cosa sono e perché contano per le email
Table of Contents
C’è un dettaglio poco noto della posta elettronica: il mittente di un’email si può falsificare con estrema facilità. Il nome e l’indirizzo che compaiono nel campo “Da” (in inglese From) sono un po’ come il mittente scritto a mano sul retro di una busta: di per sé, nessuno garantisce che siano veri. Su questa debolezza si reggono buona parte dello spam, del phishing e dello spoofing, cioè le email che si spacciano per qualcun altro. SPF, DKIM e DMARC sono i tre strumenti nati per rimettere ordine. Servono a una cosa sola: dimostrare che un messaggio arriva davvero da chi dice di arrivare.
Il problema: la posta nasce senza controlli
Quando la posta elettronica è stata progettata, la rete era piccola e fatta di macchine che si fidavano l’una dell’altra. Scrivere il proprio nome nel campo mittente bastava, perché non c’era motivo di mentire. Quel modello non prevedeva alcuna verifica dell’identità, ed è rimasto tale: ancora oggi, tecnicamente, chiunque può inviare un’email indicando come mittente un indirizzo che non gli appartiene.
Le conseguenze sono due, ed è utile tenerle distinte perché i tre strumenti nascono proprio per affrontarle. La prima è la sicurezza: un truffatore può scrivere “da parte” della tua banca o della tua azienda e ingannare chi riceve. La seconda è la deliverability, cioè la capacità di un’email legittima di arrivare davvero nella casella giusta invece di finire nello spam. I grandi provider filtrano enormi volumi di posta, e un mittente che non riescono a verificare è, per definizione, sospetto.
SPF, DKIM e DMARC non si escludono a vicenda: lavorano insieme, ciascuno su un pezzo del problema. Vediamoli uno alla volta.
SPF: chi può spedire per un dominio
SPF sta per Sender Policy Framework ed è descritto nella RFC 7208. Risponde a una domanda precisa: quali server sono autorizzati a spedire posta per un certo dominio?
L’idea è semplice. Il proprietario di un dominio pubblica, tra le impostazioni pubbliche del dominio stesso (i cosiddetti record DNS, la “rubrica” che traduce i nomi di Internet), un elenco degli indirizzi dei server autorizzati. Quando arriva un messaggio, il server ricevente legge quell’elenco e controlla se il server che glielo sta consegnando è nella lista. Se c’è, il controllo passa; se non c’è, qualcosa non torna.
Il paragone è quello di un elenco al banco della posta: “per questa azienda possono spedire solo questi uffici”. Una lettera che parte da un ufficio non autorizzato viene guardata con sospetto.
In pratica è una singola riga di testo, e un dominio deve averne una sola. Assomiglia a questa:
example.com. IN TXT "v=spf1 include:_spf.provider.tld -all"La parte finale, -all, dice al ricevente come trattare chi non è in lista: rifiutalo. Un’alternativa più morbida, ~all, significa “trattalo come sospetto ma non rifiutarlo del tutto”, ed è comoda nella fase iniziale, quando non si è ancora sicuri di aver elencato tutti i propri mittenti.
SPF ha un limite importante da conoscere: controlla il “percorso” del messaggio, cioè il server che lo spedisce, non il suo contenuto. È il motivo per cui, da solo, non basta.
DKIM: la firma che prova l’integrità
DKIM sta per DomainKeys Identified Mail ed è descritto nella RFC 6376. Se SPF verifica da dove parte il messaggio, DKIM verifica il messaggio stesso.
Funziona con la crittografia a chiavi, lo stesso principio delle firme digitali. Il server che spedisce applica al messaggio una firma calcolata con una chiave privata, che tiene segreta. Chi riceve recupera la corrispondente chiave pubblica (di nuovo dai record DNS del dominio) e la usa per verificare la firma. Se il conto torna, due cose sono dimostrate: il messaggio proviene davvero da quel dominio, e non è stato alterato durante il viaggio. Se anche solo una virgola fosse cambiata in transito, la firma non tornerebbe più.
Il paragone qui è il sigillo di ceralacca su una lettera. Non ti dice solo chi l’ha spedita: se il sigillo è intatto, ti garantisce anche che nessuno ha aperto e modificato la busta lungo la strada.
La firma viaggia dentro un’intestazione tecnica del messaggio, invisibile all’utente comune, chiamata DKIM-Signature. Al suo interno due indicazioni contano più delle altre: il dominio che firma (il tag d=) e il selettore (il tag s=), un’etichetta che permette a uno stesso dominio di avere più chiavi attive e di sostituirle senza interruzioni.
DMARC: la regola su cosa fare quando i controlli falliscono
Restano due lacune. Primo: né SPF né DKIM dicono al ricevente cosa fare quando un controllo fallisce. Secondo, e più sottile: entrambi verificano un dominio “tecnico”, che l’utente non vede, e non garantiscono che coincida con l’indirizzo mostrato nel campo “Da”. Un messaggio potrebbe superare i controlli su un dominio qualsiasi e mostrarne un altro all’utente.
DMARC colma entrambe le lacune. Sta per Domain-based Message Authentication, Reporting, and Conformance; dal 2026 il riferimento aggiornato è la RFC 9989, che ha sostituito la storica RFC 7489 e ha reso DMARC uno standard vero e proprio.
Il suo primo compito si chiama allineamento (in inglese alignment). DMARC pretende che il dominio verificato da SPF o da DKIM corrisponda a quello che l’utente legge nel campo “Da”. Se un messaggio supera SPF o DKIM ma su un dominio diverso da quello visibile, per DMARC non è allineato. Basta che uno dei due controlli passi e sia allineato perché DMARC sia soddisfatto.
Il secondo compito è dare l’istruzione. Il proprietario del dominio pubblica una regola, di nuovo come record DNS, che indica cosa fare con i messaggi che non superano l’allineamento. Le tre opzioni previste sono:
p=none: non fare nulla di speciale, limitati a osservare. È la fase di monitoraggio.p=quarantine: tratta il messaggio come sospetto, di solito recapitandolo nella cartella spam.p=reject: rifiuta il messaggio, che non viene proprio consegnato.
Il record vive a un indirizzo dedicato e assomiglia a questo:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:report@example.com"Quella parte rua introduce la terza funzione, spesso la più utile: i report. I provider riceventi inviano periodicamente al proprietario del dominio dei resoconti (documenti in formato XML) che elencano chi ha spedito a suo nome e con quale esito. È così che si scopre sia chi abusa del proprio dominio, sia i propri servizi legittimi dimenticati, per esempio un gestionale o una piattaforma di newsletter. Senza questi report si procede alla cieca.
Come si incastrano i tre
Messi in fila, i tre strumenti coprono aspetti diversi e complementari:
- SPF verifica il percorso: da quale server parte il messaggio.
- DKIM verifica l’integrità: il contenuto è autentico e non è stato manomesso.
- DMARC lega i primi due all’indirizzo che l’utente vede davvero e decide cosa fare quando qualcosa non torna, oltre a fornire i report.
Nessuno dei tre da solo è sufficiente. SPF senza DMARC non protegge l’indirizzo visibile; DKIM senza DMARC non dice cosa fare in caso di fallimento; DMARC senza SPF né DKIM non ha nulla da controllare. È l’insieme a funzionare.
Perché contano oggi
Fino a qualche anno fa configurarli era considerato una buona pratica facoltativa. Non lo è più. Dal 2024 Google e Yahoo li richiedono esplicitamente a chi invia grandi volumi di posta: secondo le linee guida ufficiali di Google, chi supera i 5.000 messaggi al giorno verso caselle Gmail deve avere SPF e DKIM configurati e una regola DMARC attiva, anche solo minima (p=none), con l’indirizzo visibile allineato al dominio di SPF o di DKIM. Senza questi controlli, le email rischiano semplicemente di non arrivare.
Vale anche per chi invia poca posta. Un dominio senza autenticazione è un dominio che chiunque può usare per truffe a nome di chi lo possiede, ed è anche un dominio che i filtri antispam trattano con più diffidenza.
Come si imposta, a grandi linee
Tutti e tre si configurano nello stesso posto, i record DNS del dominio, e non richiedono di toccare i server di posta se ci si appoggia a un provider che li supporta. Lo schema generale è questo: si pubblica il record SPF con l’elenco dei mittenti autorizzati, si attiva la firma DKIM e si pubblica la relativa chiave pubblica, infine si pubblica il record DMARC.
Il passaggio più delicato è proprio DMARC, e l’ordine consigliato è graduale: si parte da p=none, si leggono i report per capire chi spedisce davvero a proprio nome, si sistemano gli eventuali mittenti legittimi rimasti fuori e solo allora si irrigidisce la regola verso quarantine e poi reject. Farlo di colpo rischia di bloccare email legittime che non si sapeva di avere. La logica è semplice: prima si guarda, poi si decide.
In sintesi
SPF, DKIM e DMARC sono tre risposte a un difetto di nascita della posta elettronica: chiunque può fingersi un altro. SPF dice chi è autorizzato a spedire, DKIM firma il messaggio per dimostrarne l’integrità, DMARC lega i due controlli all’indirizzo visibile e decide cosa fare quando falliscono. Insieme riducono spoofing e phishing e aiutano i messaggi legittimi ad arrivare a destinazione. Non sono più un extra: sono il minimo perché la posta di un dominio sia presa sul serio.
