Contenuto informativo basato su fonti istituzionali. L’applicazione concreta richiede una valutazione del contesto, del rischio e della normativa vigente.
Costruire l'inventario prima della policy
Elencare i servizi che usano il dominio visibile è il passaggio più importante: caselle ordinarie, ticketing, gestionali, portali, newsletter, applicazioni, stampanti e fornitori possono avere percorsi distinti. Per ogni sorgente servono responsabile, dominio From, percorso SMTP, meccanismo di autenticazione e modalità di test.
Microsoft raccomanda di configurare SPF e DKIM per domini e sottodomini attivi prima di DMARC. Per piattaforme di invio non direttamente controllate è prudente usare un sottodominio dedicato, limitando l'impatto sulla reputazione e rendendo più chiara la responsabilità operativa.
- Dominio e sottodominio usati nel From
- Servizio, proprietario e fornitore
- Indirizzi IP o include SPF necessari
- Dominio e selettore DKIM
- Campioni di messaggi e risultato Authentication-Results
Usare i report aggregati come strumento di governo
La nuova specifica DMARC separa il protocollo dai formati di reporting: RFC 9990 disciplina i report aggregati. Questi dati descrivono le sorgenti osservate, il volume e gli esiti SPF, DKIM, allineamento e policy. Non sono una lista automatica di autorizzazioni: IP condivisi, forwarding e provider richiedono contesto.
I report vanno raccolti in un indirizzo o servizio controllato, conservati in modo proporzionato e analizzati con una frequenza definita. Ogni sorgente sconosciuta viene classificata: legittima da correggere, obsoleta da rimuovere, terza parte da governare o abuso da monitorare.
- Volume per sorgente e dominio
- Pass e fail di SPF e DKIM
- Allineamento con l'Author Domain
- Sorgenti nuove o inattese
- Trend dopo ogni modifica DNS o applicativa
Passare all'enforcement con criteri verificabili
Il monitoraggio permette di osservare senza chiedere il blocco dei messaggi falliti. Prima di quarantine o reject è necessario verificare che i flussi importanti abbiano almeno un meccanismo allineato e che help desk, fornitori e responsabili sappiano gestire le anomalie.
RFC 9989 ha rimosso il tag pct dalla specifica aggiornata: la progressione non va quindi progettata facendo affidamento su una percentuale pubblicata nel record. È più solido procedere per domini o sottodomini, correggere i flussi, osservare i risultati e modificare la policy con change management, rollback e verifica della consegna.
- Criterio di uscita dal monitoraggio
- Test su destinatari e provider differenti
- Finestra di modifica e piano di rollback
- Comunicazione a proprietari dei servizi
- Monitoraggio continuo dopo quarantine o reject
Domande frequenti
Che cosa contiene un report aggregato DMARC?+
Riepiloga per periodi e sorgenti gli esiti di autenticazione e policy osservati dai destinatari partecipanti. Aiuta a trovare flussi legittimi non allineati e tentativi di abuso.
Il tag pct è ancora il modo corretto per un rollout graduale?+
No. RFC 9989, pubblicata nel 2026, ha rimosso pct. Conviene avanzare per domini o sottodomini e per fasi operative verificate, senza basare il piano su quel tag.
Quarantine e reject vengono sempre applicati dai destinatari?+
DMARC esprime la preferenza del proprietario del dominio. Il ricevente la considera insieme ai propri controlli e non è obbligato ad applicarla in modo identico in ogni caso.