SPF, DKIM e DMARC: guida pratica alla sicurezza DNS del dominio aziendale

Un cliente ti chiama per avere conferma di una fattura con un IBAN nuovo. Tu quella fattura non l’hai mai mandata, eppure l’email sembra partita dal tuo indirizzo aziendale. Che una truffa del genere riesca o venga fermata dipende in buona parte da poche impostazioni DNS del tuo dominio, che spesso nessuno in azienda ha mai controllato.

Sono SPF, DKIM e DMARC per la posta e DNSSEC e CAA per il dominio. A queste si aggiungono la pulizia dei record che non servono più e la protezione degli account con cui si gestisce il dominio. In questa guida vediamo a cosa servono e come sistemarle, anche se non ti occupi di informatica.

Cos’è il DNS e perché riguarda anche la tua posta

Il DNS (Domain Name System) è la «rubrica» di Internet: traduce un nome facile da ricordare, come www.example.com, nell’indirizzo numerico del server che lo ospita. Ogni volta che qualcuno apre il tuo sito o ti scrive un’email, il suo computer consulta questa rubrica per sapere dove andare.^[1]

La parte della rubrica che riguarda il tuo dominio si chiama zona DNS ed è fatta di righe chiamate record, ognuna con un compito preciso. I record A collegano un nome all’indirizzo IP di un server. I CNAME fanno di un nome l’alias di un altro, spesso di un servizio esterno. Gli MX indicano a quali server consegnare la posta. I TXT contengono testo libero, ed è lì che si scrivono SPF, DMARC e le verifiche di proprietà richieste da Google, Microsoft e altri servizi. La zona è ospitata dal provider DNS, che spesso coincide con il registrar (la società da cui hai acquistato il dominio) o con l’hosting.

In molte aziende la zona DNS viene impostata una volta e poi dimenticata. Ogni nuovo fornitore aggiunge qualche record, quelli vecchi restano dove sono e nessuno controlla più se le protezioni sono attive.

Cosa può fare un attaccante con un DNS configurato male

I record DNS sono pubblici e chiunque può consultarli. Per chi prepara un attacco sono una fonte preziosa di informazioni e, se configurati male, anche una porta d’ingresso. I rischi concreti sono cinque.

• Email a nome tuo (email spoofing): senza un’autenticazione corretta della posta si possono inviare email che sembrano partire dal tuo dominio, verso clienti, fornitori o colleghi. È la base delle truffe sulle false fatture.
• Furto di un sottodominio (subdomain takeover): se un record punta a un servizio esterno dismesso, un malintenzionato può registrare quel servizio a proprio nome e pubblicare contenuti su un sottodominio legittimo della tua azienda.
• Informazioni interne esposte: record dimenticati possono rivelare indirizzi di rete interni, nomi di sistemi e fornitori usati, utili a preparare attacchi mirati.
• Certificati emessi da altri: senza restrizioni, qualunque autorità di certificazione può rilasciare un certificato per il tuo dominio.
• Dominio dirottato: chi entra nel pannello del registrar o del provider DNS controlla, di fatto, sito e posta.

Conta anche il lato normativo. La direttiva europea NIS2, recepita in Italia con il D.Lgs. 4 settembre 2024, n. 138, chiede a un numero crescente di organizzazioni misure adeguate di gestione del rischio informatico, sotto la supervisione dell’Agenzia per la Cybersicurezza Nazionale.^[2] La configurazione del dominio, poi, è tra le prime cose che clienti, partner e auditor possono verificare dall’esterno, senza chiedere nulla a nessuno.

SPF, DKIM e DMARC: come impedire che si spediscano email a nome tuo

Si parte dalla posta, perché è qui che una configurazione sbagliata si fa sentire per prima. Da febbraio 2024 Google e Yahoo chiedono a chi invia più di 5.000 email al giorno ai loro utenti SPF, DKIM e un DMARC allineato; Google chiede comunque a tutti i mittenti almeno SPF o DKIM.^{[3] [4]} Dal 5 maggio 2025 Microsoft applica regole analoghe a chi supera le 5.000 email al giorno verso Outlook.com, Hotmail e Live, e respinge i messaggi non conformi.^[5] Anche se la tua azienda invia poche email conviene configurarli, perché sono proprio questi record a impedire che altri si spaccino per te.^[6]

SPF: chi è autorizzato a spedire con il tuo dominio

Il record SPF è un record TXT che elenca i servizi autorizzati a spedire email con il tuo dominio, per esempio Microsoft 365, la piattaforma di newsletter o il CRM.^[7] Da solo non basta: SPF controlla l’indirizzo tecnico di ritorno, non quello che il destinatario vede nel campo Da, ed è per questo che serve anche DMARC. Perché funzioni, rispetta quattro regole.

• un solo record SPF per dominio: se ce ne sono due, il controllo fallisce;
• dentro, solo i servizi che usi davvero; quelli dismessi vanno tolti;
• in chiusura ~all (segna come sospetti gli altri server) oppure -all (li rifiuta). Con DMARC a regime vanno bene entrambe, e ~all evita che alcune email inoltrate vengano scartate prima del controllo DMARC. Mai +all o ?all;
• non più di 10 consultazioni DNS, contando anche quelle degli include dei fornitori: oltre, il controllo SPF va in errore e molti destinatari lo trattano come fallito.

DKIM: la firma digitale delle email

DKIM aggiunge alle email una firma crittografica che indica quale dominio se ne assume la responsabilità e dimostra che il contenuto firmato non è stato modificato lungo il percorso.^[8] Molti servizi di invio firmano di default con il proprio dominio: perché la firma conti per DMARC va configurata con il tuo. Serve per ogni servizio che invia email a tuo nome, e l’errore più comune è attivarla sullo strumento di marketing e dimenticarla sulla posta aziendale, per esempio Microsoft 365 o Google Workspace.^[9] Lo standard richiede chiavi di almeno 1024 bit e raccomanda 2048 bit o più.^[10]

DMARC: decidere cosa succede alle email false

DMARC collega i due controlli al mittente che il destinatario vede. Un’email lo supera se passa SPF o DKIM per lo stesso dominio che compare nel campo Da (si chiama allineamento); se non lo supera, il record DMARC dice ai server di posta come trattarla e ti fa arrivare report periodici su chi sta usando il tuo dominio.^[11]

In molte aziende il record DMARC c’è, ma è fermo su p=none e spesso non ha un indirizzo per i report. Così le email false vengono solo osservate, arrivano comunque ai destinatari e nessuno legge i dati. DMARC va portato a regime per gradi, in tre fasi.

1. Monitoraggio, con p=none e un indirizzo per i report (rua): servono a scoprire tutti i servizi che inviano a tuo nome.
2. Quarantena, con p=quarantine: chiedi ai destinatari di mettere nello spam le email che non superano DMARC.
3. Rifiuto, con p=reject: chiedi di respingerle. È l’obiettivo finale; i server di posta di solito rispettano la richiesta, ma la decisione resta loro.

Un esempio di record nella fase finale:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

sp=reject estende la regola ai sottodomini: prima di usarlo, verifica nei report che nessun sottodominio invii email legittime senza autenticazione. Il vecchio tag pct, che applicava la policy solo a una percentuale di email, è stato eliminato dal nuovo standard DMARC del 2026: se c’è ancora, meglio toglierlo. Per le prove il nuovo standard prevede t=y: i destinatari applicano un livello meno severo (quarantine al posto di reject, none al posto di quarantine) finché non lo togli.^[11]

Due casi che sfuggono spesso. I domini che non inviano email (vecchi marchi, domini difensivi, domini solo per il sito) vanno protetti comunque con v=spf1 -all e un DMARC in p=reject, perché sono i preferiti dai truffatori proprio in quanto nessuno li controlla. E DMARC protegge il tuo dominio esatto, non quelli simili (per esempio con una lettera cambiata): per quelli servono monitoraggio e, se il caso, registrazione difensiva.

Record dimenticati: quali cercare e quando eliminarli

Ogni record DNS rivela pubblicamente qualcosa della tua infrastruttura, e quelli che non servono più aggiungono rischio senza alcun vantaggio. Quando fai pulizia, cerca soprattutto questi quattro casi.

• CNAME verso servizi esterni dismessi (vecchi strumenti di tracking, landing page, ambienti di prova): sono la causa tipica del subdomain takeover. Lo stesso rischio vale per record A verso indirizzi cloud rilasciati e per deleghe NS dimenticate.^[12]
• Residui di vecchi fornitori, come i record di configurazione automatica della posta del provider precedente, che possono indirizzare i programmi di posta verso server sbagliati.
• Indirizzi IP privati (192.168.x.x, 10.x.x.x, 172.16-31.x.x) pubblicati nel DNS pubblico: dall’esterno non servono a nessuno e rivelano la struttura della rete interna.
• Record di servizi non più usati: gestione dei dispositivi, FTP, verifiche di dominio di piattaforme abbandonate.

Ogni record dovrebbe avere un responsabile e un motivo per esistere. Se nessuno sa a cosa serve, va verificato e, con cautela, rimosso. Quando dismetti un servizio, togli prima il record DNS e poi il servizio, non il contrario.^[13]

DNSSEC, CAA e accessi: proteggere il dominio, non solo la posta

DNSSEC

DNSSEC firma digitalmente le risposte DNS, così i resolver che la verificano possono scartare quelle falsificate. Protegge dal DNS spoofing e dal cache poisoning, attacchi che dirottano i visitatori verso server controllati da terzi.^[14] Con i principali provider si attiva in pochi clic, poi va aggiunto un record (DS) presso il registrar. Attenzione quando cambi provider DNS: un record DS non aggiornato rende il dominio irraggiungibile.

Record CAA

I record CAA indicano quali autorità di certificazione possono emettere certificati per il tuo dominio; le autorità riconosciute dai browser sono obbligate a controllarli e a rifiutare le richieste non autorizzate.^[15] Prima di attivarli includi tutte le autorità che usi davvero, comprese quelle della CDN o dell’hosting, altrimenti il rinnovo automatico dei certificati può fallire. Il check gratuito verifica sia DNSSEC sia la presenza di almeno un record CAA, e ne tiene conto nel voto.

Chi può entrare nel pannello del dominio

La configurazione più sicura non serve a nulla se l’account che la gestisce è debole. Su registrar e provider DNS attiva l’autenticazione a più fattori e il blocco al trasferimento del dominio (registrar lock). Usa accessi nominativi, riservati a chi ne ha davvero bisogno, e imposta il rinnovo automatico. Blocco al trasferimento e scadenza compaiono nei dati pubblici del registro (WHOIS/RDAP); l’autenticazione a più fattori e l’elenco di chi ha accesso, invece, li conosce solo chi amministra gli account.

Sito web: proxy, server di origine e HTTPS

Se usi una CDN o un reverse proxy, il traffico web passa da lì e l’indirizzo reale del server (il server di origine) può restare nascosto. Spesso però si scopre proprio dal DNS: record del server di posta, SPF con indirizzi ip4: o vecchi sottodomini non protetti dal proxy. La protezione funziona solo a quattro condizioni.

• il server di origine accetta il traffico web solo dal proxy, altrimenti chi scopre l’IP reale può aggirarlo;
• dal proxy passano solo i record del traffico web: posta, DKIM e configurazione automatica dei client ne restano fuori, o smettono di funzionare;
• HSTS obbliga i browser a usare sempre HTTPS: si parte con una durata breve e si estende ai sottodomini solo dopo aver verificato che supportino tutti HTTPS;^[16]
• le protezioni anti-bot vanno regolate con attenzione: se sono troppo aggressive bloccano anche motori di ricerca e assistenti AI, con effetti sulla visibilità del sito.

Checklist: 10 verifiche sul dominio aziendale

Accanto a ogni verifica trovi dove farla.

Verifica	Dove
Un solo record SPF, con i soli servizi in uso, che termina con ~all o -all	Check istantaneo; servizi in uso e 10 consultazioni a mano
DKIM attivo con il tuo dominio per tutti i servizi che inviano email, chiavi da 2048 bit	Check istantaneo (presenza sui selettori più comuni); il resto a mano
DMARC con report attivi e percorso pianificato verso p=reject	Check istantaneo
DNSSEC attivo	Check istantaneo
Record CAA con tutte le autorità che usi	Check istantaneo (presenza)
HTTPS forzato, certificato valido, HSTS attivo	Report completo
Nessun sottodominio dimenticato o servizio esposto senza motivo	Report completo (dai certificati pubblici)
Nessun CNAME verso servizi dismessi, IP privato o residuo di vecchi fornitori	Pannello DNS, a mano
Autenticazione a più fattori e blocco al trasferimento su registrar e provider DNS	Pannello del registrar, a mano
Server di origine raggiungibile solo tramite proxy	Test autorizzato (VAPT)

Controlla il tuo dominio con il check gratuito

Le configurazioni viste in questa guida sono pubbliche: chiunque può leggerle, anche chi vuole mandare email a nome della tua azienda. Il check sicurezza dominio gratuito di Talos le controlla usando solo dati pubblici, senza registrazione e senza alcun test sui tuoi sistemi.

In pochi secondi ottieni un voto da A a F su SPF, DKIM, DMARC, DNSSEC e CAA, con una spiegazione chiara per ogni voce. Se lo chiedi, entro 2 giorni lavorativi un tecnico prepara il report completo: sito e certificato, sottodomini presenti nei certificati pubblici, servizi raggiungibili da Internet con le vulnerabilità note da verificare, e le 3 cose da sistemare per prime.

Resta fuori quello che nessun controllo esterno può vedere: gli account del registrar, i record che non compaiono nei certificati pubblici, la rete interna, le applicazioni e le API dietro login. Per quelle serve il passo successivo, un Vulnerability Assessment e Penetration Test.

Domande frequenti

Come faccio a sapere se qualcuno può spedire email a nome della mia azienda?

Devi controllare SPF, DKIM e DMARC del tuo dominio. Il modo più rapido è il check sicurezza dominio gratuito di Talos: in pochi secondi ti dice se il tuo dominio chiede ai destinatari di bloccare le email false a tuo nome, di metterle nello spam o di lasciarle passare.

Cos’è la sicurezza DNS?

È l’insieme delle configurazioni e delle pratiche che proteggono il dominio di un’organizzazione da abusi come email a nome dell’azienda, furto di sottodomini, falsificazione delle risposte DNS e dirottamento del dominio.

SPF, DKIM e DMARC sono obbligatori?

Nessuna legge li impone in generale, ma Google, Yahoo e Microsoft li richiedono a chi invia grandi volumi di email, e senza di essi i messaggi rischiano di finire nello spam o di essere rifiutati. Per qualsiasi azienda sono la base per evitare che il proprio dominio venga usato nel phishing.

Cos’è un subdomain takeover?

È un attacco in cui qualcuno prende il controllo di un sottodominio legittimo sfruttando un record DNS che punta a un servizio esterno non più in uso. Si previene eliminando i record orfani e, quando si dismette un servizio, togliendo prima il record DNS.

Ogni quanto va controllata la configurazione DNS?

Almeno una volta all’anno e ogni volta che attivi o dismetti un servizio esterno: nuovo provider di posta, CRM, piattaforma di marketing, applicazione in cloud.

Fonti

1. P. Mockapetris, RFC 1034 – Domain Names: Concepts and Facilities, IETF, novembre 1987. www.rfc-editor.org
2. Agenzia per la Cybersicurezza Nazionale, NIS – Network and Information Security (D.Lgs. 4 settembre 2024, n. 138, di recepimento della Direttiva (UE) 2022/2555). www.acn.gov.it
3. Google, Linee guida per i mittenti di email, Guida di Gmail. support.google.com
4. Yahoo, Sender Best Practices, Yahoo Sender Hub. senders.yahooinc.com
5. Microsoft, Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders, Microsoft Tech Community, aprile 2025. techcommunity.microsoft.com
6. NIST, SP 800-177 Rev. 1 – Trustworthy Email, febbraio 2019. csrc.nist.gov
7. S. Kitterman, RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, IETF, aprile 2014. www.rfc-editor.org
8. D. Crocker, T. Hansen, M. Kucherawy (a cura di), RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures, IETF, settembre 2011. www.rfc-editor.org
9. Microsoft Learn, How to use DKIM for email in your custom domain, Microsoft Defender for Office 365. learn.microsoft.com
10. S. Kitterman, RFC 8301 – Cryptographic Algorithm and Key Usage Update to DKIM, IETF, gennaio 2018. www.rfc-editor.org
11. T. Herr, J. Levine (a cura di), RFC 9989 – Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF, maggio 2026 (sostituisce la RFC 7489). www.rfc-editor.org
12. OWASP, Web Security Testing Guide – Test for Subdomain Takeover (WSTG-CONF-10). owasp.org
13. OWASP, Subdomain Takeover Prevention Cheat Sheet, OWASP Cheat Sheet Series. cheatsheetseries.owasp.org
14. R. Arends et al., RFC 4033 – DNS Security Introduction and Requirements, IETF, marzo 2005. www.rfc-editor.org
15. P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews, RFC 8659 – DNS Certification Authority Authorization (CAA) Resource Record, IETF, novembre 2019. www.rfc-editor.org
16. J. Hodges, C. Jackson, A. Barth, RFC 6797 – HTTP Strict Transport Security (HSTS), IETF, novembre 2012. www.rfc-editor.org