Capita spesso che un'azienda pubblichi un record DMARC su p=none e lo lasci lì per anni. È il primo passo giusto, ma da solo non protegge nulla. Con none il dominio chiede ai server che ricevono la posta di consegnare comunque anche i messaggi che falliscono i controlli, e di mandare un rapporto. Chi usa il tuo nome nel mittente per una falsa richiesta di pagamento continua a farlo. L'obiettivo è arrivare a p=reject, la politica con cui la posta che finge di essere tua viene rifiutata. La paura che frena è sempre la stessa: bloccare le proprie fatture o le proprie newsletter. Un percorso ordinato in sei settimane evita entrambe le cose.
Cosa è cambiato nel 2026
A maggio 2026 l'IETF ha pubblicato la nuova versione dello standard, la RFC 9989, che sostituisce la RFC 7489 del 2015. Per chi deve fare questo percorso cambiano due cose. La prima: il tag pct, che permetteva di applicare la politica solo a una percentuale dei messaggi, non esiste più. Il testo spiega che nell'esperienza operativa veniva applicato correttamente solo con i valori 0 e 100. Al suo posto c'è un segnale di prova, t=y, che chiede di non applicare la politica dichiarata.
La seconda: entra nello standard il tag np, la politica per i sottodomini che non esistono. Le guide che suggeriscono di salire al 25, poi al 50, poi al 100 per cento descrivono quindi un metodo superato. Il passaggio da una politica all'altra è netto, e la sicurezza viene dalla fase di lettura dei rapporti.
Perché none non basta più
I grandi provider di posta hanno trasformato l'autenticazione in un requisito. Google, dal febbraio 2024, chiede a chi invia oltre cinquemila messaggi al giorno verso indirizzi Gmail di avere SPF, DKIM e un record DMARC almeno su none, e dal novembre 2025 applica i requisiti con rinvii e rifiuti dei messaggi non conformi. Microsoft ha introdotto requisiti analoghi dal 5 maggio 2025 per i propri servizi di posta consumer.
Sono soglie pensate per i grandi volumi, ma i filtri aziendali usano criteri simili anche sotto soglia. C'è poi una ragione che non dipende dai provider: senza una politica di rifiuto chiunque può spedire posta con il tuo dominio nel campo mittente, e i tuoi clienti la ricevono.
Settimana 1: l'inventario di chi scrive a tuo nome
Il primo lavoro non è tecnico, è un elenco. Tutti i servizi che inviano posta con il dominio aziendale nel mittente: la posta dei dipendenti, il gestionale che manda le copie di cortesia delle fatture, il CRM, la piattaforma delle newsletter, il sito con il modulo di contatto, il negozio online, il centralino che inoltra i messaggi vocali, il software del personale, l'assistenza clienti. Per ognuno va chiesto al fornitore come si configura l'invio con il proprio dominio.
Nello stesso giorno si pubblica, se manca, il record DMARC su p=none con il tag rua, che indica l'indirizzo a cui i server riceventi spediranno i rapporti aggregati. Conviene anche controllare che il record SPF non superi il limite di dieci interrogazioni DNS fissato dallo standard: oltre quel limite la verifica fallisce per tutti.
Settimane 2 e 3: leggere i rapporti
I rapporti aggregati arrivano ogni giorno, in formato XML, dai principali server riceventi. Per ogni sorgente di invio dicono quanti messaggi sono passati, con quale esito per SPF e DKIM e se il dominio era allineato a quello del mittente. Letti a mano sono quasi illeggibili, e conviene usare uno strumento che li raccolga in una tabella.
In due settimane le sorgenti si dividono in tre gruppi. I servizi legittimi già allineati, su cui non c'è nulla da fare. I servizi legittimi non allineati, che sono il vero lavoro del percorso. Le sorgenti sconosciute, che possono essere un servizio dimenticato nell'inventario oppure qualcuno che usa il tuo dominio senza permesso. Ogni sorgente del terzo gruppo va identificata prima di andare avanti.
Settimana 3: allineare un servizio alla volta
Per quasi tutti i servizi la strada più solida è DKIM con il proprio dominio. Il fornitore genera una chiave, l'azienda pubblica nel DNS il record corrispondente, e da quel momento i messaggi sono firmati con il dominio aziendale e risultano allineati. L'SPF da solo spesso non basta, perché molte piattaforme usano il proprio dominio come indirizzo di ritorno e l'allineamento SPF fallisce anche quando il controllo passa. Per le chiavi conviene usare almeno 2048 bit, come raccomanda la RFC 8301.
Se un servizio non permette di firmare con il dominio aziendale, le soluzioni sono due: spostarlo su un sottodominio dedicato, con una sua politica, oppure cambiare l'indirizzo del mittente. Un servizio non allineato e lasciato com'è verrà bloccato più avanti.
Settimana 4: quarantine
Quando i rapporti di almeno sette giorni consecutivi non mostrano più sorgenti legittime non allineate, si passa a p=quarantine. I messaggi che falliscono finiscono nella cartella della posta indesiderata invece di essere consegnati. È il momento in cui eventuali dimenticanze emergono senza danni definitivi: un cliente che non trova una fattura, un modulo del sito che non arriva più in ufficio.
Conviene avvisare amministrazione e assistenza clienti e chiedere di segnalare ogni anomalia per due settimane. Se qualcosa emerge, si torna al rapporto, si identifica la sorgente e la si sistema come le altre. Se il problema è grave, si può tornare su none per qualche giorno: il record si cambia in pochi minuti.
Settimane 5 e 6: reject, e i sottodomini
Dopo due settimane di quarantine senza segnalazioni si pubblica p=reject. Nello stesso record conviene fissare due politiche spesso dimenticate: sp, che vale per i sottodomini esistenti, e np, che vale per quelli che non esistono e che qualcuno potrebbe inventare per una truffa. I rapporti non vanno spenti: restano attivi e si guardano almeno una volta al mese.
Da questo momento ogni nuovo servizio che invia posta a nome dell'azienda va configurato prima di entrare in funzione, altrimenti i suoi messaggi vengono rifiutati. Lo standard ricorda anche che reject può creare problemi agli inoltri automatici e alle liste di distribuzione che modificano i messaggi: se l'azienda ne usa, vanno provati prima del passaggio.
Chi deve fare il lavoro in azienda
Il percorso tocca il DNS, quindi passa da chi gestisce il dominio, spesso un fornitore informatico esterno. L'inventario però lo conosce chi usa i servizi: amministrazione, marketing, assistenza, chi gestisce il sito. Senza una persona interna che tenga l'elenco e chieda conferma a ciascun reparto, il fornitore tecnico configura quello che vede, e i servizi dimenticati emergono alla settimana quattro.
La divisione che funziona è semplice. Una persona dell'azienda tiene l'inventario e il calendario delle sei settimane. Il fornitore tecnico pubblica i record e legge i rapporti. Ogni cambio di politica si decide insieme, guardando la stessa tabella.
Come verificare il risultato
Lo strumento gratuito di controllo del dominio sul sito legge in pochi secondi i record SPF, DKIM e DMARC pubblicati, insieme ai record MX e alla presenza nelle principali liste di segnalazione. Conviene usarlo all'inizio, per sapere da dove si parte, e dopo ogni cambio di politica, per verificare che il record sia scritto correttamente. Un errore di sintassi, o due record DMARC sullo stesso dominio, rendono la politica inefficace.
Un dominio portato a reject protegge la posta che l'azienda non può permettersi di perdere. L'apertura di nuovi mercati non dovrebbe viaggiare su quello stesso dominio: nei progetti che seguiamo gira su un'infrastruttura dedicata gestita da UNEEK, con domini separati e autenticati, e il dominio principale resta fuori dal rischio.
La soluzione
Il recapito si costruisce prima di scrivere il primo messaggio. L'assessment strategico include il controllo dell'infrastruttura di invio, a partire dai record del dominio.