SPF, DKIM e DMARC: basi della sicurezza e-mail contro phishing

Questo post spiega i rischi e la teoria alla base di SPF, DKIM e DMARC, e perché le permutazioni di dominio (domini simili) sono l'amplificatore silenzioso che trasforma "una singola email contraffatta" in un disastro per il marchio, le finanze e il furto di credenziali.

Il problema principale: l'email è stata creata per la consegna, non per l'identità

SMTP (il protocollo che fa circolare le email) è stato progettato in un'epoca in cui la fiducia era implicita. Di default:

L'intestazione “Da:” è solo testo.
Chiunque può provare a inviare email fingendo di essereceo@yourcompany.com

Molti sistemi di posta hanno storicamente accettato i messaggi purché potessero essere consegnati.

Le difese moderne aggiungono l'autenticazione a livello di dominio sopra l'SMTP. È quello che fanno SPF, DKIM e DMARC.

SPF: “Quali server sono autorizzati a inviare email per il mio dominio?”

SPF (Sender Policy Framework) è un record DNS che elenca i server di posta (o i servizi di invio) autorizzati a inviare email utilizzando il tuo dominio nel campo envelope-from / return-path.

Come funziona SPF (teoria)

Quando un server di posta ricevente riceve un messaggio, controlla:

Quale dominio viene utilizzato nel mittente dell'involucro (Return-Path).
Quel dominio pubblica un record SPF nel DNS?
L’IP di connessione è autorizzato da quel record SPF?

Se sì → SPF superato. Se no → SPF fallito (o softfail/neutro a seconda della politica).

Esempio di record SPF

example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Modalità comuni di fallimento SPF (in cui gli hacker hanno la meglio)

Troppo permissivo:v=spf1 +all

(in pratica “chiunque può inviare”).

Softfail perpetuo:~all

senza applicazione DMARC, che porta a una gestione “indifferente”.

Inclusioni mancanti: il tuo CRM, sistema di ticketing, strumento per newsletter non è elencato → la posta legittima fallisce.
Limite di ricerca DNS: SPF ha un limite di 10 ricerche DNS; catene complesse diinclude:

possono interrompere la consegna.

SPF protegge solo il dominio dell'involucro: gli hacker possono comunque far sembrare che il mittente visibile sia tu, a meno che DMARC non imponga l'allineamento.

Conclusione: SPF è necessario, ma non sufficiente per fermare lo spoofing.

DKIM: “Questa email è stata davvero inviata da qualcuno con la chiave privata del dominio?”

DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica ai messaggi in uscita. Il mittente firma le intestazioni selezionate (e a volte il corpo) con una chiave privata. Il destinatario recupera la chiave pubblica dal DNS e verifica la firma.

Come funziona DKIM (teoria)

Il server di posta in uscita aggiunge un’intestazione del tipo: -DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Il destinatario interroga il DNS: -selector1._domainkey.example.com

→ chiave pubblica

Se la firma corrisponde → DKIM supera il controllo.

Esempio di record DNS DKIM

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Modalità di fallimento di DKIM (dove gli hacker hanno la meglio)

Assenza totale di DKIM: molti domini ancora non firmano la posta in modo coerente.
Firma selettiva: solo alcuni sistemi firmano (ad es. Microsoft 365 lo fa, il tuo strumento di marketing no).
Firme compromesse: i forwarder/le mailing list possono modificare contenuti/intestazioni e compromettere il DKIM.
Chiavi deboli/vecchie: chiavi corte o a lunga durata aumentano il rischio (se compromesse, l'impersonificazione diventa banale).
Dominio non allineato: DKIM viene superato per un dominio diverso da quello che gli utenti vedono nel campo "Da".

Conclusione: DKIM è potente perché è crittografico, ma ha bisogno di allineamento e policy: questo è il compito di DMARC.

DMARC: "Cosa devono fare i destinatari se SPF/DKIM falliscono, e corrisponde al mio campo 'Da' visibile?"

DMARC (Domain-based Message Authentication, Reporting & Conformance) mette tutto insieme:

Richiede che SPF e/o DKIM superino il controllo, e
Devono essere allineati con il dominio Da: che gli utenti vedono effettivamente.

Poi dice ai destinatari cosa fare se l’autenticazione fallisce:
-p=none

(solo monitoraggio)
-p=quarantine

(invia le email sospette a spam/posta indesiderata)
-p=reject

(blocca completamente)

Allineamento DMARC (il concetto chiave)

Gli hacker adorano questa lacuna:

SPF supera il controllo perrandom-sender.com
Il campo “Da:” mostraceo@yourcompany.com

Senza l’allineamento DMARC, un messaggio può sembrare provenire da te anche se il dominio autenticato non c’entra nulla.

DMARC dice: l’identità autenticata deve corrispondere al campo “Da” visibile, non solo a “qualcosa che ha superato un controllo da qualche parte”.

Esempio di record DMARC (monitoraggio)

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Esempio di record DMARC (applicato)

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"

Modalità di fallimento di DMARC (quando gli aggressori hanno la meglio)

**Bloccato per sempre sup=none

**: ricevi i rapporti, ma lo spoofing continua ad arrivare.

Nessun indirizzo di segnalazione / rapporti ignorati: non hai idea di chi stia abusando del tuo dominio.
Allineamento configurato male: i servizi legittimi falliscono e tu devi sospendere l'applicazione.
Lacune nei sottodomini: senza una politica sui sottodomini, gli aggressori spoofanoanything.yourcompany.com

Nessun monitoraggio esterno: DMARC non è una soluzione "imposta e dimentica" quando cambiano gli strumenti.

In sintesi: DMARC è il livello di applicazione che trasforma SPF/DKIM da "segnali" a "protezione".

Cosa fanno effettivamente gli hacker con un'autenticazione e-mail debole

Ecco i percorsi di abuso ad alto impatto che SPF/DKIM/DMARC aiutano a prevenire:

1) Frode al CEO / reindirizzamento delle fatture (BEC)

Gli hacker inviano email che sembrano provenire dalla dirigenza o dal reparto finanziario per cambiare gli IBAN, approvare pagamenti o richiedere carte regalo. Anche un solo caso di spoofing riuscito può costare più di un anno di strumenti di sicurezza.

2) Raccolta di credenziali

Un'e-mail dall'aspetto perfetto "da parte dell'IT" rimanda a una pagina di accesso falsa di Microsoft 365. Nel momento in cui le credenziali vengono acquisite, l'autore dell'attacco può passare alle caselle di posta interne reali e inviare legittime e-mail di phishing dall'interno del tuo tenant.

3) Usurpazione del marchio nei confronti di clienti/partner

Anche se il tuo team interno è formato, i tuoi clienti non lo sono. I messaggi contraffatti possono danneggiare la tua reputazione, innescare frodi e creare incubi per l'assistenza.

Permutazioni di dominio: il moltiplicatore dei “domini simili”

Anche con un’applicazione perfetta del DMARC, gli hacker possono semplicemente registrare un dominio diverso che assomiglia al tuo e inviare messaggi da lì.

Esempi: -examp1e.com

(1 al posto di l) -exarnple.com

(rn al posto di m) -example-support.com

-example.com-security.net

-exämple.com

(trucchi IDN / omografi)

TLD diversi:example.co

,example.net

,example.io

Questo fenomeno si chiama permutazione di dominio / typosquatting (e include attacchi omografici, combo-squatting, bitsquatting e altro ancora).

Perché le permutazioni sono pericolose

Gli utenti leggono le “forme”, non le stringhe: dare un’occhiata veloce all’indirizzo del mittente non è affidabile.
I client mobili nascondono i dettagli: molte interfacce comprimono o troncano le informazioni sul mittente.
SPF/DKIM/DMARC non sono d'aiuto: proteggono il tuo dominio, non i domini simili.
Gli hacker possono creare un'infrastruttura che sembra "legittima": certificati TLS, pagine di destinazione con il tuo marchio, flussi di risposta realistici.

Flusso tipico di un attacco con un dominio simile

Registrare un dominio simile al tuo.
Configura correttamente SPF/DKIM/DMARC (sì, gli hacker lo fanno).
Invia messaggi "urgenti" a finanza, risorse umane, clienti o fornitori.
Raccogli credenziali o reindirizza i pagamenti.
Se arriva una risposta, mantieni viva la conversazione (stile "thread hijacking").

Conclusione: hai bisogno sia del monitoraggio dell'autenticazione sia del rilevamento dei domini simili.

Come dovrebbe essere una configurazione "corretta": una linea guida pratica

Se vuoi una configurazione pulita e moderna:

SPF

Esattamente un record TXT SPF per dominio.
Includi solo i mittenti che usi effettivamente.
Concludi con-all

una volta convalidate tutte le fonti.

DKIM

Assicurati che ogni piattaforma di invio firmi le email.
Rinnova le chiavi periodicamente.
Usa chiavi sufficientemente forti (e non riutilizzarle all’infinito).

DMARC

Inizia conp=none

per un breve periodo per osservare i mittenti legittimi.

Passa ap=quarantine

, poi ap=reject

Usa l’allineamento rigoroso dove possibile (aspf=s; adkim=s

Considera la politica sui sottodomini (sp=

) in modo che i sottodomini non diventino una scappatoia.

Permutazioni di dominio

Controlla la presenza di domini simili tra i TLD più comuni e di evidenti errori di digitazione.
Dai priorità a quelli che:
- hanno record MX (possono inviare/ricevere email),
- ospitano pagine di phishing,
- sono stati registrati di recente,
- assomigliano al marchio + “fatturazione / login / assistenza”.

Perché il monitoraggio continuo è importante (anche se lo “configuri una volta sola”)

Il DNS cambia per motivi banali — migrazioni, cambi di fornitore, “soluzioni rapide”, domini scaduti — e questi banali cambiamenti possono compromettere silenziosamente l’autenticazione.

Il monitoraggio continuo rileva:

Errori nella ricerca SPF dopo che qualcuno ha aggiunto un nuovo strumento
Selettori DKIM rimossi o ruotati in modo errato
DMARC declassato a “p=none

”

Un dominio simile che appare all’improvviso e inizia a inviare email al tuo staff

Ecco perché AutoPhish ora include uno scanner per la sicurezza e-mail / DNS per controlli rapidi e un monitoraggio continuo con avvisi per le organizzazioni registrate.

Lista di controllo rapida che puoi copiare nel tuo runbook interno

L'SPF esiste, è unico e termina con-all

(dopo la convalida)

Tutte le fonti di posta sono state prese in considerazione (M365/Google + marketing + assistenza + transazionale)
DKIM abilitato su tutte le fonti, chiavi non scadute
DMARC esiste con la reportistica abilitata
DMARC applicato (quarantine

oreject

) con allineamento configurato

Sottodomini coperti (sp=

o DMARC esplicito sui sottodomini)

Monitoraggio dei domini simili abilitato (errori di battitura + scambi di TLD + combinazioni)
Avvisi collegati a un canale reale (email/Slack/Teams/ticketing)

Controlla il tuo dominio in pochi secondi (gratis)

Vuoi fare subito un rapido controllo? Usa l'AutoPhish DNS Checker per analizzare all'istante i tuoi record SPF, DKIM e DMARC:

AutoPhish DNS Checker: https://autophish.io/dns-check

Se desideri una protezione continua, puoi anche impostare il monitoraggio continuo con un abbonamento AutoPhish: riceverai così avvisi quando i record DNS cambiano o quando vengono rilevati domini simili.

Considerazioni finali

L'autenticazione delle email (SPF/DKIM/DMARC) è una delle poche misure di sicurezza che migliora sia la protezione che la deliverability. Aggiungi il monitoraggio dei domini simili e coprirai i due principali vettori di impersonificazione: lo spoofing del tuo dominio e lo spoofing del tuo marchio.

SPF, DKIM, DMARC e permutazioni di dominio: le basi della sicurezza e-mail che gli hacker sfruttano