A maggio 2026 l’IETF ha pubblicato la revisione della specifica DMARC. Non è un aggiornamento urgente e non richiede interventi notturni, ma rende obsoleti alcuni parametri che quasi tutte le newsletter aziendali hanno ancora scritti nel DNS.
Tre righe di testo in una zona DNS decidono se la newsletter arriva in casella o viene respinta prima ancora di essere filtrata. È il pezzo di infrastruttura di comunicazione con il rapporto più sbilanciato tra importanza e attenzione ricevuta: nessuno lo guarda finché non smette di funzionare, e quando smette di funzionare non ci sono avvisi in dashboard. A maggio 2026 quel pezzo di infrastruttura è cambiato.
Cosa fanno le tre sigle
SPF dichiara quali server hanno il permesso di spedire posta a nome di un dominio. È una lista di indirizzi pubblicata nel DNS.
DKIM appone a ogni messaggio una firma crittografica verificabile con una chiave pubblica anch’essa nel DNS. Dimostra che il messaggio non è stato alterato in transito e che proviene da chi dice di provenire.
DMARC è la regola che collega le due cose all’indirizzo che il destinatario vede nel campo “Da”. Stabilisce cosa deve fare il provider quando un messaggio non supera i controlli — ignorare, mettere in quarantena, rifiutare — e dove spedire i rapporti su quanto sta accadendo.
Senza DMARC, SPF e DKIM verificano un mittente tecnico che l’utente non vede mai. È il motivo per cui per anni un indirizzo falsificato passava con la stessa facilità di uno legittimo.
Cosa è successo a maggio
L’IETF ha pubblicato tre documenti — RFC 9989, 9990 e 9991 — che sostituiscono la specifica originale del 2015, la RFC 7489. Il primo definisce il protocollo, il secondo i rapporti aggregati, il terzo i rapporti di errore.
Il cambiamento più rilevante non è tecnico ma di status. La specifica del 2015 era un documento Informational pubblicato fuori dal processo di standardizzazione IETF: descriveva una prassi, non imponeva un comportamento, e infatti i vari fornitori l’hanno implementata con interpretazioni diverse per undici anni. Le nuove RFC sono Proposed Standard sullo Standards Track. Da oggi chi scrive una gara d’appalto, una policy di sicurezza o un requisito contrattuale ha uno standard formale da citare.
Prima di allarmare chi gestisce il DNS: non esiste alcun “DMARC2”. Il record continua a iniziare con v=DMARC1 e i record esistenti restano validi. Non serve una modifica d’emergenza.
I parametri che non ci sono più
Serve però una revisione, perché il set di tag è cambiato. Sono usciti dalla specifica pct, rf e ri. Sono entrati np, psd e t.
Il più diffuso dei tre uscenti è pct, e vale la pena capire perché. Serviva ad applicare la policy solo a una percentuale dei messaggi: p=quarantine; pct=25 significava mettere in quarantena un quarto della posta non conforme. Era il metodo standard per irrigidire la policy per gradi senza rischiare di bloccare comunicazioni legittime. Chiunque abbia fatto una migrazione DMARC negli ultimi cinque anni ha quasi certamente un pct scritto da qualche parte.
La graduazione ora si esprime con il tag t, che segnala esplicitamente una fase di test. I ricevitori conformi ignorano i tag che non riconoscono, quindi un vecchio record con pct non si romperà. Semplicemente non farà più ciò che chi l’ha scritto crede che faccia. È una categoria di guasto peggiore di un errore visibile.
L’altra modifica strutturale riguarda il modo in cui si determina il dominio organizzativo, cioè il dominio “padre” da cui un sottodominio eredita la policy. Prima si passava per la Public Suffix List, un elenco mantenuto esternamente. Ora la procedura risale l’albero DNS interrogando direttamente i livelli superiori. Per chi gestisce molti sottodomini — e le strutture di comunicazione ne gestiscono sempre, tra piattaforme di invio, eventi e campagne — significa che l’ereditarietà delle policy va riverificata, non data per acquisita.
Perché non è più facoltativo
Questa revisione arriva dopo due anni in cui i grandi provider hanno trasformato l’autenticazione da buona pratica a condizione d’accesso. Google e Yahoo hanno annunciato i requisiti per i mittenti massivi nell’ottobre 2023, con applicazione da febbraio 2024. Microsoft ha esteso regole analoghe alle caselle consumer Outlook.com, Hotmail e Live da maggio 2025.
La soglia, in tutti e tre i casi, è nell’ordine dei 5.000 messaggi al giorno verso caselle personali. Due dettagli contano più della soglia stessa. Il primo: il conteggio riguarda le caselle di consumo, non gli account aziendali ospitati su Workspace o Microsoft 365. Il secondo: secondo le linee guida di Google la classificazione come mittente massivo, una volta raggiunta, non decade se il volume successivamente scende.
Agli obblighi di autenticazione si affiancano un tasso di segnalazioni spam da mantenere sotto lo 0,3% e la disiscrizione con un clic prevista dalla RFC 8058. La sanzione non è la cartella spam: è il rifiuto a livello SMTP. Il messaggio non viene consegnato male, non viene consegnato.
Cinque verifiche
Leggere il record attuale e cercare pct. Se c’è, la strategia di rollout che descriveva non è più garantita.
Controllare in quale fase si trova la policy. Un p=none mantenuto per anni soddisfa formalmente il requisito di avere un record, ma non protegge da nulla e viene guardato con crescente diffidenza.
Verificare l’allineamento sui sottodomini alla luce della nuova procedura di risoluzione del dominio organizzativo.
Controllare che ogni piattaforma di invio in uso — la newsletter, il CRM, il sistema transazionale, lo strumento che qualcuno ha attivato per un evento e non ha mai spento — sia autenticata sul dominio. Il tasso di lamentele si calcola sul dominio, non sulla singola piattaforma.
Verificare che lo strumento di monitoraggio in uso interpreti i nuovi tag. Un cruscotto che continua a mostrare come valido un parametro rimosso non sta monitorando: sta rassicurando.
Fonti: IETF, RFC 9989, 9990 e 9991, maggio 2026 (protocollo DMARC, rapporti aggregati, rapporti di errore; sostituiscono la RFC 7489 del 2015); IETF, RFC 8058 (disiscrizione con un clic); Google, Email sender guidelines (definizione di mittente massivo, soglia verso caselle Gmail personali, permanenza della classificazione, soglia di segnalazioni spam); Microsoft, requisiti per mittenti ad alto volume verso caselle Outlook.com, Hotmail e Live, in vigore da maggio 2025; documentazione tecnica di settore sulla transizione a DMARCbis relativa alla modifica del set di tag e alla procedura di risoluzione del dominio organizzativo.