Dominio, email e aggiornamenti: cosa serve a un sito dopo la pubblicazione.

01 / Il punto di partenza

Un sito non finisce il giorno in cui va online

Quando un sito viene pubblicato, sembra un lavoro concluso. In realtà resta collegato a servizi che hanno scadenze e regole proprie: il registro dei domini, il fornitore della posta, la piattaforma che ospita il sito, le librerie con cui è costruito.

Nella maggior parte dei casi i problemi non arrivano da un attacco, ma da cose ordinarie: un rinnovo non pagato, un record DNS cancellato durante un trasloco, un aggiornamento rimandato per anni. Sapere come funzionano basta per evitarli o per accorgersene in tempo.

02 / Il nome della tua attività online

Il dominio: di chi è e quando scade

Il dominio è l’indirizzo del sito, per esempio nomeattivita.it. Non si compra per sempre: si registra per un periodo e si rinnova, di solito ogni anno, tramite un fornitore chiamato registrar (Aruba, Register.it e molti altri).

Deve essere intestato a te

Chi compare come intestatario è il titolare del dominio. Se a registrarlo a proprio nome è stata l’agenzia o il consulente, il giorno in cui vuoi cambiare fornitore potresti non avere il controllo del tuo indirizzo. Verifica che l’intestatario sia la tua attività e che tu abbia accesso al pannello del registrar, o almeno sappia chi ce l’ha.

Cosa succede se scade

Con il dominio scaduto smettono di funzionare sia il sito sia le email. Per i domini .it, le linee guida tecniche del Registro .it prevedono che un dominio cancellato dal registrar resti per 30 giorni in un periodo di recupero, durante il quale solo quel registrar può recuperarlo. Poi viene eliminato e chiunque può registrarlo, compreso un concorrente o chi rivende domini.

• Attiva il rinnovo automatico e controlla che il metodo di pagamento non sia scaduto.
• Usa un’email di contatto che leggi davvero: gli avvisi di scadenza arrivano lì. Meglio non usare un indirizzo dello stesso dominio, che smetterebbe di funzionare proprio alla scadenza.
• Segna la data di scadenza in un calendario condiviso, anche se il rinnovo è automatico.

03 / La rubrica del dominio

DNS: l’elenco che dice dove va ogni servizio

Il dominio da solo non contiene né il sito né la posta. Ha un elenco di indicazioni, i record DNS, che dicono a ogni servizio dove andare. I più comuni sono questi:

• A e CNAME: dove si trova il sito.
• MX: a quale server consegnare le email in arrivo.
• TXT: verifiche e regole, per esempio SPF, DKIM e DMARC, che dicono chi è autorizzato a inviare email a nome del tuo dominio.

Questo elenco viene gestito da un solo fornitore alla volta, indicato dai nameserver del dominio. Se i nameserver sono di Aruba, conta solo l’elenco nel pannello Aruba. Se diventano quelli di un altro servizio, conta solo l’elenco di quel servizio, anche se nel pannello Aruba i vecchi record sono ancora visibili.

04 / Il caso più frequente

Sito su Vercel, dominio su Aruba: perché le email smettono di arrivare

Una situazione tipica: dominio e posta sono su Aruba, il nuovo sito viene pubblicato su una piattaforma come Vercel. Per collegare il dominio al sito ci sono due strade, e una delle due, se fatta di fretta, interrompe le email.

Strada 1: cambiare solo i record del sito

I nameserver restano quelli di Aruba. Nel pannello Aruba si modificano solo i record del sito, usando i valori che Vercel mostra nelle impostazioni del progetto. Tutto il resto, compresa la posta, non cambia:

; Il sito su Vercel: si cambiano solo questi due record
example.com.        A       <indirizzo indicato da Vercel>
www.example.com.    CNAME   <valore indicato da Vercel>

; La posta resta dal fornitore attuale: questi non si toccano
example.com.        MX      <server di posta del fornitore>
example.com.        TXT     "v=spf1 <regole del fornitore> ~all"

È la strada più semplice quando la posta è già configurata e funziona. La documentazione di Vercel lo dice esplicitamente: cambiare solo i record A o CNAME del sito non richiede di spostare gli altri record.

Strada 2: spostare i nameserver su Vercel

Si indicano al registrar i nameserver di Vercel, che da quel momento gestisce l’intero elenco DNS. Può essere comodo, ma Vercel risponde solo con i record che contiene. Se i record MX e TXT della posta Aruba non sono stati ricreati lì, le email in arrivo non trovano più il server: il sito funziona, la posta no. Anche gli invii possono finire nello spam, se mancano le regole SPF e DKIM.

Vercel avverte di copiare tutti i record esistenti prima di cambiare i nameserver, compresi quelli per la posta, e ha una guida dedicata a perché le email smettono di arrivare dopo il cambio. Lo stesso vale per qualsiasi altro servizio a cui si affidano i nameserver.

Come fare il cambio senza perdere email

1. Prima di toccare qualcosa, esporta o fotografa l’elenco completo dei record nel pannello attuale.
2. Se sposti i nameserver, ricrea prima sul nuovo servizio tutti i record MX e TXT, più quelli per webmail o configurazione automatica, se presenti.
3. Fai il cambio in un momento tranquillo: le modifiche DNS possono impiegare alcune ore per propagarsi.
4. Verifica subito: invia un’email da un indirizzo esterno, per esempio Gmail, e rispondi. Chi ha un terminale può controllare i record con dig.

dig NS example.com +short    # chi risponde per il dominio
dig MX example.com +short    # dove viene consegnata la posta
dig A  example.com +short    # dove punta il sito

Se le email hanno già smesso di arrivare, la soluzione è la stessa: ricreare i record della posta dove oggi si gestisce il DNS, oppure tornare ai nameserver precedenti. Le email inviate nel frattempo di solito vengono ritentate dai server per un periodo limitato; quelle respinte vanno fatte rimandare.

05 / Il codice che non hai scritto

Gli aggiornamenti delle dipendenze

Un sito moderno usa decine o centinaia di librerie scritte da altri: il framework, i componenti dell’interfaccia, gli strumenti per immagini e moduli. Sono le dipendenze. Lo stesso vale per i siti WordPress con temi e plugin. Rimandare gli aggiornamenti per anni crea tre problemi.

1. Vulnerabilità note

Quando viene scoperta una falla, la correzione arriva come aggiornamento, e la falla diventa pubblica. A dicembre 2025, per esempio, il team di React ha segnalato una vulnerabilità critica nei React Server Components che permetteva di eseguire codice sul server senza autenticazione; Next.js ha pubblicato le versioni corrette per le applicazioni coinvolte. Chi ha aggiornato subito era protetto, chi non lo ha fatto è rimasto esposto.

2. Piattaforme che smettono di supportare le vecchie versioni

Anche l’ambiente in cui gira il sito ha una scadenza. Node.js 20 non riceve più aggiornamenti secondo il calendario ufficiale di Node.js, e Vercel ha annunciato che non lo supporta più dal 1° ottobre 2026. Un progetto fermo a quella versione va aggiornato prima di poter essere pubblicato di nuovo.

3. Aggiornamenti sempre più difficili

Aggiornare una versione alla volta è di solito un lavoro breve. Recuperare tre anni di ritardo può richiedere di riscrivere parti del sito, perché nel frattempo sono cambiate le regole delle librerie.

06 / Un metodo

Come aggiornare senza rompere il sito

Aggiornare non significa installare tutto l’ultimo disponibile e sperare. Un metodo semplice:

• Sapere cosa c’è da aggiornare. Nei progetti JavaScript, npm audit segnala le vulnerabilità note; servizi come Dependabot propongono gli aggiornamenti in automatico.
• Distinguere i tipi di aggiornamento. Con il versionamento semantico, una correzione (1.4.2 → 1.4.3) di solito non cambia nulla; una versione maggiore (1.x → 2.0) può richiedere modifiche al codice.
• Provare prima di pubblicare. Gli aggiornamenti si fanno su una copia, si eseguono i test automatici e si controlla un’anteprima del sito prima di portarli online.
• Poter tornare indietro. Con le versioni fissate nel file di lock e una pubblicazione precedente pronta, un problema si annulla in pochi minuti.
• Avere un ritmo. Un controllo ordinario ogni mese, e un intervento immediato quando esce una correzione di sicurezza critica.

npm outdated    # quali pacchetti hanno versioni più recenti
npm audit       # quali hanno vulnerabilità note

Un ultimo accorgimento: aggiungi nuove librerie solo quando servono davvero e preferisci quelle mantenute attivamente. Ogni dipendenza in meno è una cosa in meno da tenere aggiornata.

07 / Da tenere a portata di mano

Le domande da fare a chi gestisce il tuo sito

1. Il dominio è intestato alla mia attività? E chi ha accesso al pannello del registrar?
2. Quando scade e come viene rinnovato? Con quale email arrivano gli avvisi?
3. Dove sono gestiti i DNS? Esiste una copia dei record attuali?
4. Chi gestisce la posta? Se si sposta il sito, chi verifica che le email continuino ad arrivare?
5. Ogni quanto vengono aggiornate le dipendenze? Come vengono provate prima di andare online?
6. Se un aggiornamento crea un problema, quanto tempo serve per tornare alla versione precedente?

Se a queste domande nessuno sa rispondere, il sito funziona finché non succede qualcosa. Bastano un’ora per mettere in ordine queste informazioni e un controllo periodico per mantenerle. Se il sito della tua attività deve ancora nascere, puoi partire dall’anteprima gratuita e definire fin dall’inizio chi si occupa di cosa.