Rapporti di errore DMARC (RUF): cosa sono, come funzionano e come abilitarli in modo sicuro

Pubblicazione di un record DMARC è un passo importante per proteggere il proprio dominio da spoofing, phishing e uso non autorizzato della posta elettronica. Tuttavia, il vero valore operativo deriva dai report che indicano se i mittenti legittimi superano l'autenticazione delle email e dove si verificano gli errori.

Molti team aziendali si affidano ai report aggregati DMARC per monitorare lo stato generale del dominio, ma tali riepiloghi potrebbero non fornire dettagli sufficienti per la risposta agli incidenti, le indagini di conformità o la risoluzione di problemi complessi relativi a mittenti di terze parti. I report di errore DMARC (RUF) aggiungono un contesto a livello di messaggio che può aiutare i team di sicurezza e IT a identificare più rapidamente la causa degli errori di autenticazione. 

Questa guida spiega cosa sono i report RUF, in che modo si differenziano dai dati aggregati e come utilizzarli in modo efficace.

Che cos’è un rapporto di errore DMARC?

Un rapporto di errore DMARC (chiamato anche rapporto di errore o rapporto RUF) è una notifica dettagliata e quasi in tempo reale inviata dai server di posta elettronica destinatari quando un messaggio non supera l'autenticazione DMARC. Fornisce una diagnostica a livello di messaggio, inclusi i risultati dell'autenticazione, la fonte di invio e le intestazioni del messaggio, in modo che i proprietari dei domini possano indagare su potenziali tentativi di spoofing e risolvere i problemi relativi all'autenticazione delle e-mail.

Nota terminologica: I termini «rapporto di errore DMARC», «rapporto di errore DMARC» e «rapporto RUF» si riferiscono tutti allo stesso tipo di rapporto. Il formato di base è l’AFRF (Authentication Failure Reporting Format), definito nella RFC 6591, che costituisce un’estensione specifica per DMARC dell’ARF (Abuse Reporting Format, RFC 5965). Questi termini sono spesso utilizzati in modo intercambiabile nel settore.

• Chi li genera? I server di posta in ricezione, gli ISP, i gateway di posta aziendali e i dispositivi di sicurezza, ma solo se supportano RUF e rilevano un errore di autenticazione. I proprietari dei domini richiedono i rapporti tramite il tag ruf=, anche se sono i destinatari a decidere se inviarli in base alle proprie politiche sulla privacy e alla propria configurazione.
• Dove viene inviato? Viene inviato all'indirizzo e-mail specificato nel tag ruf= del tuo record DNS DMARC.
• Quale formato utilizza? A differenza dei report aggregati, che vengono forniti come file XML, i report RUF utilizzano l'AFRF (Authentication Failure Reporting Format) per fornire dati dettagliati sugli errori di autenticazione in un formato più facilmente leggibile.

Quali informazioni sono contenute nei rapporti di errore DMARC?

Poiché RUF i report DMARC sono pensati per un'analisi approfondita dei problemi, contengono metadati specifici sul messaggio non consegnato che non si trovano nei rapporti aggregati. Un tipico rapporto RUF include:

• Indirizzo IP del mittente: l'indirizzo IP esatto da cui è stato effettuato il tentativo di invio del messaggio
• Indirizzi "Da" e "Return-Path": l'intestazione "Da" e il mittente della busta
• Oggetto: l'oggetto effettivo dell'e-mail non recapitata
• Risultati dell'autenticazione: dettagli specifici sul motivo per cui SPF o DKIM non abbiano funzionato e se allineamento DMARC è stato raggiunto
• Intestazioni dell'e-mail: le intestazioni complete del feedback del messaggio
• Ora di ricezione: il timestamp relativo al momento in cui il messaggio è arrivato al server ricevente
• Politica DMARC applicata: la politica applicata al messaggio, che sia "nessuna", "quarantena" o "rifiuto"
• Risultato della consegna: se il messaggio è stato consegnato, messo in quarantena o rifiutato
• Informazioni di identificazione personale (PII): poiché questi rapporti possono includere oggetti e indirizzi dei destinatari, spesso contengono informazioni di identificazione personale

Nota sulla privacy

A causa della presenza di dati personali identificativi (PII), molti dei principali provider di caselle di posta elettronica hanno deciso di non inviare i rapporti RUF per tutelare la privacy degli utenti. PowerDMARC risolve questo problema supportando la crittografia PGP per i rapporti RUF, in modo che i dati sensibili rimangano crittografati e accessibili solo a te. Alcuni destinatari che inviano rapporti RUF oscurano prima le parti sensibili del corpo del messaggio o dell’oggetto; questo spiega perché alcuni rapporti di errore arrivano vuoti o contengono stringhe [REDACTED].

Esempio di rapporto di errore DMARC: come interpretare i singoli campi

Per capire cosa succede “dietro le quinte”, esamina i dati grezzi. Quando un’e-mail non viene recapitata, il destinatario genera un report in formato AFRF. Di seguito è riportato un che utilizza domini riservati e intervalli IP secondo la RFC 5737.

Interpretazione campo per campo

Consiglio pratico

Quando esamini un rapporto RUF, rispondi alle seguenti quattro domande in ordine. L'IP di origine è presente nell'elenco dei mittenti approvati? L'autenticazione SPF o DKIM ha dato esito negativo, o entrambe? Il campo "Original-Mail-From" corrisponde al tuo dominio? Sembra trattarsi di un caso di inoltro marginale o di un inoltro tramite mailing list? Se non sei in grado di rispondere con certezza a queste domande, inoltra il rapporto al tuo team di sicurezza affinché lo esamini.

Come appare il record nel tuo DNS

Per ricevere questi rapporti, il record DMARC deve includere il tag ruf=. Ecco un esempio rappresentativo:

Se invii i rapporti a un dominio diverso dal tuo, il dominio di destinazione deve pubblicare un record DNS che lo autorizzi a ricevere i rapporti per tuo conto. Analisi dei tag:

• v=DMARC1: il tag di versione standard che identifica il protocollo DMARC
• p=none: modalità di monitoraggio; i messaggi non vengono respinti né messi in quarantena e ai destinatari viene richiesto di segnalare i risultati dell'autenticazione
• rua=: destinazione dei report aggregati giornalieri che riassumono tutte le attività di autenticazione
• ruf=: destinazione per le segnalazioni di malfunzionamento; indirizzarle verso una piattaforma di elaborazione sicura e dedicata anziché verso una casella di posta generica
• fo=1: indica ai destinatari di generare un rapporto in caso di esito negativo della verifica SPF o DKIM

Rapporto aggregato DMARC e rapporto sugli errori: RUA e RUF

Entrambe le tipologie di report sono configurate all’interno dello stesso record DMARC, ma hanno finalità distinte. L’RUA offre una visibilità a livello di dominio nel corso del tempo; l’RUF fornisce dettagli a livello di messaggio per errori specifici. Per un’analisi più approfondita, consulta questo confronto tra rapporti RUA e RUF.

Come abilitare i rapporti di errore DMARC nel proprio record DNS

Per abilitare RUF è necessario aggiornare il record TXT DMARC esistente nel DNS. Segui questi passaggi.

1. Accedi al tuo provider DNS. Accedi alla console di gestione DNS del tuo dominio.
2. Individua il tuo record TXT DMARC. Trova il record TXT pubblicato su _dmarc.tuodominio.com.
3. Aggiungi la destinazione RUF. Inserire un indirizzo ruf=mailto: a cui devono essere inviati i rapporti di errore, ove supportato.
4. Configurare le opzioni in caso di errore. Aggiungere il tag fo= per definire quando devono essere generati i report, come illustrato nella sezione successiva.
5. Utilizza un sistema di elaborazione sicuro. Invia i report a una piattaforma sicura come PowerDMARC anziché a una casella di posta generica.
6. Salva e attendi la propagazione. La propagazione delle modifiche al DNS a livello globale può richiedere fino a 48 ore.

L'invio dei report RUF a una casella di posta standard genera confusione e aumenta il rischio di esposizione dei dati. Una piattaforma di reporting centralizza i dati DMARC, trasforma i dati grezzi di autenticazione in dashboard di facile lettura e mette in correlazione gli errori con i risultati di allineamento SPF, DKIM e DMARC, consentendo ai team di identificare più rapidamente i problemi.

Spiegazione di DMARC per i tag: quando vengono generati i rapporti di errore

Il tag "fo" è un componente del record DMARC che indica al server ricevente quando generare un rapporto di errore.

La maggior parte dei professionisti della sicurezza utilizza fo=1 perché garantisce la massima visibilità sugli errori di autenticazione. Detto questo, fo=1 dovrebbe essere indirizzato a una piattaforma di elaborazione dedicata e sicura piuttosto che alla casella di posta elettronica di un utente. Il volume di segnalazioni che genera può diventare ingestibile senza automazione, e l’invio a una casella di posta non protetta aumenta l’esposizione dei dati sensibili contenuti nei messaggi. A errore DKIM , in particolare, può generare un'ondata di segnalazioni che è opportuno isolare da una casella di posta condivisa.

Perché potresti non ricevere i rapporti di errore DMARC

Se hai abilitato RUF ma la destinazione dei report è vuota, ciò non indica necessariamente un errore di configurazione. Diversi fattori comuni possono impedire la ricezione dei report.

Ecco perché, secondo l’RUA i rapporti RUA sono considerati la fonte autorevole per il monitoraggio dello stato di salute complessivo del dominio, mentre i report RUF fungono da strumento investigativo supplementare per specifici scenari di guasto.

Questioni relative alla privacy e alla sicurezza

Poiché i rapporti RUF possono contenere oggetti, indirizzi dei destinatari, intestazioni e, talvolta, il contenuto dei messaggi, devono essere gestiti con attenzione nel rispetto delle normative sulla privacy quali GDPR e CCPA. Per le organizzazioni operanti in settori regolamentati quali quello finanziario, sanitario, dell’istruzione, della vendita al dettaglio e della pubblica amministrazione, i dati relativi ai malfunzionamenti devono essere trattati tramite sistemi sicuri e con accesso controllato che garantiscano il rispetto degli obblighi in materia di privacy e conformità.

Per le organizzazioni che devono soddisfare i requisiti di Google, Microsoft, PCI DSS, GDPR o quelli governativi in materia di autenticazione delle e-mail, è fondamentale disporre di flussi di lavoro sicuri per la generazione dei report. I dati RUF possono supportare le indagini, ma la visibilità aggregata su DMARC, i progressi nell’applicazione delle politiche e la gestione dei mittenti autenticati rimangono essenziali per garantire la conformità a lungo termine.

Migliori pratiche

• Utilizza una piattaforma dedicata e sicura per la segnalazione.
• Abilita la crittografia PGP: un modello "bring-your-own-key" (porta la tua chiave) implica che solo gli utenti autorizzati in possesso della chiave privata possano visualizzare i contenuti sensibili dei rapporti di errore.
• Limitare l'accesso ai dati relativi ai guasti in base al ruolo e alle esigenze operative.
• Definire le politiche di conservazione dei dati RUF archiviati in conformità con le normative vigenti in materia di privacy.
• Effettuare una verifica legale prima di abilitare la funzione RUF nelle giurisdizioni in cui vigono requisiti rigorosi in materia di protezione dei dati.

Come utilizzare i report RUF per individuare gli attacchi di spoofing e risolvere i problemi

Una volta che inizi a ricevere i dati relativi agli errori, considera ogni segnalazione come un indizio su cui indagare piuttosto che come un verdetto definitivo. Verifica i risultati confrontandoli con gli elenchi dei mittenti approvati, le tendenze aggregate DMARC, i log del gateway di posta e le informazioni sulle minacce prima di prendere decisioni correttive. Cinque scenari coprono la maggior parte dei casi emersi dai dati relativi agli errori.

Rilevamento dello spoofing dei domini

Se un rapporto di errore individua un indirizzo IP di origine non riconosciuto che utilizza il proprio dominio nell'indirizzo "From" dell'intestazione, considerarlo come un segnale da approfondire. Verificare innanzitutto l'origine confrontandola con gli elenchi dei mittenti approvati, le tendenze aggregate, i log dei gateway e le informazioni sulle minacce. Se confermato come non autorizzato, l'IP può essere aggiunto alle liste di blocco e il proprio centro operativo di sicurezza può essere informato.

Risoluzione di errori legittimi

A volte le e-mail legittime non vengono recapitate perché un mittente di terze parti non è configurato correttamente, un selettore DKIM è impostato in modo errato o il record SPF del dominio è diventato troppo complesso. Una piattaforma di monitoraggio aiuta i team a identificare questi errori nel loro contesto e a semplificare la gestione dell’SPF grazie all’SPF in hosting e all’appiattimento automatizzato, riducendo il rischio di problemi di consegna man mano che vengono aggiunti nuovi strumenti SaaS.

Diagnosi dei guasti relativi all'inoltro

L'inoltro delle e-mail spesso causa una violazione dell'SPF, poiché l'indirizzo IP del server di inoltro non è presente nel record SPF del mittente originale. Se un rapporto RUF segnala errori provenienti da un servizio di inoltro riconosciuto o da un relay di una mailing list, la causa è probabilmente una violazione dell'SPF piuttosto che un tentativo di spoofing. In questi casi, verifica se il DKIM risulta ancora valido, poiché le firme DKIM in genere non vengono alterate dall'inoltro, e se la politica DMARC può essere soddisfatta esclusivamente tramite l'allineamento DKIM.

Individuazione dell’IT sommerso e dei mittenti non autorizzati

I report RUF possono rivelare fonti di invio che i team IT non hanno autorizzato o di cui non sono a conoscenza, come ad esempio un team di marketing che ha integrato un nuovo strumento di automazione senza aggiornare il record SPF. Se un report di errore segnala un errore proveniente da un indirizzo IP appartenente a una piattaforma SaaS adottata di recente, si tratta di una lacuna di configurazione piuttosto che di un attacco. Aggiungi il servizio al tuo elenco di mittenti autorizzati e aggiorna di conseguenza il tuo record DMARC.

Flusso di lavoro delle indagini

1. Identificare l'indirizzo IP di origine nel rapporto RUF.
2. Verifica l'autorizzazione: questo indirizzo IP è associato a uno strumento o a un servizio utilizzato dalla tua organizzazione?
3. Verificare l'allineamento: controllare i risultati SPF e DKIM nel campo "Authentication-Results".
4. Verificare se si tratta di un caso di inoltro o di una mailing list: valutare se l'errore SPF è dovuto a un relay intermedio.
5. Classificare il rischio: mittente autorizzato con configurazione errata, mittente non autorizzato, messaggio inoltrato o fonte di “shadow IT”.
6. Rimedio: se l'autorizzazione è presente ma non viene rispettata, correggere l'allineamento SPF o DKIM. Se l'autorizzazione non è presente, utilizzare la politica DMARC con p=quarantine o p=reject per garantire la protezione.
7. Monitoraggio tramite report aggregati: verificare l'efficacia delle misure correttive esaminando i report RUA successivi.

Quando vale la pena attivare RUF e quando è meglio evitarlo

RUF non è un'impostazione predefinita per tutti i domini. La sua utilità dipende da chi leggerà i report e dallo scopo per cui sono stati creati. Ci sono tre situazioni in cui è utile e due in cui non lo è.

• Attivalo quando disponi di un team di sicurezza in grado di intervenire sulla base dei dati. Gli analisti del SOC e gli addetti alla gestione degli incidenti utilizzano i dettagli a livello di messaggio per indagare sui casi confermati di spoofing: questa è l'applicazione più efficace del report.
• Attivarlo durante la risoluzione attiva dei problemi. Quando un mittente di terze parti continua a generare errori e i dati aggregati non sono sufficientemente specifici, i dettagli sull'errore relativi all'IP esatto e al risultato dell'allineamento consentono di accelerare la diagnosi.
• Attivatela in contesti regolamentati in cui siano già in atto procedure di elaborazione sicure. Se si utilizzano già report crittografati e con controllo degli accessi, la maggiore profondità investigativa comporta un rischio marginale minimo.
• Valutate nuovamente la questione se i report dovessero essere inviati a una casella di posta condivisa. Senza crittografia e controlli di accesso, la ricezione di rapporti contenenti dati personali comporta un rischio di non conformità che supera i benefici.
• Rivalutate la questione se nessuno è responsabile dei risultati. Un volume elevato di fo=1 senza un analista che ne valuti l'importanza diventa rumore, e i report aggregati coprono già il monitoraggio dello stato di salute del dominio.

L'impostazione predefinita più comune per la maggior parte dei team è quella di dare priorità all'analisi aggregata. Si esegue RUA per valutare lo stato di salute del dominio e i progressi nell'applicazione delle politiche, quindi si attiva RUF in modo mirato quando un'indagine o un errore persistente da parte di un mittente richiede un'analisi approfondita a livello di messaggio, indirizzata a una piattaforma progettata per gestire i dati sensibili.

Limiti dei rapporti di errore DMARC

Comprendere cosa non possono fare i report RUF è importante tanto quanto sapere cosa possono fare. È opportuno considerare i report sugli errori come uno strumento investigativo supplementare, piuttosto che come l’indicatore principale su cui basare le decisioni relative al programma DMARC.

• Supporto limitato da parte dei provider: i principali provider di posta elettronica, tra cui Gmail e Microsoft 365, generalmente non inviano segnalazioni RUF per motivi di privacy, pertanto la copertura dei casi di errore è intrinsecamente incompleta
• Dati oscurati: i destinatari che inviano segnalazioni possono oscurare l'oggetto, il corpo del messaggio o gli indirizzi dei destinatari prima della consegna
• Falsi positivi dovuti all'inoltro: i relay delle mailing list e i servizi di inoltro causano spesso errori SPF che sembrano errori di autenticazione, ma non sono tentativi di spoofing
• Volume dei rapporti e rumore: con fo=1, i mittenti ad alto volume potrebbero ricevere un numero ingestibile di segnalazioni, molte delle quali riflettono il comportamento di inoltro previsto piuttosto che minacce reali
• Non sostituisce la RUA: i report aggregati rimangono la fonte autorevole per lo stato di integrità dell'autenticazione a livello di dominio, pertanto il RUF dovrebbe integrare, anziché sostituire, il monitoraggio continuo dell'RUA
• Rischio di esposizione dei dati personali (PII): in assenza di crittografia e controlli di accesso, il semplice fatto di ricevere rapporti RUF può di per sé comportare obblighi di conformità ai sensi del GDPR, del CCPA e di normative simili

Come gli MSP possono utilizzare i rapporti sugli errori DMARC relativi ai domini dei clienti

Per gli MSP e gli MSSP, i rapporti sugli errori sono preziosi quando un cliente segnala messaggi mancanti, casi sospetti di spoofing o errori di autenticazione inspiegabili. Tuttavia, i rapporti RUF grezzi sono difficili da gestire su larga scala. Possono contenere dati sensibili dei clienti, provenire da più domini contemporaneamente e richiedere una correlazione con altri segnali di autenticazione per poter essere utilizzati.

• Visibilità su più domini: l'aggregazione dei report relativi a decine o centinaia di domini dei clienti senza una piattaforma centralizzata richiede un notevole impegno manuale
• Gestione dei dati sensibili: I report RUF provenienti dai domini dei clienti possono contenere informazioni personali identificative (PII) dei clienti finali, il che comporta obblighi di conformità per l'MSP
• Gestione del volume dei rapporti: i domini dei clienti con volumi elevati possono generare un gran numero di segnalazioni di errore che sovraccaricano i flussi di lavoro dei tecnici
• Accesso basato sui ruoli: i tecnici dovrebbero poter visualizzare solo i report relativi ai domini dei clienti loro assegnati

Una piattaforma centralizzata come PowerDMARC per MSP e MSSP aiuta i fornitori di servizi a elaborare i dati RUF in modo sicuro, a separare i domini dei clienti, a ridurre i tempi delle indagini manuali e a fornire ai tecnici una rapida visibilità su quale mittente, indirizzo IP o meccanismo di autenticazione abbia causato un errore, senza esporre inutilmente dati sensibili.

In che modo PowerDMARC aiuta a gestire i rapporti di errore DMARC

PowerDMARC elabora in modo sicuro i dati relativi agli errori DMARC e trasforma i dati grezzi relativi agli errori di autenticazione in informazioni utili. Anziché inviare rapporti RUF contenenti dati sensibili a una casella di posta standard, i team visualizzano i rapporti in una dashboard centralizzata, proteggono i dati sensibili con la crittografia PGP e mettono in correlazione gli errori con i risultati di allineamento SPF, DKIM e DMARC.

• Visibilità chiara: identifica più rapidamente le fonti di invio non riuscite, i risultati dell'autenticazione e gli IP sospetti su tutti i tuoi domini
• Gestione sicura: la crittografia PGP con un modello "bring-your-own-key" riduce l'esposizione dei dati sensibili relativi ai guasti, in modo che nemmeno PowerDMARC possa leggere i contenuti crittografati
• Gestione centralizzata: monitora DMARC, SPF, DKIM, BIMI, MTA-STS e TLS-RPT da un'unica piattaforma senza dover cambiare strumento o analizzare file XML non elaborati
• Risoluzione più rapida dei problemi: risolvi i problemi legati agli errori dei mittenti legittimi e ai tentativi di spoofing senza dover analizzare manualmente i rapporti AFRF, grazie all’SPF in hosting e all’appiattimento automatizzato, per ridurre gli errori di consegna man mano che vengono aggiunti nuovi strumenti SaaS
• Preparazione alla conformità: registri di audit, controlli di accesso basati sui ruoli e supporto per Google, Microsoft, PCI DSS, GDPR e i requisiti governativi relativi ai mittenti

Domande frequenti

Che cos’è esattamente un rapporto di errore DMARC?

Un rapporto sugli errori in tempo quasi reale generato quando una singola e-mail non supera i controlli di autenticazione definiti dalla politica DMARC e dalle opzioni di gestione degli errori. Contiene dettagli a livello di singolo messaggio, a differenza dei rapporti aggregati, che riassumono l'attività relativa a tutti i messaggi nell'arco di 24 ore.

In che cosa si differenzia il RUF dal RUA?

RUA fornisce un riepilogo giornaliero a livello di dominio in formato XML che copre tutti i messaggi. RUF opera in tempo quasi reale per i singoli messaggi non riusciti in formato AFRF (RFC 6591, che estende l'ARF definito nella RFC 5965), contiene dettagli specifici relativi al messaggio e può includere informazioni di identificazione personale (PII). RUA invece no.

Come faccio ad attivare questi report?

Aggiungi ruf=mailto:[email protected] al tuo record TXT DMARC su _dmarc.yourdomain.com. Includi fo=1 per ricevere un rapporto in caso di errore di SPF o DKIM. Indirizza i rapporti verso una piattaforma sicura anziché verso una casella di posta standard.

Ho configurato RUF ma non mi appare nulla. È guasto?

Non necessariamente. Molti provider non inviano i RUF per motivi di privacy e non viene generato alcun report quando i messaggi vengono trasmessi. Se vengono ricevuti report RUA aggregati, è probabile che i dati siano corretti. Consultare la tabella di risoluzione dei problemi per individuare altre possibili cause.

Tutti i provider di caselle di posta elettronica inviano rapporti di errore DMARC?

No. Gmail e Microsoft 365 generalmente non lo fanno, adducendo motivi di privacy degli utenti. La copertura è limitata ai destinatari che hanno implementato il supporto RUF, in genere alcuni gateway di posta aziendali, ISP e server di posta indipendenti. Si tratta di una limitazione fondamentale.

È sicuro ricevere i rapporti di errore DMARC?

Possono contenere informazioni personali identificabili (PII), quali oggetti delle e-mail, indirizzi dei destinatari e intestazioni. La loro ricezione senza adeguati controlli può comportare obblighi ai sensi del GDPR e del CCPA. La soluzione più sicura consiste nell’inoltrarle a una piattaforma protetta dotata di crittografia PGP, accesso basato sui ruoli e periodi di conservazione definiti.

A cosa serve il tag "fo"?

È l'acronimo di "Failure Options" (Opzioni di errore) e definisce quando i destinatari generano un rapporto. Il valore fo=0 (impostazione predefinita) richiede che sia SPF che DKIM risultino non validi. Il valore fo=1 invia un rapporto in caso di errore di uno dei due. Il valore fo=d si attiva solo in caso di errore DKIM; il valore fo=s solo in caso di errore SPF.

• Informazioni su
• Ultimi messaggi

Milena Baghdasaryan

Specialista dei contenuti presso PowerDMARC

Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.

Ultimi messaggi di Milena Baghdasaryan (vedi tutti)

• "Rispondi" vs "Rispondi a tutti": galateo e rischi per la sicurezza - 14 agosto 2026
• Rapporti di errore DMARC (RUF): cosa sono, come funzionano e come abilitarli in modo sicuro - 11 agosto 2026
• L'autenticazione delle e-mail nelle più grandi aziende di intelligenza artificiale del mondo - 10 agosto 2026