La guida definitiva di Red Sift alla sicurezza delle email
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 delle email
Tutte le misure di sicurezza delle email (ad eccezione di DMARC) sono inefficaci nell'individuare un'email dannosa quando sembra provenire da un dominio legittimo. Questo a causa di un difetto nel Simple Mail Transfer Protocol (SMTP). Nell'ottobre 2008, il Network Working Group lo ha ufficialmente definito 'intrinsecamente insicuro', dichiarando che chiunque potesse impersonare un dominio e utilizzarlo per inviare email fraudolente fingendo di essere il proprietario del dominio.
Chiunque abbia conoscenze di base di programmazione può apprendere velocemente, con una semplice ricerca su Google, i passaggi necessari per impersonare l'identità email di qualcuno. Il risultato è un'email che sembra legittima, senza i soliti segnali di phishing. Con 3,4 miliardi di email di phishing inviate ogni giorno, i sistemi di posta elettronica rimangono il bersaglio principale dei cybercriminali.
SPF (Sender Policy Framework) verifica che un'email sia inviata da un indirizzo IP autorizzato dal record SPF del dominio mittente tramite un record DNS TXT che elenca i server di posta autorizzati.
DKIM (DomainKeys Identified Mail) utilizza una firma crittografica, validata tramite una chiave pubblica nel DNS, per confermare che il contenuto dell'email non sia stato alterato e provenga da un dominio autorizzato. Entrambi sono essenziali per la sicurezza delle email, ma nessuno dei due previene l'impersonificazione esatta.
Mentre i protocolli comunicano al destinatario chi è il mittente dell'email, quest'ultimo non riceve istruzioni su come agire con tale informazione. I principali fornitori di caselle di posta ora richiedono SPF e DKIM per chi invia email massive nel 2026.
DMARC sta per Domain-based Message Authentication, Reporting, and Conformance. È un protocollo di sicurezza email in uscita che consente ai proprietari di un dominio di istruire le caselle di posta riceventi a rifiutare email contraffatte. DMARC funziona combinando i risultati di SPF e DKIM per determinare se la tua email è autentica e autorizzata.
La policy DMARC (definita dal tag "p=" nel tuo record DNS) indica poi ai server destinatari cosa fare con quell'email. DMARC blocca l'impersonificazione esatta del dominio istruendo i server destinatari a non accettare email non autenticate. Nel 2026, DMARC è diventato un requisito standard per le organizzazioni che inviano email massive.
La specifica SPF limita le ricerche DNS a 10. Se il tuo record SPF supera questo limite, SPF fallirà. I meccanismi SPF conteggiati sono: a, ptr, mx, include, redirect ed exists. In realtà, 10 ricerche non sono sufficienti perché la maggior parte delle aziende usa diversi strumenti per inviare email.
G Suite da solo consuma 4 ricerche DNS, aggiungi HubSpot per il marketing che usa 7 ricerche e hai già superato il limite. Non appena superi le 10 ricerche SPF, il traffico email inizierà a fallire casualmente la validazione. Ecco perché le organizzazioni nel 2026 stanno passando a una gestione dinamica di SPF invece di mantenere manualmente record compressi.
Mail Transfer Agent Strict Transport Security (MTA-STS) è uno standard che consente la cifratura dei messaggi scambiati tra due server di posta. Specifica che le email possono essere inviate solo tramite una connessione crittografata Transport Layer Security (TLS), impedendo così l'intercettazione da parte dei cybercriminali. SMTP da solo non offre sicurezza, rendendolo vulnerabile ad attacchi man-in-the-middle in cui la comunicazione può essere intercettata e modificata.
Inoltre, la cifratura in SMTP è opzionale, quindi le email possono essere inviate in chiaro. Senza MTA-STS, un attaccante può intercettare la comunicazione e forzare l'invio del messaggio in formato non cifrato. Nel 2026, MTA-STS è uno standard di sicurezza per tutte le organizzazioni che gestiscono comunicazioni sensibili.
Implementando DMARC ottieni il vantaggio di bloccare i tentativi di phishing che sembrano provenire da te, rafforzare la fiducia dei clienti, ridurre il rischio cyber e conformarti ai requisiti dei principali provider come Google, Yahoo e Microsoft per l'invio massivo di email.
DMARC rafforza la conformità a PCI DSS 4.0 e aumenta la resilienza organizzativa contro le minacce cyber in evoluzione. Una volta a p=reject (enforcement), DMARC blocca truffe dei fornitori, compromissioni di account e lo spoofing della posta impedendo agli attori malevoli di utilizzare il tuo dominio per inviare email di phishing e condurre Business Email Compromise (BEC). Secondo il Data Breach Investigations Report 2025 di Verizon, gli attacchi BEC rappresentano oltre il 17-22% di tutti gli incidenti di Social Engineering.
Red Sift OnDMARC accelera l'adozione di DMARC con una scoperta automatica dei mittenti, correzioni prescritte, rilevamento di anomalie e accesso per team globali in base ai ruoli. Nel 2026, le migliori piattaforme consentono alle aziende di raggiungere il livello di enforcement p=reject in 6-8 settimane, invece dei sei mesi che erano la norma.
Uno dei vantaggi più segnalati di OnDMARC è proprio il tempo medio di 6-8 settimane per arrivare alla piena enforcement. L'automazione della piattaforma analizza costantemente cosa sta accadendo sul tuo dominio, generando avvisi su cosa e dove intervenire. Entro 24 ore dall'aggiunta del record DMARC unico in DNS, OnDMARC inizia ad analizzare e mostrare i report DMARC tramite dashboard chiare.
I principali provider di email come Microsoft, Google e Yahoo ora impongono DMARC per chi invia email massive (oltre 5.000 email al giorno) dal 2024-2025, e tali requisiti sono diventati uno standard nel 2026.
Oltre ai requisiti imposti dai provider di caselle di posta, alcuni settori e normative governative stanno introducendo l'obbligo di DMARC. Per esempio, le agenzie federali statunitensi e i processori di pagamenti regolamentati da DORA devono adottare DMARC. L'implementazione di DMARC rafforza anche la conformità a regolamenti come PCI DSS 4.0, GDPR e NIS2. Per i team di sicurezza, email e IT, garantire la sicurezza delle email aziendali in linea con le best practice internazionali è fondamentale.