DMARC per il dominio aziendale: cosa controllare prima di rifare il sito

DMARC sembra un tema da reparto IT, ma entra spesso nei progetti web piu di quanto sembri. Quando rifai un sito, cambi fornitore, sposti hosting o riordini il dominio aziendale, tocchi quasi sempre anche DNS, form, invii transazionali, newsletter, caselle collegate e strumenti che mandano email a nome dell azienda.

Il punto non e trasformare il progetto sito in un servizio di cybersecurity. Il punto e evitare che dominio e posta restino fuori dalla checklist. Un sito puo essere ben fatto, veloce e chiaro, ma se le email inviate dal dominio non sono autenticate bene rischi problemi di recapito, confusione sugli invii legittimi e piu margine per impersonificazioni del dominio.

DMARC sta per Domain-based Message Authentication, Reporting and Conformance. In pratica permette al proprietario del dominio di dire ai server riceventi come trattare le email che non superano correttamente i controlli SPF e DKIM allineati al dominio visibile nel campo From. Nel 2026 il riferimento tecnico non e piu solo lo storico RFC 7489: IETF ha pubblicato RFC 9989 per il protocollo DMARC e RFC 9990/9991 per reporting aggregato e failure report.

La parte importante per una PMI non e memorizzare gli RFC. E capire il percorso: prima si controllano SPF e DKIM, poi si pubblica un record DMARC, spesso partendo da una policy di monitoraggio, poi si leggono i report, si correggono gli invii legittimi e solo dopo si valuta se irrigidire verso quarantine o reject. Saltare questa sequenza puo rompere invii buoni, non solo bloccare quelli cattivi.

Questo tema diventa concreto quando il sito usa form contatto, preventivi, prenotazioni, CRM, newsletter o automazioni. Se uno di questi strumenti invia email usando il dominio aziendale senza essere incluso bene in SPF, senza DKIM corretto o senza allineamento DMARC, il problema puo apparire come un bug del sito o del form. In realta e una configurazione del dominio rimasta incompleta.

C e poi il caso del cambio fornitore. Nel subentro di un sito si controllano spesso CMS, hosting, backup, repository e analytics, ma si dimentica la posta. E un errore pratico. Prima di cambiare DNS o mettere online una nuova versione, conviene sapere chi gestisce il dominio, quali record email sono presenti, quali servizi inviano per conto dell azienda e dove arrivano eventuali report DMARC.

La checklist minima e piu semplice di quanto sembri. Primo: identificare tutti gli strumenti che inviano email dal dominio, non solo le caselle personali. Secondo: verificare record SPF e DKIM. Terzo: controllare se esiste un record DMARC e con quale policy. Quarto: leggere se i report arrivano a una casella presidiata. Quinto: evitare cambi DNS improvvisati durante una migrazione del sito.

Un record DMARC con p=none non blocca di per se i messaggi che falliscono. Serve soprattutto a osservare cosa succede. Per questo e utile nella fase iniziale: permette di scoprire invii dimenticati, newsletter storiche, tool commerciali, plugin o servizi terzi che nessuno aveva messo in mappa. Passare subito a policy rigide senza questa lettura puo creare problemi operativi.

Gmail ha reso molto piu visibile il tema autenticazione: nelle linee guida attuali richiede SPF o DKIM per tutti i sender e, per i bulk sender, SPF, DKIM e DMARC. Anche se una piccola azienda non manda volumi enormi, il segnale e chiaro: dominio e email non sono un dettaglio separato dal sito quando il sito genera lead, preventivi o comunicazioni automatiche.

Per leggere bene il rischio, non basta chiedere se la posta funziona. Serve chiedere se il dominio e protetto abbastanza da distinguere invii legittimi, invii configurati male e tentativi di impersonificazione. DMARC non elimina phishing, truffe o Business Email Compromise da solo, ma riduce una parte del problema: l uso non autorizzato del dominio aziendale nelle email.

La parte commerciale e altrettanto importante. Se un form preventivo finisce in spam, se una conferma non arriva o se una newsletter usa un mittente poco credibile, il problema colpisce fiducia e conversione. Un progetto web serio non deve promettere sicurezza totale, ma deve almeno evitare che la parte email resti opaca mentre si sta lavorando su sito, tracking e acquisizione.

Questo vale anche quando il sito viene ereditato da un altro fornitore. Se non sai chi controlla DNS, chi puo modificare record, quali strumenti hanno accesso all invio e quali account ricevono i report, non sei ancora in una fase di supporto ordinario. Sei ancora in una fase di presa in carico. Pagare manutenzione o supporto evolutivo senza chiarire questo blocco rischia di lasciare aperta una zona grigia.

La domanda utile quindi non e se DMARC sia un extra tecnico da comprare a parte. La domanda utile e se, nel momento in cui tocchi dominio e sito, hai verificato abbastanza bene la base email da non creare problemi di recapito o ownership. Se la risposta e no, il passo corretto e inserirlo nella checklist di audit o subentro, non aspettare il primo problema di consegna.

Una proposta seria dovrebbe lasciare leggibili almeno tre confini. Primo: che cosa viene controllato nel DNS e negli invii del dominio. Secondo: che cosa resta fuori perche appartiene a gestione mailbox, sicurezza email avanzata o formazione interna. Terzo: quali cambi vanno fatti prima della messa online e quali richiedono monitoraggio progressivo dopo il rilascio.

Per Maticweb questo articolo resta nel perimetro corretto: non promette un presidio di sicurezza email completo e non inventa certificazioni. Serve a chiarire un punto operativo reale nei progetti web: quando dominio, DNS, sito e form cambiano, DMARC, SPF e DKIM vanno almeno letti e messi in ordine con il resto della presa in carico.

Se stai rifacendo il sito, cambiando fornitore o riportando sotto controllo un progetto ereditato, porta DMARC nella conversazione presto. Non come paura tecnica, ma come controllo pragmatico: chi manda email dal dominio, con quali record, con quale policy e con quale responsabilita operativa se qualcosa smette di arrivare.