Monitoraggio DMARC gestito.
Dai report alla policy p=reject.

DMARC (Domain-based Message Authentication, Reporting and Conformance) è un record DNS con cui il proprietario di un dominio dice ai server riceventi cosa fare con i messaggi che non superano SPF o DKIM: nulla (p=none), quarantena (p=quarantine) o rifiuto (p=reject). La parte «Reporting» è quella che pochi usano: Google, Microsoft, Yahoo e gli altri destinatari inviano ogni giorno un report aggregato in XML con gli indirizzi IP che hanno spedito posta a nome del dominio e l’esito dell’autenticazione. Letti con costanza, quei report dicono chi sta davvero usando il tuo dominio. Il servizio li riceve, li legge ogni ora e li traduce in una diagnosi in italiano. Lavoriamo sui report aggregati (RUA): i report forensi (RUF), che pochi destinatari inviano, non sono trattati. La copertura dipende da chi manda i report: i grandi provider sì, molti server piccoli no, quindi i numeri non descrivono mai il cento per cento della posta.

Con p=none il dominio è solo osservato: i messaggi falsi vengono recapitati comunque e il record serve soltanto a ricevere i report. Solo p=reject, con p=quarantine come tappa intermedia, dice ai destinatari di scartare la posta che non supera l’autenticazione, ed è l’unica configurazione che impedisce davvero a terzi di spedire a nome del tuo dominio. Google, Yahoo e Microsoft richiedono già un record DMARC a chi spedisce grandi volumi verso le loro caselle. Una policy di enforcement è inoltre una misura tecnica documentabile in un audit NIS2 o ISO/IEC 27001.

L’inoltro è il caso più delicato. Quando un destinatario gira automaticamente la posta a un altro indirizzo, o una mailing list riscrive il messaggio, SPF fallisce perché il server che inoltra non è tra quelli autorizzati. Se anche la firma DKIM si rompe, con p=reject quel messaggio viene scartato. Per questo il servizio riconosce le sorgenti che si comportano da inoltro e le classifica come tali, e il passaggio a p=reject avviene solo quando le sorgenti legittime firmano correttamente con DKIM, che sopravvive all’inoltro. Il percorso è graduale proprio per non perdere posta legittima.

Dipende da quanti sistemi spediscono a nome del dominio. Un’azienda con la sola posta su Microsoft 365 arriva all’enforcement in tempi brevi; un’organizzazione con CRM, piattaforme per newsletter, gestionali e stampanti multifunzione che inviano email richiede più tempo, perché ogni sorgente va identificata, autorizzata in SPF o fatta firmare con DKIM. Il punteggio di prontezza, su una scala da 0 a 100, indica in ogni momento quanto manca e qual è il prossimo passo: la quarantena parte sul 10% della posta da 80 punti e arriva al 100% da 90, il rifiuto parte sul 25% da 95 e diventa totale da 97. Di norma il dominio resta alcune settimane in osservazione con p=none, passa a p=quarantine con percentuale crescente e infine a p=reject. Non forziamo i tempi: il dominio avanza quando i report dicono che è pronto.

No. Il servizio è gestito: AtWorkStudio configura i record, autorizza i mittenti, porta il dominio in enforcement e continua a monitorarlo. Il cliente riceve la scheda del dominio in italiano, in PDF, generata dal proprio referente AtWorkStudio quando serve, di norma a fine mese o dopo un intervento: contiene i numeri degli ultimi 30 giorni confrontati con i 30 precedenti, la configurazione DNS, il punto del percorso, cosa è stato fatto e chi invia posta per il dominio. Gli avvisi e il riepilogo settimanale sono strumenti interni degli operatori. La piattaforma operativa, DMARC Reaper, è riservata agli operatori AtWorkStudio. Report e cronologia sono conservati 13 mesi su Azure nella regione Italia Nord.