Monitoraggio del dominio: la pratica che protegge la consegna delle tue email

Incollare un record DMARC nella zona DNS non chiude nulla: il record non serve a niente finché nessuno legge i report che genera ogni giorno. La surveillance di dominio indica questo lavoro di lettura continua, distribuito su 4 assi: i report DMARC, i record DNS (MX, SPF, DKIM), la data di scadenza del dominio e i domini simili registrati da terzi. Senza questo controllo, un team growth scopre il problema solo dopo, quando il CMO chiede perché il tasso di apertura è crollato. Un caso classico circola nei forum di email marketing: una sender reputation che crolla del 30% in tre mesi senza che nessun contenuto delle campagne sia cambiato, e la causa, quasi sempre, è un record DNS modificato senza che nessuno se ne sia accorto.

I 4 assi della surveillance di dominio

Un dominio mal monitorato perde il controllo su 4 fronti contemporaneamente, raramente uno solo. Il primo riguarda i report DMARC aggregati (RUA), che arrivano quotidianamente in una casella dedicata e che poche persone aprono. Il secondo copre i record DNS stessi: SPF, DKIM e il record DMARC possono essere modificati da un fornitore esterno o da uno script di migrazione, senza che parta alcun avviso. Il terzo asse riguarda la scadenza del dominio, argomento amministrativo che nessuno vuole gestire. Il quarto riguarda i domini che assomigliano al vostro per un solo carattere, registrati per ingannare i vostri clienti tramite usurpazione; il meccanismo di questa minaccia è trattato più avanti. La surveillance di dominio da sola non blocca alcun attacco. Fa scattare l’allarme presto, su tutti e 4 i fronti insieme.

Leggere i report DMARC invece di limitarsi a pubblicarli

Un record DMARC in p=none non rifiuta né mette in quarantena un solo messaggio. Fa scattare l’invio di report aggregati (RUA), in formato XML, in media una volta al giorno, da parte di ogni provider che riceve posta firmata dal vostro dominio: Gmail, Outlook, Yahoo, oltre ai server aziendali che applicano DMARC. I report forensi (RUF), invece, dettagliano un singolo messaggio fallito. Google non li invia più. Microsoft e Yahoo lo fanno ancora a intermittenza. Decodificare i campi di un report aggregato (IP sorgente, allineamento SPF/DKIM, disposizione applicata dal server ricevente) è un esercizio tecnico a sé stante, trattato in dettaglio nel nostro articolo come leggere un report DMARC aggregato senza sbagliare. Qui, il punto pratico sta in una frase: senza lettura regolare, la policy resta bloccata su p=none. È il caso della maggior parte dei domini protetti nel mondo, per mancanza di qualcuno che analizzi il flusso XML e faccia salire la policy verso p=quarantine e poi p=reject.

Rilevare una modifica DNS non autorizzata su MX, SPF, DKIM, DMARC

Strumenti come MXToolbox, CaptainDNS o DNS Assistant interrogano la zona DNS a intervalli regolari e confrontano ogni record con il suo valore precedente: se MX, SPF, DKIM o DMARC cambia, parte un avviso via email o Slack. L’avviso mostra la differenza tra il vecchio e il nuovo valore, il che evita di rifare una diagnosi completa a ogni incidente. Un record SPF che supera il limite di 10 query DNS fallisce senza bounce né avviso visibile lato mittente, uno scenario descritto in dettaglio nel nostro articolo sul limite SPF delle 10 ricerche DNS. Un record DKIM rimosso dopo una migrazione di hosting rompe allo stesso modo la firma di tutte le email in uscita; l’unico sintomo visibile è a volte un NDR (non-delivery report) che mostra l’Enhanced Status Code 5.7.1, senza un legame evidente con la modifica DNS avvenuta il giorno prima. Un cambio protocollare pianificato, come la rimozione del tag pct previsto da DMARCbis, produce lo stesso tipo di modifica apparentemente sospetta ma legittima: confrontare prima e dopo resta più affidabile che reagire alla cieca. Niente da consultare ogni mattina in uno stack già carico di avvisi: questi servizi girano in background e segnalano solo quando un valore cambia davvero. Un solo caso giustifica l’installazione. Il dominio cambia raramente configurazione DNS una volta stabilizzato. Quando cambia, è quasi sempre una modifica volontaria di qualcuno del team. Il monitoring serve a individuare quella che nessun ticket interno annuncia, la pista più frequente dietro un record dirottato senza compromissione dell’account registrar, uno scenario documentato da Infoblox ed Eclypsium sotto il nome Sitting Ducks.

Quasi 800.000 domini vulnerabili identificati e oltre 30.000 dirottamenti confermati dal 2019, senza che alcun account registrar sia stato compromesso (Infoblox ed Eclypsium, 2024).

Monitorare la scadenza e il rinnovo del dominio

Il ciclo che segue una scadenza prevede tre fasi: un periodo di grazia di circa 30 giorni in cui il rinnovo resta semplice, un periodo di redenzione di circa 30 giorni con penale da 80 a 200 euro, poi una finestra di cancellazione finale di 5-15 giorni prima della rimessa in vendita pubblica. Il 13% dei nomi a dominio aziendali scaduti viene riregistrato da terzi, secondo le ricerche interne di CSC pubblicate nel 2024. Questa percentuale sale per i domini storici lasciati nel punto cieco di un portafoglio di marchi mai controllato dopo una fusione o un cambio di fornitore. Un dominio perso a questo punto porta via il sito e gli indirizzi email aziendali. Cancella anche il posizionamento Google accumulato in diversi anni.

Individuare i domini simili e il typosquatting

Un dominio copiato con un carattere diverso (sostituzione di una l con una I maiuscola, aggiunta di un trattino, estensione .co invece di .com) basta per allestire una pagina di phishing credibile o un indirizzo di invio che inganna un cliente frettoloso. Oltre 30.000 domini lookalike che imitano marchi noti sono stati censiti tra febbraio e luglio 2024 da Zscaler ThreatLabz, di cui oltre 10.000 identificati come malevoli. Solo nel marzo 2025, oltre 26.000 domini che usurpano marchi o servizi pubblici sono stati rilevati da Palo Alto Networks Unit 42 durante campagne di smishing. Il meccanismo tecnico di questa usurpazione, il modo in cui un attaccante falsifica il mittente di un’email, è approfondito nel nostro articolo dedicato all’email spoofing. Il rilevamento anticipato, prima dell’invio della prima campagna fraudolenta, limita i danni. Un servizio di monitoraggio sulle varianti simili al nome del marchio depositato completa il quadro.

Frequenza di verifica consigliata per asse

Questo ritmo è adeguato per la maggior parte delle configurazioni osservate su domini già stabilizzati. Un dominio appena migrato verso un nuovo provider di emailing giustifica una lettura DMARC quotidiana nel primo mese, il tempo necessario perché l’allineamento SPF e DKIM si stabilizzi sulla nuova infrastruttura.

Ciò che la surveillance di dominio non copre

La causa di una deliverability in calo a volte punta altrove rispetto al dominio: quasi sempre verso la lista stessa, con un tasso di hard bounce in aumento e indirizzi catchall accumulati durante gli import. Un dominio può essere perfettamente monitorato (DMARC letto, DNS stabile, rinnovo anticipato, nessuna variante typosquattata rilevata) e vedere comunque crollare la propria deliverability. Anche il complaint rate sale, visibile tramite le feedback loop di diversi provider di posta. Questi segnali degradano la reputazione del mittente allo stesso modo di un record SPF rotto. Nessuno strumento di monitoring DNS li rileva, e l’equivalente Microsoft del Postmaster di Gmail (SNDS, Smart Network Data Services, meno consultato ma altrettanto rivelatore) non copre nemmeno la qualità degli indirizzi inviati. L’unico modo per sapere se la lista è degenerata insieme al DNS resta passarla al setaccio prima del prossimo invio, invece di scoprire il problema in una dashboard quando la reputazione è già compromessa.

Lo standard BIMI, che mostra il logo del mittente nella casella di posta, richiede un DMARC in p=reject stabile da diverse settimane per essere attivato dalla maggior parte dei provider. Pochi domini soddisfano ancora questa condizione nel 2026.