Come configurare correttamente DMARC in Office 365

Da febbraio 2024, i requisiti di Gmail per l'invio massivo di email hanno imposto un record DMARC pubblicato per ogni dominio che invia email. email 5,000 al giorno agli utenti Gmail. Yahoo applica la stessa regola in base al loro migliori pratiche per il mittente. Come di che si terrà nel maggio 2025Microsoft ha iniziato a rifiutare la posta non conforme proveniente da mittenti con volumi elevati di messaggi indirizzati a Outlook, Hotmail e Live.

DMARC è passato da opzionale a obbligatorio per qualsiasi tenant di Microsoft 365 che opera su larga scala e attualmente statistiche sullo spam via e-mail Bisogna chiarire il motivo: i provider stanno inasprendo le regole di autenticazione perché la posta non autenticata crea rischi sia per i mittenti che per i destinatari.

Ecco perché è importante imparare a configurare correttamente DMARC in Office 365, dalla verifica dei prerequisiti e dalla creazione del record alla sua pubblicazione nel DNS, dalla scelta di una policy di avvio sicura alla verifica del suo funzionamento, fino al passaggio alla piena applicazione senza bloccare la posta legittima.

Prerequisiti per la configurazione di DMARC in Office 365

DMARC non è un protocollo autonomo. È un livello di policy sopra SPF e DKIM Questo indica ai server di posta riceventi cosa fare quando questi controlli falliscono. Se SPF o DKIM sono configurati in modo errato o non allineati, l'applicazione di DMARC inizierà ad agire in base a tale disallineamento nel momento in cui si passa da p=none.

Prima di pubblicare il record DMARC, verifica tutti e quattro i prerequisiti elencati di seguito:

• Test SPF pubblicato e superato: Per i tenant di Microsoft 365, il record SPF deve includere include:spf.protection.outlook.com più eventuali mittenti di terze parti aggiuntivi (SendGrid, Mailchimp, HubSpot, ecc.) che inviano email per conto del tuo dominio.
• Firma DKIM abilitata per ogni dominio personalizzato: Microsoft 365 non abilita automaticamente DKIM per i domini personalizzati. Apri il portale di Microsoft Defender, vai alla pagina DKIM in Posta elettronica e collaborazione → Criteri e regole → Criteri di minaccia e verifica che la firma sia attivata per il dominio personalizzato.
• Accesso come amministratore globale o amministratore della sicurezza al tenant di Microsoft 365 per eventuali passaggi di verifica all'interno del portale Defender.
• Accesso DNS per il dominio personalizzato pubblicare il record DMARC TXT all'indirizzo _dmarc.yourdomain.com nel pannello di controllo del proprio provider DNS.

Come configurare DMARC in Office 365: procedura passo passo

I cinque passaggi seguenti richiedono dai 10 ai 15 minuti di lavoro attivo, più il tempo di propagazione DNS (da pochi minuti a 48 ore, a seconda del provider DNS e delle impostazioni TTL).

La configurazione DMARC avviene interamente nel DNS, non nel portale di Microsoft Defender. Microsoft 365 gestisce automaticamente i controlli DMARC in entrata tramite Exchange Online Protection, ma non esiste un'impostazione nel portale di Defender per configurare il DMARC in uscita sul dominio personalizzato. Tale record si trova nella zona DNS.

Passaggio 1: Verificare che SPF e DKIM funzionino correttamente.

Invia un'email di prova dal tuo dominio personalizzato a un indirizzo Gmail o Yahoo esterno. Apri l'email e visualizza tutte le intestazioni del messaggio (in Gmail: menu con i tre puntini → "Mostra originale").

Nell'intestazione Authentication-Results, verificare quanto segue:

• spf=pass — SPF è autorizzato e superato
• dkim=pass — DKIM sta firmando correttamente e la firma è verificata

Se uno dei due restituisce un risultato negativo o neutro, fermati qui e risolvi prima il problema di autenticazione. La pubblicazione di un record DMARC su un SPF o DKIM non funzionante causerà la quarantena o il rifiuto di email legittime non appena modificherai la policy oltre p=none.

Fase 2: Decidere la politica DMARC iniziale

Iniziate impostando p=none per ogni nuova implementazione DMARC. Questa policy raccoglie i report aggregati DMARC senza influire sulla consegna delle email. I messaggi non autenticati vengono comunque recapitati, ma i server di posta riceventi inviano i risultati dell'autenticazione all'indirizzo specificato nel tag rua=. Questi dati indicano quali fonti di invio sono allineate e quali no prima che inizi l'applicazione delle policy.

Passare direttamente a p=quarantine o p=reject è la causa più comune di perdita di email legittime durante l'implementazione di DMARC. Se una piattaforma di invio di terze parti non è ancora allineata, una policy rigorosa metterà in quarantena o rifiuterà immediatamente le email legittime provenienti da quella fonte. La fase p=none esiste proprio per evitare questo.

Passaggio 3: Creazione del record DMARC

Il record DMARC di base per una nuova distribuzione ha questo aspetto:

v=DMARC1; p=nessuno; rua=mailto:[email protected]; pct=100;

Ecco cosa significa ogni tag:

• v=DMARC1 — la versione del protocollo. Obbligatoria come primo tag in ogni record DMARC.
• p = none — la politica applicata ai messaggi che non superano l'allineamento DMARC. Si inizia con nessuna impostazione, poi si passa alla quarantena e al rifiuto man mano che l'allineamento si stabilizza.
• rua=mailto:indirizzo — la casella di posta in cui vengono inviati i report aggregati. Utilizzare una casella di posta dedicata come [email protected]oppure, se preferisci una visualizzazione tramite dashboard, puoi instradare i report a un analizzatore DMARC di terze parti.
• pct=100 — la percentuale di messaggi non validi a cui si applica la policy. Impostala a 100 fin dall'inizio. Le implementazioni graduali in termini di percentuale sono raramente necessarie nelle moderne implementazioni DMARC e aggiungono complessità non necessaria.

Per il riferimento completo dei tag, inclusi i tag opzionali come ruf (report forensi), sp (policy di sottodominio), adkim e aspf, vedere Italiano:documentazione ufficiale del protocollo.

Passaggio 4: Pubblicare il record DMARC nel DNS

Accedi al pannello di controllo del tuo provider DNS. Crea un nuovo record TXT con i seguenti valori:

• Nome dell'ospite: _dmarc (alcuni provider richiedono _dmarc.yourdomain.com; inserisci esattamente ciò che è richiesto dall'interfaccia utente DNS)
• Valore/Contenuto: il record DMARC completo creato nel passaggio 3, esattamente come scritto
• TTL: 3600 (un'ora) è lo standard; i valori inferiori si propagano più rapidamente durante i test

Salva il record. La propagazione DNS in genere si completa entro poche ore, ma può richiedere fino a 48 ore. Durante questo periodo, il record potrebbe non essere sempre visibile da tutti i resolver.

Passaggio 5: Verificare che il record DMARC sia attivo

Una volta che il record si è propagato, verificatelo in due modi:

• Ricerca DNS: Accedi allo strumento di ricerca DMARC di MXToolbox, inserisci il tuo dominio e verifica che il record venga analizzato correttamente e risulti valido. Se la ricerca fallisce o restituisce un errore, controlla la formattazione del record DNS, poiché la causa è solitamente un punto e virgola mancante o un nome host errato.
• Verifica dell'intestazione di autenticazione: Invia un'altra email di prova dal tuo dominio personalizzato a Gmail, Yahoo o a un indirizzo Outlook esterno. Apri le intestazioni complete e verifica che la sezione Authentication-Results ora mostri dmarc=pass per il dominio mittente.

I report aggregati di DMARC iniziano ad arrivare nella casella di posta rua= entro 24-72 ore dalla pubblicazione del record. Esaminate attentamente il primo lotto prima di valutare l'adozione di una policy più restrittiva.

Comprensione delle opzioni della politica DMARC: Nessuna, Quarantena e Rifiuto

Ogni implementazione DMARC di successo si articola in tre fasi, distribuite su settimane o mesi. Saltare le fasi comporta il rischio di rifiutare email legittime prima che tutte le fonti di invio siano correttamente allineate. L'approccio graduale è il modo migliore per proteggere il flusso di posta elettronica e al contempo procedere alla piena applicazione delle policy.

Modalità di monitoraggio: p=nessuno

v=DMARC1; p=nessuno; rua=mailto:[email protected]; pct=100;

Con p=none, i server di posta riceventi raccolgono i risultati DMARC e li inviano al tuo indirizzo rua=, ma i messaggi non validi vengono comunque recapitati normalmente. Nulla viene messo in quarantena o rifiutato.

Rimani in modalità p=none per un minimo di 2-4 settimane. Utilizza questo periodo per leggere i report aggregati e verificare che ogni fonte di invio legittima, come Microsoft 365, piattaforme di marketing, mittenti transazionali e CRM, superi la verifica di conformità DMARC. Qualsiasi fonte che presenti errori deve essere corretta prima che la policy diventi più restrittiva.

Passare a p=quarantena solo quando i report mostrano costantemente tassi di superamento superiori al 95% per tutti i mittenti legittimi su più cicli di segnalazione.

Applicazione blanda: p=quarantena

v=DMARC1; p=quarantena; rua=mailto:[email protected]; pct=100;

Con p=quarantine, i server di posta riceventi instradano i messaggi non recapitabili nella cartella spam o posta indesiderata anziché nella Posta in arrivo. I messaggi legittimi ma non in linea con la cartella di destinazione arrivano comunque a destinazione, ma in una posizione meno visibile, dove è meno probabile che i destinatari li visualizzino.

Questa fase della policy rappresenta un utile punto di controllo intermedio. Impone conseguenze per la posta non allineata correttamente senza i bounce permanenti che si verificano con p=reject. Rimani in questa fase per altre 2-4 settimane e monitora attentamente i report per verificare se della posta legittima viene instradata erroneamente.

Passare a p=reject solo quando i report DMARC confermano un allineamento coerente su tutte le fonti e nessuna email legittima viene messa in quarantena.

Applicazione completa: p=rifiuta

v=DMARC1; p=rifiutare; rua=mailto:[email protected]; pct=100;

Con p=reject, i server di posta riceventi rifiutano direttamente i messaggi che non superano l'allineamento DMARC. I messaggi non conformi vengono restituiti al mittente e non raggiungono affatto il destinatario.

Questo è l'obiettivo di ogni implementazione DMARC. L'applicazione completa di p=reject fornisce una protezione completa contro lo spoofing del dominio e soddisfa i requisiti di Gmail, Yahoo e Microsoft per i mittenti ad alto volume. Protegge anche il tuo reputazione del dominio e dell'indirizzo IP impedendo ai mittenti non autorizzati di utilizzare il tuo nome di dominio per inviare email.

Continuare a monitorare i report DMARC con p=reject. Nuove fonti di invio, inclusi nuovi fornitori, strumenti di marketing e integrazioni, possono ancora causare errori di allineamento e devono essere integrate con l'autenticazione attiva prima di essere rese operative.

Errori comuni di configurazione DMARC in Office 365 e come risolverli

Nella maggior parte dei casi, gli errori DMARC negli ambienti Microsoft 365 sono dovuti a problemi di allineamento, non a errori di protocollo. Ciò significa che il record è tecnicamente valido, ma l'e-mail inviata non è allineata con il dominio di firma DKIM o con gli indirizzi IP autorizzati da SPF.

I report DMARC sono vuoti

Diagnosticare: L'indirizzo della casella di posta rua= non è corretto, la casella di posta sta bloccando i report in arrivo oppure il dominio non sta inviando un volume sufficiente di dati affinché i principali provider abbiano già generato i report.

Fix: Verifica che la casella di posta rua= esista, accetti posta esterna e non sia soggetta a un filtro antispam troppo aggressivo. Invia alcune email di prova dal dominio a indirizzi Gmail e Yahoo; questi provider in genere generano report entro 24-48 ore se DMARC è configurato correttamente.

Le email legittime vengono messe in quarantena o rifiutate.

Diagnosticare: Una piattaforma di invio di terze parti non è allineata. La causa più comune è uno strumento di marketing, un CRM o un provider di email transazionali che non è stato aggiunto a SPF o configurato per firmare con DKIM per il dominio personalizzato.

Fix: Esamina i report aggregati DMARC per identificare la fonte che presenta l'errore. Aggiungi la fonte al tuo record SPF (include:thirdparty.com), configura la firma DKIM per tale fonte tramite le impostazioni della piattaforma oppure torna temporaneamente a p=none finché l'allineamento non viene corretto. Non lasciare mai la policy su p=reject finché fonti note non presentano l'errore.

Errori di allineamento DMARC dopo l'inoltro

Diagnosticare: Le email inoltrate spesso compromettono l'allineamento SPF perché l'indirizzo IP del server di inoltro non è presente nel record SPF del mittente originale. Il DKIM, invece, in genere non subisce l'inoltro, quindi questo scenario si riduce spesso a un caso di allineamento che richiede solo l'intervento del DKIM.

Fix: Assicurarsi che DKIM firmi correttamente per il mittente originale. La posta conforme a DKIM supera il controllo DMARC anche quando SPF fallisce a causa dell'inoltro. Se DKIM continua a fallire anche dopo l'inoltro, significa che il sistema di inoltro sta modificando il contenuto del messaggio e invalidando la firma DKIM. Questa situazione generalmente richiede il supporto di ARC (Authenticated Received Chain) da parte del server di inoltro per essere risolta.

errori di formato del record DMARC

Diagnosticare: Gli errori di battitura nel record DMARC TXT possono invalidare l'intera policy. I problemi più comuni includono la mancanza del prefisso v=DMARC1, la mancanza di punti e virgola tra i tag o la suddivisione errata del record su più voci DNS.

Fix: Esegui la validazione DMARC del record pubblicato tramite il validatore di MXToolbox e verifica che il risultato sia corretto e valido. Controlla che il record esista come singola voce TXT sotto _dmarc.yourdomain.com, non suddiviso in due record, e che ogni tag sia separato da un punto e virgola.

DMARC, se implementato correttamente, protegge il tuo dominio.

Configurare DMARC è più semplice se si seguono i passaggi nell'ordine corretto. Verificate SPF e DKIM, create il record, pubblicatelo nel DNS e procedete con calma attraverso ogni fase della policy, prendendovi il tempo necessario per leggere i report e risolvere eventuali problemi di allineamento prima di intensificare l'applicazione delle policy.

Poiché DMARC rappresenta l'ultimo livello di autenticazione delle email, la sua efficacia dipende innanzitutto dal corretto funzionamento di SPF e DKIM. Se questi record non sono configurati correttamente o non sono allineati, l'applicazione di DMARC potrebbe bloccare email legittime anziché proteggere il dominio dallo spoofing.

L'autenticazione, tuttavia, non risolve tutti i problemi di recapito. Un dominio correttamente autenticato che invia a un elenco pieno di indirizzi non validi, temporanei o inattivi genererà comunque bounce permanenti, e questi bounce influiranno sulla tua reputazione del mittente della posta elettronica indipendentemente da quanto sia pulito il tuo record DMARC.

Prima della tua prossima campagna, carica la tua lista su DeBounce ed esegui un passaggio di convalida completo Convalida dell'elenco e-mailL'autenticazione conferma che l'email proviene da te, mentre la pulizia della lista conferma che è destinata a un destinatario reale. Entrambe sono necessarie per dare a ogni campagna maggiori possibilità di raggiungere la casella di posta.