Come leggere i report DMARC: una guida completa a RUA e RUF

Hai pubblicato un record DMARC, hai impostato `rua=` sul tuo indirizzo e-mail e ora i rapporti ti arrivano nella posta in arrivo sotto forma di file XML compressi. Sono difficili da leggere, provengono da aziende di cui non hai mai sentito parlare e non è chiaro cosa dovresti fare, ammesso che ci sia qualcosa da fare.

Questa guida risolve il problema. Spiega cosa contengono i report DMARC, come leggere il codice XML campo per campo, cosa significano effettivamente RUA e RUF e, soprattutto, quali azioni intraprendere quando un mittente supera il controllo, non lo supera o compare in modo inaspettato. Se hai tra le mani il tuo primo report, inizia dall’inizio e procedi verso il basso.

Questo blog presuppone che tu disponga già di un record. Se così non fosse, pubblica innanzitutto un record DMARC, poi torna qui per interpretare i report che genera.

Cosa sono i report DMARC?

I rapporti DMARC sono riepiloghi giornalieri inviati dai server di posta riceventi all'indirizzo specificato nel tag `rua=`. Ciascuno di essi elenca tutti gli indirizzi IP che hanno inviato un'e-mail dichiarando di provenire dal tuo dominio durante un periodo di riferimento, indicando se SPF e DKIM abbiano superato o meno i controlli per ciascuna fonte. Rappresentano lo strumento principale per monitorare lo stato di autenticazione delle e-mail del proprio dominio. Sono l’unica vera fonte di visibilità su chi sta inviando e-mail a nome dell’utente, che si tratti di mittenti legittimi o meno.

Chi invia i rapporti DMARC?

Ogni server di posta che riceve e-mail dal tuo dominio invierà un rapporto se hai configurato l'opzione rua=. Ciò include ovviamente Google, Microsoft e Yahoo. Sono inclusi anche provider di servizi di posta elettronica (ESP) più piccoli, gateway di posta aziendali, sistemi universitari e provider internazionali che i tuoi destinatari potrebbero utilizzare. 

Ricevere segnalazioni da organizzazioni che non si riconoscono è normale e prevedibile. Può semplicemente significare che un server da qualche parte ha elaborato un messaggio che sembrava provenire dal proprio dominio. Tuttavia, si noti che un volume elevato di posta in tali segnalazioni proveniente da un IP che non si controlla giustifica comunque un'indagine, poiché si tratta di un segnale di spoofing.

Il numero di segnalazioni che ricevi ogni giorno dipende dal numero di server di posta distinti che hanno ricevuto la tua e-mail. Se invii messaggi solo a pochi destinatari, potresti ricevere due o tre segnalazioni al giorno. Chi invia grandi volumi di messaggi può riceverne centinaia. Nessuno di questi dati indica di per sé un problema. Il volume delle segnalazioni riflette la distribuzione dei tuoi destinatari, non lo stato di salute del tuo dominio.

Quando arrivano i rapporti?

La maggior parte dei fornitori invia un unico rapporto aggregato ogni 24 ore, e i rapporti arrivano in genere entro 24-48 ore dall’attività di posta elettronica a cui si riferiscono. Si riceve un rapporto separato da ciascuna organizzazione che fornisce i dati (Google e Microsoft inviano i propri rapporti in modo indipendente), quindi la posta inviata in un singolo giorno a destinatari diversi genera diversi rapporti che coprono lo stesso intervallo di tempo.

I rapporti vengono inviati come allegati compressi in formato .zip o .gz da mittenti automatizzati. Alcuni client di posta elettronica li contrassegnano come sospetti, quindi se stai aspettando dei rapporti e non ne vedi nessuno, controlla la cartella dello spam o della posta indesiderata prima di pensare che ci sia un problema.

Tipi di report DMARC: RUA e RUF

Esistono due tipi di report DMARC. Per quasi tutti i domini, dovrai preoccuparti solo del primo.

Report aggregati (RUA): lo standard

Rapporti aggregati DMARC rappresentano un riepilogo su 24 ore di tutto il traffico e-mail proveniente dal proprio dominio che un determinato server di posta ha elaborato. Vengono forniti in formato XML compresso e mostrano gli indirizzi IP di invio, i volumi dei messaggi, l’esito (superato/non superato) dei controlli SPF e DKIM e la disposizione DMARC (l’azione intrapresa dal destinatario). È fondamentale sottolineare che non contengono alcun contenuto delle e-mail né informazioni di identificazione personale, ma solo metadati di autenticazione, il che li rende sicuri da ricevere e archiviare in qualsiasi regione. È proprio su questo rapporto che si concentra la presente guida. 

Segnalazioni di errore (RUF): errori per singolo messaggio

Segnalazioni di errore DMARC (precedentemente denominati "rapporti forensi") sono notifiche quasi in tempo reale che indicano che un determinato messaggio non ha superato l'autenticazione. La RFC 9991 (maggio 2026) ha formalmente standardizzato questo tipo di rapporto. Poiché un rapporto di errore può includere le intestazioni del messaggio e talvolta il contenuto del corpo (dati che potrebbero contenere informazioni personali identificabili), i principali provider, tra cui Google, Microsoft e Yahoo, non li inviano affatto. Abilita ruf= solo se disponi di un processore dedicato per i dati e, in ogni caso, non aspettarti di ricevere rapporti dai grandi provider di posta elettronica. 

RUA contro RUF 

Cosa contiene un report DMARC: campo per campo

Un report aggregato DMARC è un file XML suddiviso in tre sezioni principali: metadati del report (chi lo ha inviato e quando), politica pubblicata (il tuo record DMARC così come è stato visto dal destinatario) e record, una riga per ogni fonte di invio. Comprendete questi tre blocchi e il resto sono solo dettagli.

Section 1: Report Metadata (<report_metadata>)

Questo riquadro indica chi ha inviato il rapporto e il periodo a cui si riferisce.

• org_name: l'organizzazione che effettua la segnalazione (ad es., google.com).
• e-mail: l'indirizzo di contatto del mittente del rapporto.
• report_id: un identificatore univoco per questo specifico report.
• date_range (inizio + fine): l'intervallo di riferimento, espresso come timestamp in formato epoch; sarà necessario convertirlo in una data leggibile dall'utente.

Cosa verificare in questa sezione: assicurati che il rapporto copra il periodo desiderato.

Section 2: Policy Published (<policy_published>)

Questo mostra il tuo record DMARC esattamente come è stato valutato dal destinatario al momento dell'elaborazione.

• dominio: il dominio a cui si applica la politica.
• adkim / aspf: modalità di allineamento DKIM e SPF (flessibile o rigorosa).
• p: la tua politica (nessuna, quarantena o rifiuto).
• sp: la tua politica sui sottodomini, se impostata.
• pct: un campo percentuale obsoleto. Si noti che pct è stato rimosso ai sensi della RFC 9989 (maggio 2026); è possibile che compaia ancora nei report più vecchi, ma nei nuovi record dovrebbe essere omesso.

Cosa verificare in questa sezione: assicurati che la politica pubblicata corrisponda a quanto previsto. In caso contrario, è possibile che la propagazione del tuo DNS non sia stata completata.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: l'indirizzo IP del mittente. Consultalo per identificare chi ha inviato l'e-mail.
• conteggio: quanti messaggi sono stati inviati da quell'IP.
• policy_evaluated/disposition: l'azione intrapresa (nessuna, quarantena o rifiuto).
• policy_evaluated/dkim e policy_evaluated/spf: il risultato (superato/non superato) allineato allo standard DMARC per ciascuno di essi.
• identificatori/header_from: il dominio visibile nel campo "Da:", ovvero quello che DMARC protegge.
• auth_results/spf: il dominio SPF e il risultato.
• auth_results/dkim: il dominio DKIM, il selettore e il risultato.

Cosa controllare in questa sezione: tutti gli indirizzi IP che riconosci superano il controllo DMARC? Ci sono indirizzi IP che non riconosci?

Esempio di report XML DMARC

Ecco un rapporto aggregato realistico e anonimizzato che mostra tre fonti di invio: un mittente legittimo che supera i controlli, un mittente legittimo che non li supera e un IP sconosciuto. Ogni campo è accompagnato da un commento in lingua semplice. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

Come leggere i rapporti DMARC: passo dopo passo

Passaggio 1: Aprire e decomprimere il report

I rapporti vengono inviati come allegati a un'e-mail con un oggetto del tipo "Segnalazione dominio: yourdomain.com - Mittente: google.com - ID segnalazione: …". Salva l'allegato, decomprimilo (gli strumenti di decompressione integrati nel tuo sistema operativo gestiscono senza problemi i file .zip e .gz) e apri il file .xml risultante con un qualsiasi editor di testo. 

Per qualsiasi analisi più approfondita, caricalo sul nostro strumento DMARC Report Analyzer anziché leggere il codice XML grezzo, per analizzare i dati in modo approfondito in un formato leggibile dall'utente.

Fase 2: Identificare l'organizzazione responsabile della rendicontazione

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Fase 3: Verifica la tua politica pubblicata

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Fase 4: Verifica di ogni record (origine dell'invio)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Fase 5: Classificare ciascuna fonte

Classifica ogni fonte in uno dei tre gruppi seguenti:

1. Legittimo e ammissibile: non è richiesta alcuna azione.
2. Legittimo ma inefficace: da correggere (vedi il quadro d'azione qui sotto).
3. Sconosciuto e in fase di invio: potenziale spoofing; monitorare il volume e valutare l'opportunità di rafforzare la propria politica qualora risultasse elevato.

Analisi dei report DMARC su larga scala: strumenti e automazione

Quando i report arrivano quotidianamente da più fornitori, la lettura manuale dei file XML diventa impraticabile. Un dominio che invia messaggi a utenti Gmail, Outlook e Yahoo riceve almeno tre report al giorno, ogni giorno, e leggerli uno per uno a mano non è fattibile oltre la prima settimana. L'analisi automatica dei dati è lo standard del settore per un motivo ben preciso.

Per un rapido controllo una tantum, strumenti gratuiti come il DMARC Report Analyzer di PowerDMARC consentono di caricare un file XML non elaborato e di visualizzarne il contenuto in un formato facilmente leggibile senza dover aprire un editor di testo.

Per un monitoraggio continuo su larga scala, una piattaforma dedicata gestisce tutto in modo automatico: normalizza i report provenienti da ogni fornitore in un’unica vista, avvisa l’utente quando compare un mittente sconosciuto, conserva la cronologia e genera esportazioni pronte per la revisione contabile. 

Per gli utenti di PowerDMARC, la nostra dashboard di reportistica gestisce tutto questo sia in ambienti a dominio singolo che a domini multipli, in modo che l'analisi avvenga in modo continuo e non solo quando ci si ricorda di controllare.

• Tutti i tuoi report in un unico posto: Invece di decine di file XML separati sparsi nella posta in arrivo, ogni report di ogni fornitore viene riunito in un'unica vista.
• Copertura su tutti i domini: Per i team che gestiscono più di un dominio, tale consolidamento si estende all'intero portafoglio, in modo che un'unica dashboard copra tutti i domini di cui siete responsabili.
• Dati storici, non solo istantanee: La cronologia archiviata consente di monitorare il tasso di successo settimana dopo settimana, verificare che la correzione apportata a un mittente non funzionante abbia effettivamente funzionato e individuare un lento aumento delle attività sospette prima che si trasformino in un incidente.
• Filtraggio e ricerca: Isolare una fonte di invio specifica o un tipo di errore specifico, invece di esaminare manualmente ogni singolo record.
• Avvisi sui nuovi mittenti: Ricevi una notifica quando compare un nuovo mittente non autorizzato, così non dovrai aspettare la prossima revisione manuale per individuarlo.
• Esportazione pronta per la revisione: Genera report esportabili per le verifiche di conformità e la rendicontazione alle parti interessate.

Cosa fare con i rapporti DMARC

Leggere il rapporto è il primo passo. È solo agendo concretamente che potrai proteggere il tuo dominio. Ogni volta che esamini una nuova serie di rapporti, segui i passaggi riportati di seguito nell’ordine indicato.

Correggere i mittenti legittimi che non vengono riconosciuti

Se un mittente che riconosci (il tuo ESP, CRM, helpdesk o piattaforma di newsletter) riporta dkim=fail o spf=fail:

1. In caso di errori SPF: aggiungi l'intervallo di indirizzi IP del mittente o includi il meccanismo "include:" nel tuo record SPF, quindi verifica nuovamente con il nostro SPF Checker.
2. In caso di errori DKIM: chiedi al provider di abilitare la firma DKIM personalizzata per il tuo dominio e pubblica la chiave che ti fornirà, quindi verifica con il nostro DKIM Checker.

Identificare e monitorare i mittenti sconosciuti

Un indirizzo IP che non riconosci e che invia email a nome del tuo dominio potrebbe essere uno strumento adottato da un team senza avvisare nessuno, un servizio di inoltro legittimo o un tentativo attivo di spoofing. Un volume ridotto proveniente da un IP sconosciuto è comune e presenta un rischio basso. Un volume elevato proveniente da un IP sconosciuto è un chiaro segnale di spoofing, ed è in questi casi che l'applicazione della tua politica di quarantena o di rifiuto blocca attivamente l'abuso.

Tieni traccia della tua percentuale di superamento nel tempo

Il tasso di superamento DMARC rappresenta la percentuale di messaggi che superano l'autenticazione DMARC. Con p=none non influisce sulla consegna, ma indica il grado di preparazione all'applicazione della politica. Prima di inasprire la politica, punta a raggiungere un tasso di superamento superiore al 95% per tutti i mittenti legittimi, che sia costante nel tempo. Monitoralo settimanalmente per almeno due-quattro settimane, anziché basarti sui dati di un singolo giorno.

Decidi quando estendere la tua polizza

Passare a p=quarantena quando tutte e tre le verifiche di prontezza risultano positive:

1. Tutti i mittenti legittimi conosciuti risultano conformi a DMARC.
2. Nei tuoi rapporti non compaiono mittenti con volumi elevati e inattesi.
3. Il tasso di superamento dell'esame si è mantenuto costantemente al di sopra del 95%.

Passare a p=reject quando le stesse condizioni permangono per una o due settimane in quarantena senza imprevisti. L'intero processo di applicazione della politica è descritto nella nostra guida alla configurazione di DMARC.

PowerDMARC automatizza l'intero processo di analisi. La nostra piattaforma monitora i tassi di accettazione, identifica i mittenti per nome anziché per indirizzo IP e ti avvisa non appena compare un nuovo mittente non autorizzato, così la decisione sulla idoneità viene presa al posto tuo, anziché doverla ricostruire a partire da dati XML grezzi.

Perché non ricevo i rapporti DMARC?

Se hai pubblicato un record con il campo rua= impostato ma non sono pervenute segnalazioni, la causa è quasi sempre da ricercarsi in una di queste sei ragioni.

Problema 1: Nel tuo record DMARC manca il tag "rua=". Questa è la causa più comune. Senza "rua=", hai esplicitamente rinunciato a ricevere i rapporti. Soluzione: aggiungi "rua=mailto:[email protected]" al tuo record e verifica con il nostro DMARC Checker.

Problema n. 2: Indirizzo e-mail errato o non valido. Un errore di digitazione, una casella di posta inesistente o una casella piena causeranno la mancata ricezione dei rapporti senza alcun avviso. Soluzione: verificare che l'indirizzo rua= sia effettivamente in grado di ricevere posta inviandogli un messaggio di prova.

Problema 3: Destinazione di segnalazione esterna non autorizzata. Se il tuo rua= punta a un indirizzo su un dominio diverso da quello del tuo record DMARC (il tuo dominio è company.com ma rua= punta a [email protected]), il dominio esterno deve pubblicare un record di autorizzazione su _report._dmarc.reportingservice.com contenente v=DMARC1. In assenza di tale record, le segnalazioni vengono scartate. La maggior parte delle piattaforme DMARC gestisce automaticamente questa operazione.

Problema n. 4: Hai pubblicato un nuovo record, ma il DNS non si è ancora propagato. I rapporti iniziano ad arrivare da 24 a 48 ore dopo che il tuo record è diventato attivo a livello globale, quindi, per risolvere questo problema, verifica la propagazione con il nostro Strumento di verifica della propagazione DNS.

Problema n. 5: Le segnalazioni finiscono nella cartella dello spam. Le segnalazioni vengono inviate come allegati compressi da mittenti automatici e spesso vengono filtrate. Per risolvere il problema, controlla la cartella dello spam e aggiungi i mittenti delle segnalazioni alla lista dei mittenti autorizzati ([email protected], [email protected]).

Numero 6: Non è stata ancora inviata alcuna e-mail. I rapporti vengono generati solo quando il tuo dominio ha effettivamente inviato messaggi che sono stati recapitati a un provider. Se non è stato inviato nulla da quando hai pubblicato il record, non c'è ancora nulla da segnalare.

RFC 9990: Lo standard per il rapporto aggregato del 2026

A partire da maggio 2026, la RFC 9990 regola il formato e l'invio dei report aggregati DMARC, assumendo il ruolo di definizione dei report che in precedenza era previsto dalla RFC 7489. Lo schema XML è retrocompatibile (i parser esistenti e i report già ricevuti continuano a funzionare) e la modifica principale consiste nella standardizzazione formale del formato di reporting e della cadenza giornaliera. 

Per un resoconto completo degli ultimi aggiornamenti, potete consultare il nostro guida DMARC RFC 9989/9990/9991 . 

Domande frequenti

Che cos’è un rapporto DMARC?

Un report DMARC è un file XML giornaliero inviato dai server di posta riceventi all'indirizzo specificato nel tag `rua=`, che riassume tutti gli indirizzi IP da cui sono state inviate e-mail dal proprio dominio e indica se i controlli SPF e DKIM hanno avuto esito positivo o negativo per ciascuno di essi. Provider come Google, Microsoft e Yahoo generano questi report ogni volta che ricevono messaggi di posta che dichiarano di provenire dal proprio dominio. Rappresentano lo strumento principale per monitorare lo stato di autenticazione delle e-mail del proprio dominio.

Qual è la differenza tra RUA e RUF in DMARC?

I report RUA (aggregati) sono riepiloghi giornalieri in formato XML che coprono tutte le attività di posta elettronica del proprio dominio. I report RUF (di errore) sono notifiche di errore relative a singoli messaggi che possono contenere i dati delle intestazioni delle singole e-mail. La maggior parte dei principali provider, tra cui Google, Microsoft e Yahoo, non invia più report di errore a causa di vincoli relativi alla privacy; pertanto, i report aggregati sono più diffusi e supportati a livello globale.

Con quale frequenza vengono inviati i rapporti DMARC?

La maggior parte dei provider invia un unico rapporto aggregato ogni 24 ore. Poiché ogni server di posta ricevente invia il proprio rapporto, ne riceverai uno da ciascun provider i cui utenti hanno ricevuto la tua posta; pertanto, un dominio che invia messaggi a utenti Gmail, Outlook e Yahoo dovrebbe aspettarsi almeno tre rapporti al giorno.

Come si legge un report XML DMARC?

Un report XML DMARC è composto da tre sezioni principali: report_metadata (chi lo ha inviato e il periodo di riferimento), policy_published (il proprio record DMARC così come è stato valutato) e records (una voce per ogni IP mittente con i relativi risultati SPF e DKIM). Per una guida pratica, è possibile consultare l’esempio XML riportato in precedenza in questa guida. Tuttavia, la maggior parte dei team IT utilizza uno strumento di analisi automatizzato che identifica i mittenti in base al nome, anziché leggere il codice XML grezzo.

Perché ricevo rapporti DMARC da organizzazioni che non riconosco?

Qualsiasi server di posta che riceva un’e-mail che dichiara di provenire dal tuo dominio invia una segnalazione se hai configurato l’opzione rua=. Ciò include piccoli ISP, gateway di posta aziendali e provider internazionali utilizzati dai tuoi destinatari, non solo Google e Microsoft. Ricevere segnalazioni da organizzazioni sconosciute è normale e significa semplicemente che quei server hanno gestito messaggi che sembravano provenire dal tuo dominio.

• Informazioni su
• Ultimi messaggi

Maitham Al Lawati

Esperto di sicurezza informatica, CEO di PowerDMARC

Maitham è un imprenditore tecnologico, esperto di sicurezza informatica, CEO e fondatore di PowerDMARC con oltre 15 anni di esperienza nel settore. Maitham ha conseguito un MBA presso l'Università di Manchester e varie certificazioni professionali, tra cui CISSP, CISM, CRISC e ISC2 CCSP.

Ultimi messaggi di Maitham Al Lawati (vedi tutti)

• Come configurare DMARC: guida completa alla configurazione passo dopo passo (2026) - 20 giugno 2026
• Come leggere i report DMARC: una guida completa a RUA e RUF - 10 giugno 2026
• Che cos’è il DMARC? Definizione, funzionamento e importanza - 28 aprile 2026