SPF, DKIM e DMARC: il Suo dominio e-mail è protetto dallo spoofing?

Perché lo spoofing delle e-mail funziona ancora

Il protocollo che trasporta la posta elettronica (SMTP) è stato progettato senza alcuna verifica del mittente reale. Chiunque può inviare un messaggio con il Suo indirizzo nel campo Da, da qualsiasi server al mondo. Per questo le truffe con fatture false, coordinate bancarie modificate e messaggi a nome dell'amministratore o di un fornitore funzionano ancora così bene.

Tre record DNS chiudono questa falla. SPF indica quali server possono inviare posta per il Suo dominio, DKIM aggiunge a ogni messaggio una firma crittografica e DMARC dice ai destinatari cosa fare con un messaggio che non supera le verifiche e Le invia report al riguardo. Nessuno basta da solo: la vera protezione arriva solo quando tutti e tre lavorano insieme e DMARC applica una policy effettiva.

Lo strumento qui sopra legge questi record dal DNS pubblico e mostra per ciascuno se è in ordine e quale record pubblicare come passo successivo.

Record SPF: chi può inviare a Suo nome

SPF (RFC 7208) è un record TXT sulla radice del dominio, ad esempio v=spf1 include:spf.protection.outlook.com -all. Il server di destinazione verifica se l'indirizzo IP del mittente è nell'elenco. La maggior parte dei problemi nasce da tre regole:

• Esattamente un record. Due record che iniziano con v=spf1 non si sommano: causano un errore permanente (permerror) e SPF fallisce per tutta la posta. Quando aggiunge un nuovo servizio, estenda il record esistente invece di crearne un secondo.
• Al massimo 10 query DNS. Ogni include, a, mx, exists e redirect, anche dentro i record inclusi, conta nel limite di 10. Pochi servizi di newsletter e CRM lo superano rapidamente. Lo strumento stima il numero seguendo gli include.
• Una chiusura sensata. -all (rifiuta i mittenti non elencati) e ~all (segnalali come sospetti) vanno entrambi bene in presenza di DMARC. ?all non protegge e +all consente a tutta Internet di inviare a Suo nome.

SPF ha un punto debole: verifica il mittente tecnico della busta, non l'indirizzo Da che vede il destinatario, e si interrompe quando un messaggio viene inoltrato. Per questo servono DKIM e DMARC.

DKIM: una firma che sopravvive all'inoltro

Con DKIM (RFC 6376) il server mittente firma ogni messaggio con una chiave privata e il destinatario verifica la firma con la chiave pubblica pubblicata nel DNS su <selettore>._domainkey.azienda.it. La firma sopravvive anche alla maggior parte degli inoltri, quindi DKIM è di solito la base più affidabile per DMARC.

Il selettore è un nome libero scelto dal provider. Microsoft 365 usa selector1 e selector2, pubblicati come record CNAME che puntano a Microsoft. Google Workspace usa per impostazione predefinita google. Le piattaforme di newsletter e CRM ne hanno ciascuna uno proprio. Poiché i selettori non si possono elencare dal DNS, uno strumento può verificare solo i nomi più comuni. Se non trova nulla, guardi l'intestazione DKIM-Signature di un messaggio inviato: il tag s= è il Suo selettore, che può inserire nello strumento.

Dove il provider lo consente, usi chiavi RSA a 2048 bit. Google le raccomanda nelle linee guida per i mittenti, e in Microsoft 365 può passare da 1024 a 2048 bit alla prossima rotazione delle chiavi.

Verifica DMARC: la policy che unisce tutto

DMARC è un record TXT su _dmarc.azienda.it. Un messaggio supera DMARC quando SPF o DKIM hanno esito positivo e il dominio verificato coincide (è allineato) con il dominio dell'indirizzo Da visibile. Il record stabilisce anche una policy per i messaggi che non superano la verifica:

Il tag rua indica l'indirizzo per i report aggregati, file XML in cui i destinatari elencano quali server hanno inviato posta a Suo nome e con quale esito. Senza di essi si lavora alla cieca, quindi inizi sempre con p=none e un indirizzo rua, ad esempio v=DMARC1; p=none; rua=mailto:dmarc-reports@azienda.it. Un servizio di report DMARC rende leggibile l'XML.

A maggio 2026 l'IETF ha pubblicato la RFC 9989, che sostituisce la specifica DMARC originale, la RFC 7489. I record v=DMARC1 esistenti continuano a funzionare. Le novità più visibili sono l'eliminazione del tag pct, sostituito dal tag di test t=y, e il nuovo tag np, che stabilisce la policy per i sottodomini inesistenti.

Cosa richiedono Gmail e Yahoo

Da febbraio 2024 Gmail richiede a tutti i mittenti SPF o DKIM. Chi invia più di 5.000 messaggi al giorno ad account Gmail deve avere SPF e DKIM, un record DMARC (la policy può essere none), un dominio Da allineato con SPF o DKIM, la disiscrizione con un clic per la posta di marketing e un tasso di spam inferiore allo 0,3%. Yahoo prevede in pratica le stesse regole per i mittenti massivi. Anche se invia meno messaggi, queste regole indicano la direzione: la posta non autenticata finisce sempre più spesso nello spam o viene rifiutata.

Gli errori più comuni

• Mittenti dimenticati. Il gestionale invia le fatture, l'e-commerce le conferme d'ordine, l'helpdesk le notifiche dei ticket, e nessuno è in SPF o firma con DKIM. Compaiono nei report DMARC non appena inizia a leggerli.
• Anni con p=none. Il monitoraggio è una fase, non una protezione. Pianifichi il passaggio a quarantine e reject con date precise.
• Policy debole per i sottodomini. sp=none accanto a p=reject consente di inviare da sottodomini inventati.
• Domini parcheggiati non protetti. I domini che non inviano posta hanno bisogno di v=spf1 -all e v=DMARC1; p=reject, altrimenti sono ideali per lo spoofing. Vale anche per i vecchi domini dopo un cambio di ragione sociale.
• Due record SPF dopo un cambio di provider e record SPF oltre il limite di query.

Ricordi infine che la PEC ha regole e infrastruttura proprie: la verifica riguarda la normale posta elettronica del Suo dominio aziendale.

Un percorso sicuro verso p=reject

1. Elenchi tutti i servizi che inviano posta a Suo nome.
2. Pubblichi un solo record SPF e attivi DKIM per il sistema di posta principale e per ogni servizio.
3. Pubblichi DMARC con p=none e rua e legga i report per due-quattro settimane.
4. Corregga i mittenti non allineati e passi a p=quarantine.
5. Quando i report restano puliti, passi a p=reject e continui a monitorarli.

Proteggere il dominio dallo spoofing è una parte sensata delle misure di gestione del rischio informatico richieste dalla NIS2. Per sapere se la direttiva La riguarda, consulti la guida NIS2 e D.Lgs. 138/2024; per una verifica più ampia delle difese, la valutazione della preparazione a un attacco informatico.

Humanfrog configura e gestisce Microsoft 365 e la sicurezza della posta, compresi SPF, DKIM, report DMARC e il passaggio graduale a p=reject senza perdere messaggi. Se desidera esaminare il risultato con un esperto, ci scriva.