SPF, DKIM e DMARC per le scuole italiane
Tre record DNS per proteggere il dominio scolastico da spoofing e phishing. Guida pratica per l’ICT referent con esempi reali su Google Workspace e pannello DNS generico.
@nomescuola.edu.it — circolari false, comunicazioni ai genitori, phishing verso il personale. SPF da solo non è sufficiente.
Il problema: perché le email scolastiche sono falsificabili
Cos’è lo spoofing
Lo email spoofing è la falsificazione del campo mittente di un’email. Un attaccante invia un messaggio che nell’intestazione riporta mittente@nomescuola.edu.it, pur non avendo alcun accesso al dominio o ai server della scuola. Il destinatario vede un mittente apparentemente legittimo — il preside, la segreteria, un docente — mentre il messaggio proviene da un server completamente estraneo.
Le conseguenze pratiche in ambito scolastico: comunicazioni false ai genitori, richieste di pagamento fraudolente, phishing verso il personale con link a siti malevoli, circolari contraffatte. Lo spoofing non richiede di violare i sistemi della scuola — sfrutta una lacuna strutturale del protocollo email.
Il protocollo SMTP non prevede autenticazione del mittente. Un server remoto può dichiarare di essere noreply@nomescuola.edu.it senza possedere il dominio. I tre meccanismi di autenticazione email — SPF, DKIM e DMARC — esistono per risolvere questo problema, ma richiedono configurazione manuale lato DNS.
Le scuole italiane gestiscono dati sensibili di minori, comunicano con famiglie e personale tramite email, e spesso usano Google Workspace come infrastruttura di posta. Eppure nella maggior parte dei casi DKIM non è mai stato attivato e DMARC è completamente assente.
I tre meccanismi: cosa fanno
| Meccanismo | Cosa fa | Dove vive | Impatto se assente |
|---|---|---|---|
| SPF | Dichiara quali server sono autorizzati a inviare email per il dominio | Record TXT nel DNS | Parziale — molti server non lo verificano in modo strict |
| DKIM | Firma crittografica su ogni email: garantisce autenticità e integrità del messaggio | Record TXT nel DNS + configurazione sul mail server | Alto — email falsificabili, maggiore probabilità di finire in spam |
| DMARC | Coordina SPF e DKIM: dice ai server riceventi cosa fare in caso di fallimento | Record TXT nel DNS | Alto — SPF e DKIM senza DMARC hanno efficacia limitata |
SPF — Sender Policy Framework
SPF è una lista bianca pubblicata nel DNS che indica quali server possono inviare email per il dominio. Un esempio tipico per una scuola con Google Workspace e servizio di hosting esterno per il sito web:
v=spf1 include:_spf.google.com include:spf.tuoprovider.it -all
include:_spf.google.com autorizza i server Google Workspace. include:spf.tuoprovider.it autorizza il server di hosting (necessario se il sito WordPress invia email transazionali — verificare il valore corretto nella documentazione del proprio provider). -all rifiuta tutto il resto.
~all e -all nello stesso record — il secondo sovrascrive il primo ma alcuni parser si comportano in modo imprevedibile. Usare solo -all alla fine.
DKIM — DomainKeys Identified Mail
DKIM aggiunge una firma digitale a ogni email in uscita. Il server ricevente verifica la firma usando la chiave pubblica pubblicata nel DNS. Se la firma non corrisponde, il messaggio è stato alterato o non proviene dal dominio dichiarato.
Con Google Workspace la chiave viene generata dall’admin panel — non è necessario gestire crittografia manualmente. Google genera una coppia di chiavi RSA a 2048 bit e fornisce il record TXT da pubblicare.
Nome: google._domainkey.nomescuola.edu.it
```
Tipo: TXT
Valore: v=DKIM1; k=rsa; p=MIIBIjAN…
google._domainkey è specifico di Google Workspace. Se la posta è gestita da un altro provider, il selettore e la procedura di generazione cambiano.
DMARC — Domain-based Message Authentication
DMARC è il livello di controllo sopra SPF e DKIM. Definisce la policy che i server riceventi devono applicare quando un’email fallisce l’autenticazione, e invia report aggregati all’amministratore.
Nome: _dmarc.nomescuola.edu.it
```
Tipo: TXT
Valore: v=DMARC1; p=none; rua=mailto:admin@nomescuola.edu.it
Il parametro p= definisce la policy:
| Policy | Comportamento | Quando usarla |
|---|---|---|
p=none |
Solo monitoring — nessun impatto sulla consegna | Fase iniziale — iniziare sempre da qui |
p=quarantine |
Email non autenticate finiscono in spam | Dopo verifica — quando i report mostrano nessun falso positivo |
p=reject |
Email non autenticate vengono rifiutate | Solo con certezza — massima protezione, massimo rischio se mal configurato |
Procedura pratica: Google Workspace
La procedura che segue è quella adottata per il dominio cigna-baruffi-garelli.edu.it (IIS Cigna-Baruffi-Garelli, Mondovì) come caso reale. I passi sono replicabili su qualsiasi scuola con la stessa infrastruttura.
Verifica SPF esistente
Controlla i record TXT attuali nel pannello DNS del proprio provider. Se SPF è presente, verifica che contenga sia include:_spf.google.com che include:spf.tuoprovider.it e che termini con un solo qualificatore (-all o ~all, non entrambi).
Genera la chiave DKIM su Google Admin
Google Admin → Apps → Google Workspace → Gmail → Autenticazione email. Seleziona il dominio, clicca “Genera nuovo record”. Scegli 2048 bit (consigliato), prefisso selettore google. Copia il valore del record TXT fornito — non cliccare ancora “Avvia autenticazione”.
Pubblica il record DKIM sul pannello DNS
Pannello DNS del provider → Aggiungi record TXT. Nome: google._domainkey (il provider completa automaticamente il dominio). Contenuto: il valore copiato da Google Admin. TTL: 86400.
Pubblica il record DMARC sul pannello DNS
Aggiungi un secondo record TXT. Nome: _dmarc. Contenuto: v=DMARC1; p=none; rua=mailto:tuacasella@dominio.edu.it. TTL: 86400. Usa la casella dell’ICT referent o del responsabile IT come destinatario dei report.
Attendi la propagazione DNS
Con TTL 86400 la propagazione può richiedere fino a 24 ore. Verifica con MXToolbox SuperTool inserendo il dominio senza www.
Avvia autenticazione DKIM su Google Admin
Dopo la propagazione, torna su Google Admin → Gmail → Autenticazione email → “Avvia autenticazione”. Google verifica il record DNS e attiva la firma. L’operazione è reversibile in qualsiasi momento.
Domini multipli: il caso degli istituti comprensivi
Gli istituti con più domini (es. dominio principale e dominio studenti separato) devono configurare DKIM e DMARC per ciascuno. La procedura è identica — su Google Admin si seleziona il dominio secondario e si genera una chiave distinta. I record vengono pubblicati come sottodomini nel DNS principale.
google._domainkey.studenti TXT v=DKIM1; k=rsa; p=...
```
_dmarc.studenti TXT v=DMARC1; p=none; rua=mailto:admin@dominio.edu.it
Checklist finale
- OK Record SPF presente con
include:_spf.google.come un solo qualificatore finale - OK Record DKIM pubblicato (
google._domainkey) per ogni dominio che invia email - OK Autenticazione DKIM avviata su Google Admin per ogni dominio
- OK Record DMARC pubblicato (
_dmarc) conp=noneeruavalido - OK Verifica con MXToolbox: MX, SPF, DKIM e DMARC tutti verdi
- OK Trattamento dati documentato nel registro ex art. 30 GDPR
p=none, analizza i report DMARC ricevuti via email. Se non compaiono falsi positivi (email legittime che falliscono l’autenticazione), puoi passare a p=quarantine per una protezione effettiva contro lo spoofing.
Riferimenti
RFC 7208 — SPF · RFC 6376 — DKIM · RFC 7489 — DMARC · AgID — Linee guida sicurezza ICT PA · MXToolbox SuperTool
“`