SPF, DKIM e DMARC: perché la sicurezza delle email inizia dal DNS 📧🛡️

Puoi avere un sito veloce, un certificato HTTPS valido e un server aggiornato, ma lasciare scoperto un punto che molti sottovalutano: l’identità del tuo dominio quando invia email. 📧 È proprio qui che entrano in gioco SPF, DKIM e DMARC.

Non sono tre sigle da aggiungere a caso nei DNS. Sono meccanismi complementari che aiutano i server destinatari a capire se un messaggio è autorizzato e se qualcuno sta cercando di impersonare il tuo dominio.

SPF: quali server possono inviare per il tuo dominio?

SPF (Sender Policy Framework) è un record TXT pubblicato nel DNS che indica quali infrastrutture possono inviare posta per un dominio utilizzato nel percorso SMTP. Per esempio, un record minimale potrebbe essere:

v=spf1 include:_spf.example.net -all

Questo è soltanto un esempio: _spf.example.net è un segnaposto, non un provider da copiare nella propria configurazione. Bisogna inserire gli host e gli include indicati dai servizi che inviano davvero email: hosting, newsletter, CRM, applicazioni e provider transazionali.

Un errore comune è pubblicare più record SPF separati sullo stesso dominio: può rendere invalida la valutazione SPF. Anche la quantità di lookup DNS effettuati dal record va controllata.

DKIM: una firma per verificare l’integrità del messaggio ✍️

DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica al messaggio. Il server destinatario recupera la chiave pubblica dal DNS e può verificare che le parti firmate non siano state alterate e che la firma corrisponda al dominio indicato.

In genere il record viene pubblicato su un nome come selector1._domainkey.example.com. Il selettore e il contenuto esatto dipendono dal provider di invio: copiarli da una guida generica non funziona.

DKIM non significa che il contenuto sia sicuro o che il mittente sia affidabile: certifica una proprietà tecnica del messaggio, non la buona fede di chi lo ha scritto.

DMARC: cosa fare quando i controlli non tornano 🚦

DMARC collega i risultati SPF e DKIM al dominio visibile nel campo From, introducendo il concetto di allineamento. Permette inoltre al proprietario del dominio di pubblicare una politica per i messaggi che non superano i controlli.

Un record iniziale orientato al monitoraggio può avere questa struttura:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Anche qui indirizzo e dominio sono esempi. La casella per i report deve essere configurata per riceverli e, se appartiene a un dominio esterno, potrebbero essere necessarie ulteriori autorizzazioni DNS.

Le politiche principali sono:

• p=none: osservare i risultati senza richiedere una particolare azione di quarantena o rifiuto.
• p=quarantine: chiedere ai destinatari di trattare con maggiore cautela i messaggi non conformi.
• p=reject: chiedere di rifiutare i messaggi che non superano DMARC.

Il passaggio a una politica più restrittiva va fatto dopo aver verificato tutti i sistemi di invio legittimi. Altrimenti rischi di penalizzare anche le tue newsletter o le notifiche applicative.

Perché SPF da solo non basta

Un messaggio può superare SPF per un dominio tecnico diverso da quello che l’utente vede nel campo From. DMARC serve anche a verificare l’allineamento, tramite SPF o DKIM, con il dominio mostrato al destinatario. Questo è uno dei motivi per cui la protezione efficace richiede una configurazione coordinata.

Naturalmente questi controlli non eliminano ogni forma di phishing: un criminale può registrare un dominio simile al tuo oppure inviare messaggi da un account legittimo compromesso. Ho approfondito questi scenari nell’articolo su come riconoscere il phishing.

La procedura che seguirei su un dominio reale 🔍

1. Inventariare ogni sistema autorizzato a inviare email per il dominio.
2. Verificare l’SPF esistente ed evitare record duplicati.
3. Abilitare DKIM per ciascun provider che lo supporta.
4. Pubblicare DMARC inizialmente in modalità di monitoraggio.
5. Analizzare i report e correggere i flussi non allineati.
6. Rafforzare gradualmente la policy dopo aver verificato la consegna dei messaggi legittimi.

Per i controlli DNS iniziali sono utili comandi come dig TXT example.com e dig TXT _dmarc.example.com. Il risultato va però interpretato insieme agli header dei messaggi realmente consegnati.

Un dettaglio importante per chi sviluppa applicazioni

Se una web app invia conferme di registrazione, recuperi password o notifiche, la reputazione del dominio e la corretta autenticazione dei messaggi incidono sull’affidabilità percepita del servizio. 🔐 Conviene quindi trattare l’email transazionale come parte dell’infrastruttura applicativa, non come una funzione accessoria.

Per approfondire le specifiche, i riferimenti tecnici sono RFC 7208 (SPF), RFC 6376 (DKIM) e RFC 7489 (DMARC).