La guida completa di Red Sift alla sicurezza e-mail
Quali sono gli obblighi e le raccomandazioni globali per DMARC nel 2026?
Per i team dei settori cybersecurity, sicurezza e-mail e IT, comprendere e rispettare i requisiti globali DMARC (Domain-based Message Authentication, Reporting, and Conformance) è essenziale.
Da Red Sift abbiamo realizzato una panoramica tabellare delle normative e delle raccomandazioni DMARC vigenti in varie aree del mondo. Il nostro obiettivo è fornire una guida chiara ed esplicita che riassuma i requisiti globali in un formato accessibile a tutti.
Che tu sia un professionista IT della sicurezza, un amministratore e-mail o un responsabile compliance, questa tabella è uno strumento fondamentale per assicurarsi che la protezione e-mail della tua organizzazione sia conforme alle best practice e agli standard internazionali.
Obblighi e raccomandazioni DMARC in tutto il mondo
Area interessata | Nome | Descrizione | Tipo di obbligo | Ulteriori informazioni |
Globale | Nuovi requisiti per chi invia grandi volumi | Le organizzazioni che inviano più di 5.000 e-mail al giorno devono autenticare i domini mittenti tramite TLS, DKIM, SPF, DKIM o SPF Alignment e impostare una policy DMARC di p=none. | Obbligo per il settore privato | |
Globale | PCI DDS v4.0 Requisito 5.4.1 | Devono essere impiegati "meccanismi automatizzati" per rilevare e bloccare i tentativi di phishing. La norma richiede "processi e meccanismi" ma non indica una soluzione specifica; le best practice suggeriscono DMARC, SPF e DKIM. | Obbligo di compliance | |
Canada | Requisiti di configurazione per i servizi di gestione e-mail | È necessario garantire che il mittente o il destinatario delle e-mail governative sia verificabile tramite Sender Policy Framework, Domain Keys Identified Mail (DKIM) e Domain-based Message Authentication, Reporting and Conformance (DMARC). | Obbligo per enti governativi | |
Danimarca | Requisiti tecnici minimi per enti governativi 2023 | Tutti gli enti governativi sono obbligati a implementare, su tutti i domini, una policy DMARC di p=reject. | Obbligo per enti governativi | |
Nuova Zelanda | Information Security Manual Nuova Zelanda, v3.6, sezione 15.2 (2022) | Il futuro successore di SEEMail utilizzerà DMARC; di conseguenza fornitori e autorità dovranno rispettare: 1. Conformità DMARC da SHOULD a MUST [CID:6019] [CID:6021] 2. Policy DMARC da p="none" a p="reject" [CID:6020] 3. Conformità DKIM da SHOULD a MUST [CID:1797] [CID:1798] | Obbligo per enti governativi | |
Irlanda | Standard base di cybersecurity per il settore pubblico, sezione 2.9 | Le organizzazioni del settore pubblico devono implementare TLS, SPF, DKIM e applicare una policy DMARC su tutte le e-mail in ingresso. | Obbligo per enti governativi | |
Paesi Bassi | Standard "Comply or Explain" | Regole obbligatorie per gli enti pubblici che prescrivono DKIM, SPF e DMARC, oltre a STARTTLS e DANE. | Obbligo per enti governativi | |
Arabia Saudita | Guida all'implementazione dei controlli essenziali di cybersecurity (ECC), sezione 2-4-3 | Le organizzazioni nazionali devono adottare tutte le misure necessarie per analizzare e filtrare le e-mail (inclusi phishing e spam) tramite tecnologie di protezione avanzate e aggiornate. Tra gli approcci consigliati figurano DKIM, SPF e DMARC. | Obbligo per enti governativi | |
Regno Unito | Manuale per la politica di cybersecurity governativa – Principio: B3 Sicurezza dati | Gli enti governativi devono possedere record DMARC, DKIM e SPF per i propri domini. Questo deve essere associato a MTA-STS e TLS Reporting. La richiesta deriva dal Minimum Cybersecurity Standard del 2018. | Obbligo per enti governativi | |
Regno Unito | Messa in sicurezza delle e-mail governative | Tutte le e-mail delle organizzazioni del settore pubblico su Internet devono essere almeno crittografate tramite TLS e autenticate con DMARC. | Obbligo per enti governativi | |
Regno Unito | Aggiornamento delle raccomandazioni di sicurezza per i servizi digitali | Ogni servizio su service.gov.uk deve pubblicare una policy DMARC. | Obbligo per enti governativi | |
USA | Direttiva operativa vincolante 18-01: Potenziamento della sicurezza e-mail e web | Tutte le agenzie federali devono rafforzare la sicurezza web tramite STARTTLS, SPF, DKIM e DMARC con policy p=reject. | Obbligo per enti governativi | |
Australia | Raccomandazioni di cybersicurezza: guida per le e-mail | Raccomanda l'implementazione di SPF, DKIM e DMARC con policy p=reject | Raccomandazione | |
Australia | Come contrastare le e-mail fraudolente | Raccomanda l'uso di SPF, DKIM e DMARC per prevenire l'utilizzo dei propri domini come fonte di falsi messaggi e-mail. | Raccomandazione | |
Australia | Strategie per contenere le e-mail malevoli | Raccomanda i metodi più efficaci per proteggere le organizzazioni dagli attacchi e-mail, in particolare l'uso di DKIM, SPF e DMARC con policy "p=reject". | Raccomandazione | |
Canada | Guida all'implementazione: Protezione dei domini e-mail (ITSP.40.065 v1.1) | Per una protezione completa contro lo spoofing, le organizzazioni dovrebbero implementare SPF, DKIM e DMARC. | Raccomandazione | |
UE | Standard di sicurezza per la comunicazione e-mail | Raccomanda di utilizzare STARTTLS, SPF, DKIM, DMARC e DANE per proteggere la comunicazione e-mail. | Raccomandazione | |
Germania | Contromisure contro spam e phishing, sezione 3.1 | Misure raccomandate per i fornitori di accesso a Internet per ridurre i problemi derivanti da malware e spam tramite SPF, DKIM e DMARC. | Raccomandazione | |
Arabia Saudita | Campagne di phishing con il malware Emotet | Implementa Domain-based Message Authentication, Reporting and Conformance (DMARC) per individuare lo spoofing delle email usando record Domain Name System (DNS) e firme digitali. | Raccomandazioni | |
Scozia | Una strategia di cyber-resilienza per la Scozia: Piano d'azione per il settore pubblico 2017-2018, v2 | Le organizzazioni pubbliche dovrebbero beneficiare della protezione contro lo spoofing fornita da DMARC. | Raccomandazioni | |
Regno Unito | Sicurezza delle email e anti-spoofing v2 | Rendi più difficile l'invio di email contraffatte dai domini della tua organizzazione implementando SPF, DKIM e DMARC con almeno la policy p=none – anche per i domini non utilizzati. Proteggi le tue email durante il trasporto con TLS. | Raccomandazioni | |
Regno Unito | Phishing: la difesa delle organizzazioni v1.1 | DMARC, SPF e DKIM sono difese di livello 1 per bloccare le email contraffatte utilizzate per attaccare un'organizzazione. | Raccomandazioni | |
Stati Uniti | CIS Controlli di sicurezza critici v8.0, IG2-9.5 | Implementa la policy e la verifica DMARC, iniziando dal Sender Policy Framework (SPF) e dagli standard DomainKeys Identified Mail (DKIM). | Raccomandazioni | |
Stati Uniti | CISA INSIGHTS Migliorare la sicurezza email e web | Abilita DKIM, SPF e DMARC con una policy p=reject. | Raccomandazioni | |
Stati Uniti | Multi-State Information Sharing and Analysis Center (MS-ISAC) Linee guida ransomware | Per ridurre il rischio di email false o alterate inviate da domini validi, implementa una policy DMARC e la relativa verifica. | Raccomandazioni | |
Stati Uniti | NIST 800-53 Catalogo dei controlli di sicurezza – Revisione 5: SI-08 | Utilizza meccanismi di protezione antispam ai punti di ingresso e uscita del sistema per rilevare e gestire messaggi indesiderati. DMARC, SPF e DKIM sono un modo per farlo. | Raccomandazioni | |
Stati Uniti | NIST Special Publication 800-177 Revisione 1: Email affidabile | Raccomanda l'implementazione di SPF, DKIM e DMARC e di altri controlli per rafforzare la fiducia nelle email. | Raccomandazioni |
Cosa succede da qui in avanti?
Lo scenario della sicurezza delle email e dell'autenticazione è in costante evoluzione.
Noi di Red Sift comprendiamo la complessità nell'implementazione e nella gestione di DMARC. La nostra soluzione pluripremiata Red Sift OnDMARC è stata progettata per semplificare l'adozione di DMARC, offrendoti tecnologia all'avanguardia e competenze riconosciute.
Domande frequenti: Guida alla sicurezza e-mail
Tutte le misure di sicurezza per l’e-mail (tranne DMARC) risultano inefficaci se un’e-mail dannosa sembra provenire da un dominio legittimo. Il motivo è un difetto nel Simple Mail Transfer Protocol (SMTP). Nell’ottobre 2008, la Network Working Group lo ha ufficialmente classificato come “fondamentalmente insicuro” e ha rilevato che chiunque può imitare un dominio e inviare e-mail fraudolente a nome del titolare del dominio.
Chiunque abbia conoscenze di programmazione di base può acquisire con una rapida ricerca su Google quello che serve a imitare l’identità e-mail di qualcun altro. Il risultato è un’e-mail che sembra legittima e non presenta tipici segnali di phishing. Con 3,4 miliardi di e-mail di phishing al giorno, i sistemi di posta restano il principale obiettivo dei criminali informatici.
SPF (Sender Policy Framework) verifica se un’e-mail è stata inviata da un indirizzo IP autorizzato dal record SPF del dominio mittente. Ciò avviene tramite un record DNS TXT che elenca i mail server autorizzati.
DKIM (DomainKeys Identified Mail) utilizza una firma crittografica, validata tramite una chiave pubblica nel DNS, per confermare che il contenuto dell’e-mail non sia stato modificato e provenga da un dominio autorizzato. Entrambe sono fondamentali per la sicurezza e-mail, ma non impediscono l’imitazione esatta del dominio.
Sebbene questi protocolli mostrino al destinatario da chi provenga l’e-mail, non forniscono istruzioni su come deve comportarsi. I principali provider di posta richiederanno dal 2026 SPF e DKIM per l’invio di comunicazioni massive.
DMARC sta per Domain-based Message Authentication, Reporting e Conformance. È un protocollo di sicurezza e-mail in uscita che consente ai proprietari di dominio di comunicare alle caselle di posta destinarie di rifiutare le e-mail contraffatte. DMARC combina i risultati di SPF e DKIM per determinare se la tua e-mail è legittima e autorizzata.
La policy DMARC (definita dal tag “p=” nel record DNS) indica poi ai server destinatari che cosa fare di queste e-mail. DMARC previene imitazioni esatte del dominio istruendo i server ricevitori a non accettare e-mail non autenticate. Dal 2026 DMARC è divenuto lo standard per le organizzazioni che inviano comunicazioni massive.
La specifica SPF limita le ricerche DNS a 10. Se il tuo record SPF supera questa soglia, la verifica SPF fallisce. I meccanismi contati sono: a, ptr, mx, include, redirect ed exists. In pratica, 10 lookup spesso non bastano: molte aziende usano più strumenti di invio e-mail.
G Suite da solo occupa 4 lookup DNS, e possono aggiungersene 7 per esempio per attività di marketing su HubSpot – e il limite viene già superato. Con oltre 10 lookup SPF, la validazione delle e-mail causa errori casuali. Nel 2026, le aziende scelgono una gestione SPF dinamica invece di provare a mantenere manualmente le configurazioni "appianate".
Mail Transfer Agent Strict Transport Security (MTA-STS) è uno standard che garantisce la crittografia delle e-mail spedite tra due mail server. Esso stabilisce che le e-mail devono essere inviate solo tramite una connessione cifrata con Transport Layer Security (TLS), prevenendo così le intercettazioni da parte dei cybercriminali. Il protocollo SMTP, da solo, non offre sicurezza ed è soggetto agli attacchi “man-in-the-middle”, che permettono di intercettare e modificare la comunicazione.
Inoltre, la crittografia in SMTP è opzionale; ciò significa che le e-mail possono essere trasmesse in chiaro. Senza MTA-STS, un attaccante può intercettare la comunicazione e forzare la trasmissione in chiaro del messaggio. Nel 2026 MTA-STS rappresenta una misura di sicurezza standard per le organizzazioni che trattano comunicazioni sensibili.
Implementando DMARC beneficerai del blocco di tentativi di phishing che sembrano provenire dal tuo dominio, maggiore fiducia da parte dei clienti, riduzione del rischio cyber, e conformità ai requisiti sui mailing massivi di Google, Yahoo e Microsoft.
DMARC contribuisce inoltre alla conformità con PCI DSS 4.0 e aumenta la resilienza organizzativa generale rispetto all’evoluzione delle minacce informatiche. Con una policy impostata su p=reject (applicazione), DMARC blocca le frodi ai fornitori, il furto di account e lo spoofing delle e-mail impedendo a terzi di usare il tuo dominio per phishing o Business Email Compromise (BEC). Secondo il Data Breach Investigations Report di Verizon 2025, oltre il 17–22% di tutti gli episodi di social engineering riguarda attacchi BEC.
Red Sift OnDMARC accelera l’adozione di DMARC grazie alla ricerca automatizzata dei mittenti, suggerimenti concreti, rilevamento delle anomalie e accesso basato sui ruoli per team globali. Nel 2026, le piattaforme leader permettono alle aziende di arrivare alla piena applicazione p=reject in 6–8 settimane invece che nei sei mesi tradizionali.
Uno dei vantaggi più citati di OnDMARC è il tempo medio di 6–8 settimane per raggiungere la piena enforcement. La potente automazione della piattaforma analizza costantemente tutti gli eventi sul tuo dominio e fornisce indicazioni e suggerimenti sugli interventi necessari. Già 24 ore dopo aver aggiunto il tuo record DMARC personalizzato nel DNS, OnDMARC inizia ad analizzare i report DMARC e a presentarli in dashboard chiare.
I maggiori provider e-mail come Microsoft, Google e Yahoo richiedono dal 2024–2025 DMARC per chi effettua invii massivi (ossia le organizzazioni che superano le 5.000 e-mail al giorno), e questi requisiti sono ormai lo standard nel 2026.
Oltre alle richieste dei fornitori di posta, interi settori e normative di autorità stanno sempre più adottando DMARC. Le agenzie federali USA devono utilizzare DMARC, così come i fornitori di servizi di pagamento regolati da DORA. Inoltre, implementare DMARC rafforza la conformità a normative quali PCI DSS 4.0, GDPR e NIS2. Per i team di cybersecurity, sicurezza e-mail e IT, è essenziale allineare la sicurezza delle e-mail della propria organizzazione alle migliori pratiche e ai requisiti internazionali.




