Come ti vedono da fuori: 8 controlli di sicurezza sul tuo dominio

C’è una parte della sicurezza aziendale che non richiede licenze, progetti o budget: quello che il tuo dominio racconta di sé a chiunque passi. Header HTTP, certificati, record DNS, autenticazione email. Sono informazioni pubbliche per definizione — chiunque può leggerle, incluso chi sta valutando se attaccarti.

La cosa curiosa è che quasi nessuna PMI le ha mai guardate. E sono esattamente le prime che guardano tre categorie di persone: un auditor NIS2, un broker assicurativo che ti manda il questionario pre-polizza, e un attaccante che fa ricognizione.

Questa guida raccoglie otto controlli gratuiti e non intrusivi — nessun tool a pagamento, nessun test invasivo, niente che possa disturbare i tuoi sistemi. Sono comandi che leggono informazioni già pubbliche.

In sintesi

• Otto controlli, tutti gratuiti, eseguibili in mezz’ora su un PC Windows.
• Servono a rispondere a una domanda concreta: cosa vede di noi chi guarda da fuori?
• Nessuno di questi test è invasivo: leggono dati pubblici, non toccano i sistemi.
• Gran parte dei problemi che troverai si risolve con poche righe di configurazione, non con nuovi acquisti.
• Fallo prima che te lo chieda un auditor o un cliente.

Prima di iniziare: una regola sola

Fai questi controlli solo su domini di tua proprietà (o con autorizzazione scritta del titolare). Sono test passivi e leggono informazioni pubbliche, ma la regola vale a prescindere: verificare l’infrastruttura di terzi senza mandato non si fa.

I comandi che seguono funzionano in PowerShell su Windows, senza installare nulla.

1. Gli header di sicurezza HTTP

Quando un browser apre il tuo sito, il server risponde con degli header. Alcuni servono a dire al browser cosa non permettere: non farmi incorniciare in un altro sito, non indovinare il tipo dei file, non passare l’indirizzo completo ai siti esterni.

Se non ci sono, il sito funziona comunque — ma perdi una serie di protezioni gratuite.

Invoke-WebRequest -Uri "https://tuodominio.it/" -Method Head |
  Select-Object -ExpandProperty Headers

Cosa cercare — questi sei nomi:

Per un riscontro visivo esiste securityheaders.com: inserisci il dominio e ottieni un voto da A a F. Non spaventarti se prendi F — è il voto più comune, e dipende quasi sempre dalla semplice assenza degli header, non da una falla.

⚠️ Una cautela sulla Content-Security-Policy. È l’header più potente e anche il più facile da sbagliare: se pubblichi una policy troppo restrittiva puoi rompere form, banner cookie e analytics senza accorgertene. Va sempre attivata prima in modalità Content-Security-Policy-Report-Only, che segnala le violazioni senza bloccare nulla, e promossa solo dopo aver verificato che tutti i servizi di terze parti (widget anti-bot, CMP, tag manager) siano autorizzati.

2. HSTS: c’è, ma dove?

Questo è l’errore più elegante che si trova in giro. Strict-Transport-Security viene spesso inviato sulla risposta di redirect da HTTP a HTTPS — dove i browser, per specifica, lo ignorano. Serve invece sulla risposta HTTPS.

Risultato: sembra configurato, e non protegge.

# Deve rispondere con un valore, non vuoto
(Invoke-WebRequest -Uri "https://tuodominio.it/" -Method Head).Headers['Strict-Transport-Security']

Se non restituisce nulla, HSTS non è attivo dove conta. Il rischio è la finestra alla prima visita su una rete ostile (Wi-Fi pubblico), in cui un attaccante può intercettare la richiesta HTTP prima che scatti il redirect.

3. Il certificato e la configurazione TLS

Qui il riferimento è Qualys SSL Labs (ssllabs.com/ssltest): analizza il server dalla propria infrastruttura e restituisce un voto da A+ a F, dicendoti quali protocolli accetti e se sei esposto a vulnerabilità note.

Cosa guardare nel referto:

• Protocolli: devono esserci solo TLS 1.2 e 1.3. TLS 1.0/1.1 vanno spenti.
• Data di scadenza del certificato — e soprattutto: il rinnovo è automatico?
• OCSP stapling: se è No, si abilita con due righe e migliora privacy e velocità.

💡 Una nota pratica: se provi a testare il TLS dalla rete aziendale con strumenti locali e vedi un certificato che non è il tuo, non allarmarti. Molte reti aziendali hanno un proxy che ri-termina il TLS: stai vedendo il certificato del proxy. Per questo un test esterno è più affidabile di uno interno.

4. DMARC: stai osservando o stai proteggendo?

DMARC dice ai server destinatari cosa fare con la posta che finge di venire dal tuo dominio. Ha tre livelli:

• p=none → osservo e non faccio nulla
• p=quarantine → metti in spam
• p=reject → rifiuta

Resolve-DnsName -Name "_dmarc.tuodominio.it" -Type TXT -Server 8.8.8.8 |
  Select-Object -ExpandProperty Strings

Il caso peggiore non è p=none. È p=none senza rua=: significa che non solo non blocchi nulla, ma non ricevi nemmeno i rapporti — quindi non sai se qualcuno sta usando il tuo dominio per il phishing. Zero protezione e zero visibilità.

Il percorso corretto è graduale, e va in questo ordine:

1. Aggiungi subito rua= restando su p=none → cominci a vedere i dati
2. Dopo 2-4 settimane di rapporti puliti → p=quarantine
3. Solo quando sei sicuro che tutti i mittenti legittimi passino → p=reject

⚠️ Saltare i passaggi ha una conseguenza concreta: passare a p=reject prima di aver allineato tutti i mittenti (Microsoft 365, il gestionale che manda le fatture, la piattaforma di newsletter, il CRM) significa che le tue email legittime iniziano a essere rifiutate. Per la configurazione lato Microsoft 365 c’è la nostra guida passo-passo a SPF, DKIM e DMARC.

5. SPF: attenzione al finale

Guarda l’ultimo carattere del record SPF:

(Resolve-DnsName -Name "tuodominio.it" -Type TXT -Server 8.8.8.8).Strings |
  Where-Object { $_ -like "v=spf1*" }

• -all (hard fail) → chi non è in elenco viene rifiutato. È l’obiettivo.
• ~all (soft fail) → chi non è in elenco passa comunque, marcato come sospetto.

Molti domini restano su ~all per anni “per sicurezza”. È comprensibile — ma è anche una protezione dimezzata. Il passaggio a -all va fatto dopo aver censito tutti i mittenti legittimi, mai prima.

6. DKIM: c’è davvero o sembra che ci sia?

DKIM firma le tue email. Su Microsoft 365 si pubblica con due record CNAME chiamati selettori:

Resolve-DnsName -Name "selector1._domainkey.tuodominio.it" -Type TXT -Server 8.8.8.8
Resolve-DnsName -Name "selector2._domainkey.tuodominio.it" -Type TXT -Server 8.8.8.8

Come leggere il risultato:

• Restituisce un CNAME verso ...onmicrosoft.com oppure un record che inizia con v=DKIM1 → ✅ configurato
• Restituisce NXDOMAIN → ❌ non configurato
• Restituisce qualcos’altro (per esempio un CNAME verso il tuo sito web) → ⚠️ leggi il punto 7, hai un wildcard

Un dettaglio che quasi nessuno controlla: se il record DKIM esiste, guarda la lunghezza della chiave. Una chiave RSA da 1024 bit è considerata debole oggi; lo standard è 2048. Se nel record trovi n=1024, o se la parte p= è piuttosto corta, vale la pena ruotare la chiave a 2048 bit dal portale di sicurezza Microsoft. È un’operazione gratuita che spesso nessuno ha mai fatto dai tempi dell’attivazione.

7. Il wildcard DNS che nasconde i problemi

Questo è il controllo più sottovalutato, e il più rivelatore. Chiedi al DNS un sottodominio che certamente non esiste:

Resolve-DnsName -Name "questo-non-esiste-12345.tuodominio.it" -Server 8.8.8.8

Se ottieni una risposta invece di NXDOMAIN, hai un wildcard DNS (*.tuodominio.it) che fa risolvere qualsiasi nome verso il tuo sito.

Perché è un problema:

• Maschera i controlli: come nel punto 6, non distingui più “il record non esiste” da “il record c’è”. Un wildcard non impedisce a un record esplicito di funzionare — ma ti impedisce di accorgerti che manca.
• Aiuta il phishing: qualunque nome dall’aspetto credibile (fatture-tuodominio, accedi.tuodominio) risolve verso un sito reale e con certificato valido.
• Complica la governance: diventa difficile capire quali sottodomini esistono davvero.

I wildcard nascono quasi sempre per comodità, anni prima, per non dover creare i record uno a uno. Vanno sostituiti con i soli record espliciti effettivamente necessari.

8. Due dettagli finali: CAA e security.txt

Record CAA — dichiara quali Autorità di Certificazione possono emettere certificati per il tuo dominio. Senza, può farlo qualunque CA al mondo.

Resolve-DnsName -Name "tuodominio.it" -Type CAA -Server 8.8.8.8

Se non risponde nulla, non c’è. Si aggiunge con un record DNS, indicando la CA che usi già.

security.txt — un file di testo in /.well-known/security.txt che dice a un ricercatore a chi scrivere se trova una vulnerabilità nei tuoi sistemi (standard RFC 9116). Senza, chi trova un problema non sa a chi rivolgersi: o scrive all’indirizzo commerciale e finisce ignorato, o lascia perdere. Provalo aprendo https://tuodominio.it/.well-known/security.txt nel browser.

Bonus: quali sottodomini hai esposto?

Non è un test tecnico, ma è il controllo che riserva più sorprese. Ogni certificato emesso viene registrato in log pubblici (Certificate Transparency): su crt.sh inserisci il dominio e vedi l’elenco dei nomi per cui è stato emesso un certificato.

Il risultato tipico in una PMI è: due o tre sottodomini che nessuno ricordava. Un vecchio portale, un ambiente di test messo online “per una demo”, un servizio dismesso ma ancora raggiungibile. Sono superficie di attacco che non sapevi di avere — e gli ambienti di test sono notoriamente i meno protetti.

Come leggere i risultati (senza farsi prendere dal panico)

Se hai fatto tutti gli otto controlli, probabilmente hai trovato qualcosa. È normale: sono impostazioni che nessuno tocca dopo la messa online.

Due cose da tenere presenti:

La maggior parte si risolve con configurazione, non con acquisti. Header, HSTS, CAA, security.txt, DKIM: sono righe da aggiungere a un file di configurazione o record DNS da creare. Costo zero, mezza giornata di lavoro.

Le priorità non sono tutte uguali. Se devi scegliere da dove partire:

1. DMARC con reporting — è l’unico che riguarda l’abuso del tuo nome verso i tuoi clienti
2. HSTS sulle risposte HTTPS — protegge chi visita il sito
3. Header di sicurezza — cinque righe, effetto immediato
4. Wildcard DNS — richiede più attenzione perché va capito cosa dipende da lui
5. Il resto (CAA, security.txt, OCSP, chiave DKIM a 2048)

Perché farlo adesso

Tre motivi che hanno una data:

• NIS2: le misure di sicurezza di base vanno adottate entro il 31 ottobre 2026, e la gestione delle vulnerabilità è tra queste. Questi controlli producono evidenze documentabili. Vedi il mapping fra misure NIS2 ed evidenze Microsoft 365.
• Questionari assicurativi: i broker cyber chiedono sempre più spesso dettagli su autenticazione email e configurazione. Rispondere “non lo so” pesa sul premio.
• Richieste dei clienti: se lavori come fornitore di aziende soggette a NIS2, prima o poi ti arriva un questionario di sicurezza. Meglio avere le risposte pronte.

E un motivo senza data: il phishing a nome della tua azienda danneggia te, anche quando la vittima è un tuo cliente. DMARC in p=reject è la difesa più economica che esista contro questo scenario.

Domande frequenti

Questi test sono legali? Sì, sul tuo dominio: leggono informazioni pubbliche, non tentano accessi. Su domini di terzi serve un mandato scritto: cambia la natura dell’attività.

Ho preso F su securityheaders.com, è grave? Nella maggior parte dei casi no: quel voto misura la presenza degli header, non l’esistenza di una falla. Un sito con F può essere perfettamente sano — mancano protezioni aggiuntive, non c’è una porta aperta. Ed è la carenza più veloce da correggere.

Posso passare direttamente DMARC a p=reject? Tecnicamente sì, ma è il modo migliore per bloccarsi la posta da soli. Prima il reporting, poi la quarantena, poi il reject — verificando a ogni passo che i mittenti legittimi passino.

Il wildcard DNS va rimosso sempre? Non necessariamente, ma va conosciuto. Se serve a un’architettura specifica (per esempio sottodomini per cliente), si documenta e si convive. Se è lì per comodità da anni, meglio sostituirlo con record espliciti.

Ogni quanto rifare i controlli? Due volte l’anno, più una volta dopo ogni cambio infrastrutturale (nuovo hosting, nuovo provider email, nuovo dominio). I certificati scadono, i record si accumulano, i fornitori cambiano.

Come ti aiutiamo

Se preferisci non farlo da solo — o se hai trovato qualcosa e vuoi sistemarlo bene la prima volta — questa verifica fa parte di come lavoriamo nell’assistenza cybersecurity gestita: controllo della postura esterna, correzione delle configurazioni, percorso DMARC fino all’enforcement senza bloccare la posta, e monitoraggio nel tempo.

Se invece stai preparando la conformità NIS2, questi controlli sono un pezzo del quadro più ampio: vedi la checklist di hardening del tenant Microsoft 365.

Parla con un nostro consulente: partiamo da una verifica della tua postura esterna, senza impegno.

Nota: i comandi PowerShell in questa guida sono test passivi che leggono record DNS e header HTTP pubblici. Eseguili solo su domini di tua proprietà o con autorizzazione scritta. Articolo aggiornato a luglio 2026.