Per proteggere il dominio email di un’azienda servono SPF, DKIM, DMARC e MTA-STS configurati correttamente, monitorati nel tempo e portati gradualmente in enforcement. In pratica, significa autorizzare chi può inviare email per conto del dominio, firmare i messaggi, dire ai provider cosa fare quando un’email non supera i controlli e proteggere il trasporto dei messaggi tra server tramite TLS.
Che cos’è la protezione del dominio email?
La protezione del dominio email è l’insieme di controlli tecnici e processi operativi che impediscono a terzi non autorizzati di usare un dominio aziendale per inviare messaggi fraudolenti, riducendo spoofing, phishing, impersonificazione e problemi di deliverability.
Nel 2026 parlare di protezione del dominio non significa più aggiungere “un record DNS” e dimenticarsene. Significa governare l’identità digitale dell’azienda nel canale che, ancora oggi, resta uno dei più esposti agli attacchi. L’email nasce su protocolli che non verificavano davvero l’identità del mittente. Per questo un attaccante può provare a presentarsi come amministrazione, HR, direzione o fornitore, sfruttando la fiducia legata al nome del dominio.
Perché la protezione del dominio è diventata critica?
Oggi un dominio non protetto è un rischio tecnico, reputazionale e operativo. I principali provider hanno alzato l’asticella per i mittenti massivi, le normative chiedono controlli anti-phishing automatizzati e le assicurazioni cyber osservano sempre più spesso la postura email come indicatore di maturità.
Il cambiamento più importante è arrivato con RFC 9989. Pubblicata a maggio 2026, questa nuova specifica ha portato DMARC nello Standards Track IETF come Proposed Standard e ha sostituito RFC 7489 e RFC 9091. In parallelo, RFC 9990 regola i report aggregati, mentre RFC 9991 riguarda i report di fallimento. Per chi gestisce domini aziendali, il messaggio è semplice: l’autenticazione email non è più un dettaglio tecnico, ma una parte essenziale della fiducia digitale dell’azienda.
Che cosa sono SPF, DKIM e DMARC?
SPF, DKIM e DMARC sono tre controlli diversi, ma vanno letti come un unico sistema. SPF dice quali server possono inviare email per il dominio. DKIM firma crittograficamente il messaggio per dimostrare che non è stato alterato. DMARC collega questi controlli al dominio visibile nel campo “Da” e indica al destinatario come comportarsi se l’autenticazione fallisce.
| Controllo | A cosa serve | Limite pratico |
| SPF | Autorizza gli indirizzi IP o i servizi che possono inviare email per il dominio. | Può rompersi con inoltri e forwarding; inoltre ha il limite dei 10 lookup DNS. |
| DKIM | Applica una firma digitale al messaggio e ne protegge l’integrità. | Funziona bene solo se tutti i sistemi autorizzati firmano correttamente. |
| DMARC | Verifica l’allineamento con il dominio visibile all’utente e definisce la policy. | Richiede analisi, monitoraggio e una migrazione controllata verso quarantine o reject. |
Che cosa cambia con RFC 9989?
RFC 9989 non cambia tutto da zero. Le aziende continuano a pubblicare record DMARC che iniziano con v=DMARC1. La differenza è che lo standard chiarisce meglio alcuni comportamenti e riduce le ambiguità che, negli anni, avevano portato provider diversi a interpretare DMARC in modo non sempre uniforme.
La novità più evidente riguarda il passaggio dalla Public Suffix List al DNS Tree Walk. Detto in modo semplice: prima molti provider usavano una lista esterna per capire dove finiva il suffisso pubblico, per esempio “.it” o “.com”, e dove iniziava il dominio dell’azienda. Con il DNS Tree Walk, invece, il provider risale la struttura DNS e cerca direttamente i record DMARC più adatti. È un approccio più chiaro e meno dipendente da liste esterne.
Quali sono i nuovi tag DMARC da conoscere?
Il nuovo standard introduce tag pensati per descrivere meglio l’intenzione del proprietario del dominio. Non servono a “fare più sicurezza” da soli, ma aiutano i provider a interpretare in modo più prevedibile la policy pubblicata.
| Tag | Significato | Esempio d’uso |
| np= | Definisce la policy per i sottodomini inesistenti. | np=reject per bloccare email da sottodomini inventati, come pagamenti.azienda.it se non esiste. |
| psd= | Indica se un dominio è un Public Suffix Domain o un dominio organizzativo. | Utile in strutture DNS complesse o delegate. |
| t= | Segnala una fase di test e sostituisce il vecchio approccio basato su pct=. | t=y durante una migrazione controllata verso enforcement. |
Perché i report DMARC sono così importanti?
Molte aziende pubblicano un record DMARC e pensano di aver finito. In realtà, il valore operativo di DMARC sta soprattutto nei report. I report aggregati RUA mostrano chi sta inviando email per conto del dominio, quali flussi passano SPF, DKIM e DMARC, dove ci sono errori di configurazione e dove compaiono segnali di spoofing.
I report forensi RUF, invece, riguardano singole email che non superano i controlli di autenticazione. Possono essere utili per capire cosa è andato storto in casi specifici, ma vanno gestiti con attenzione: potrebbero contenere informazioni sensibili. Per questo RFC 9991 introduce indicazioni dedicate alla privacy e alla riduzione dei dati presenti nei failure report.
Che ruolo ha BIMI nella protezione del dominio?
BIMI, cioè Brand Indicators for Message Identification, permette di mostrare il logo del brand nelle caselle di posta che lo supportano. Però non va visto come un semplice strumento di branding. Per funzionare richiede una configurazione email solida, perché il dominio deve avere una policy DMARC in enforcement, quindi p=quarantine o p=reject, con copertura completa.
In alcune implementazioni, soprattutto per provider come Gmail e Apple Mail, può essere richiesto anche un certificato come VMC o CMC, che attesta il diritto dell’organizzazione a usare quel logo. Il punto di sicurezza è semplice: un marchio visibile nella inbox ha senso solo se prima il dominio è davvero autenticato.
Che cos’è MTA-STS e perché completa DMARC?
MTA-STS, cioè SMTP MTA Strict Transport Security, è lo standard definito da RFC 8461 per proteggere il trasporto delle email in ingresso. Se SPF, DKIM e DMARC lavorano sull’identità del mittente e sull’allineamento del dominio, MTA-STS lavora su un altro piano: la sicurezza della connessione tra server di posta. Il suo obiettivo è evitare che un messaggio venga consegnato in chiaro quando dovrebbe viaggiare su una connessione TLS valida.
Il punto critico è che SMTP usa spesso STARTTLS in modo opportunistico: se la crittografia non viene negoziata, il messaggio può comunque essere inviato. In uno scenario di downgrade attack, un attaccante posizionato lungo il percorso può interferire con la negoziazione e far credere al server mittente che TLS non sia disponibile. Con MTA-STS in modalità enforce, invece, il dominio dichiara quali MX sono autorizzati a ricevere email e richiede una connessione TLS con certificato valido. Se queste condizioni non sono rispettate, il server mittente che supporta MTA-STS non dovrebbe consegnare il messaggio.
Per questo MTA-STS non sostituisce DMARC, ma lo completa. DMARC aiuta a capire se un’email è autorizzata a usare il dominio visibile al destinatario; MTA-STS riduce il rischio che email legittime, anche se correttamente autenticate, vengano trasmesse su un canale non sicuro. Nella pratica richiede un record DNS TXT _mta-sts, una policy pubblicata via HTTPS e, idealmente, anche TLS-RPT per ricevere report sugli errori di consegna legati a TLS.
Quali obblighi spingono le aziende verso DMARC?
La spinta verso DMARC arriva anche dai grandi provider. Dal 2024 Google e Yahoo hanno introdotto requisiti più severi per chi invia grandi volumi di email: SPF, DKIM, DMARC, basso tasso di spam e disiscrizione semplice. Nel 2025 anche Microsoft ha adottato requisiti simili per domini consumer come Outlook.com, Hotmail.com e Live.com. Per le aziende che inviano molte email, non adeguarsi può significare vedere i messaggi rifiutati o consegnati peggio.
C’è poi il tema della compliance. PCI DSS v4.0.1, dal 31 marzo 2025, richiede processi e meccanismi automatici per rilevare e proteggere il personale dagli attacchi di phishing. In altre parole, non basta fare formazione: servono anche controlli tecnici continui. Nella pratica, SPF, DKIM e DMARC sono tra i controlli più osservati in questo contesto.
Come si passa da p=none a p=reject senza rompere l’email?
Il passaggio a una policy più restrittiva va fatto con attenzione. Se si blocca troppo presto il traffico non conforme, si rischia di fermare anche email legittime: fatture, reset password, comunicazioni HR o campagne marketing. Per questo la strada corretta non è attivare reject da un giorno all’altro, ma osservare i flussi, correggere gli errori e poi aumentare gradualmente il livello di protezione.
- Monitorare con p=none. Si pubblica il record e si raccolgono report per almeno 30-90 giorni, così da intercettare anche flussi periodici.
- Riconciliare i mittenti. Si identificano piattaforme legittime, Shadow IT, servizi marketing, CRM, sistemi transazionali e fornitori.
- Correggere SPF e DKIM. Ogni flusso autorizzato deve autenticarsi e allinearsi correttamente al dominio visibile.
- Passare a quarantine. I messaggi non conformi vengono trattati come sospetti, riducendo il rischio senza arrivare subito al blocco totale.
- Arrivare a reject. Quando il traffico legittimo è sotto controllo, i messaggi non autenticati possono essere rifiutati.
Quando serve un MSSP per la Domain Protection?
Un MSSP diventa utile quando l’azienda ha molti domini, molti fornitori, più piattaforme di invio e poca visibilità centralizzata. In questi casi il problema non è soltanto tecnico, ma operativo: capire chi invia, chi dovrebbe inviare, quali record aggiornare, quali vendor coinvolgere e quando è sicuro alzare il livello di enforcement.
Un servizio di Domain Protection ben gestito aiuta a trasformare i report DMARC, spesso difficili da leggere perché in formato XML, in decisioni operative: quali fonti autorizzare, quali eliminare, quali domini proteggere anche se non inviano email e quali sottodomini espongono l’azienda a spoofing. Il collegamento con un servizio di cybersecurity nasce da qui: DMARC funziona davvero solo se viene seguito, aggiornato e governato nel tempo.
Il dominio email è identità aziendale
Nel 2026 proteggere il dominio email significa proteggere la fiducia verso l’azienda. DMARC, SPF, DKIM, BIMI, MTA-STS e reporting non sono solo sigle tecniche da inserire in una checklist. Servono a distinguere le comunicazioni legittime da quelle sospette, rendere più difficile l’impersonificazione del brand e ridurre il rischio che messaggi autentici viaggino su connessioni non sicure. La vera maturità non sta nel pubblicare un record, ma nel portare il dominio in enforcement senza creare problemi al business.
Fonti di riferimento
- IETF, RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance, maggio 2026.
- IETF, RFC 8461, SMTP MTA Strict Transport Security (MTA-STS), settembre 2018.
- RFC Editor, RFC 9989, RFC 9990 e RFC 9991, documenti DMARC aggiornati.
- org, IETF Publishes Updated DMARC Specification, 2026.
- Proofpoint, Implementing DMARC to Meet PCI DSS v4.0 Requirements.
- BIMI Group, BIMI Implementation Guide.
- Google, Yahoo e Microsoft, requisiti per bulk sender e autenticazione email.
