DMARC per Office 365: Configurazione e migliori pratiche passo dopo passo

⚠️Aggiornamento importante (maggio 2025): Microsoft applica ora il protocollo DMARC ai mittenti che inviano grandi volumi di messaggi. Se invii più di 5.000 e-mail al giorno a utenti di Outlook, Hotmail o Live senza DMARC, i tuoi messaggi potrebbero essere respinti con l'errore 550 5.7.515.

Microsoft sostiene e incoraggia l'implementazione di DMARC per gli utenti di Microsoft 365 (noto anche come Office 365 o M365), consentendo loro di adottare protocolli di autenticazione delle e-mail in modo uniforme su tutti i domini registrati. In questo blog, illustriamo la procedura per configurare DMARC per Office 365 al fine di convalidare tutte le e-mail di Office 365 che presentano:

• Indirizzi di routing e-mail online con Microsoft
• Domini personalizzati aggiunti nel centro di amministrazione
• Domini parcheggiati o inattivi, ma registrati

Che cos'è DMARC e perché è importante per Microsoft 365

DMARC è un protocollo di autenticazione delle e-mail che protegge i domini dallo spoofing e dal phishing. (Domain-based Message Authentication, Reporting, and Conformance) opera integrandosi con SPF e DKIM, allineando i risultati dell'autenticazione alle politiche del dominio e indicando ai server destinatari come gestire i messaggi che non superano tali controlli.

In un ambiente Microsoft 365, DMARC svolge una duplice funzione. Da un lato protegge il tuo dominio dall'usurpazione da parte di malintenzionati e, dall'altro, contribuisce a garantire che i destinatari esterni considerino affidabili le tue e-mail legittime.

Microsoft 365 gestisce il DMARC al posto tuo?

Uno degli errori più comuni tra gli amministratori è pensare che Microsoft 365 gestisca il DMARC al posto loro.

Microsoft 365 esegue effettivamente la convalida DMARC, ma solo per le e-mail in arrivo. Exchange Online Protection (EOP) verifica automaticamente i record SPF, DKIM e DMARC sui messaggi ricevuti dalla tua organizzazione. Ciò significa che i tuoi utenti sono protetti, in una certa misura, dalle e-mail contraffatte.

Tuttavia, per quanto riguarda le e-mail in uscita, Microsoft non interviene a meno che non si effettui una configurazione specifica. Se si desidera proteggere il proprio dominio e soddisfare i moderni requisiti di conformità, è necessario pubblicare un record DMARC nel proprio DNS.

Questa distinzione è fondamentale. Microsoft protegge la tua casella di posta, ma DMARC tutela la reputazione del tuo dominio: ecco perché Microsoft 365 necessita di DMARC anche se è già in uso EOP. La configurazione che stai per implementare riguarda la protezione dei messaggi in uscita.

Prerequisiti: configurare SPF e DKIM per Microsoft 365

Prima di pubblicare un record DMARC, è necessario assicurarsi che sia SPF che DKIM siano configurati correttamente per il proprio dominio. DMARC non autentica le e-mail autonomamente, ma si basa interamente sui risultati di SPF e/o DKIM. Se questi sono mancanti o non allineati, DMARC non funzionerà correttamente e le e-mail legittime potrebbero subire ripercussioni una volta attivata l'applicazione delle regole.

Passaggio 1: Configurare SPF per Microsoft 365

L'SPF (Sender Policy Framework) definisce quali server di posta sono autorizzati a inviare e-mail per conto del tuo dominio. In un ambiente Microsoft 365, ciò include in genere i server di posta di Microsoft e qualsiasi servizio di terze parti che utilizzi.

Configurazione manuale dell'SPF (metodo DNS)

Per configurare manualmente l'SPF:

1. Accedi al tuo provider di hosting DNS (ad es. GoDaddy, Cloudflare, ecc.)
2. Crea o aggiorna un record TXT per il tuo dominio principale

Utilizza il seguente record SPF standard di Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Se utilizzi servizi aggiuntivi (come Mailchimp o Salesforce), devi includere anche quelli. Ad esempio:

v=spf1 include:spf.protection.outlook.com include:_spf.mailchimp.com -all

💡Suggerimento: evita di inserire più record SPF; per ogni dominio deve esserci un solo record TXT SPF. Se si utilizzano più servizi, questi devono essere raggruppati in un unico record.

Configurazione automatica dell'SPF (tramite PowerDMARC)

La creazione manuale dei record SPF può rivelarsi complessa, soprattutto quando sono coinvolti più servizi. Errori quali il superamento dei limiti di ricerca DNS o configurazioni errate sono frequenti.

L'utilizzo degli strumenti SPF di PowerDMARC semplifica questa procedura. Il generatore SPF crea automaticamente un record valido in base alle tue fonti di invio.

Passaggio 2: Abilitare DKIM per Microsoft 365

Il protocollo DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica alle tue e-mail. Ciò consente ai server di ricezione di verificare che il messaggio non sia stato alterato e che provenga effettivamente dal tuo dominio.

A differenza di SPF, DKIM in Microsoft 365 richiede sia la configurazione DNS sia l'attivazione nel Centro di amministrazione.

Configurazione manuale di DKIM (DNS + Centro di amministrazione)

Per abilitare DKIM manualmente:

1. Vai al portale di Microsoft 365 Defender
2. Vai su Posta elettronica e collaborazione → Criteri e regole → Criteri relativi alle minacce → DKIM
3. Scegli il tuo dominio

Fonte immagine

Prima di poter abilitare DKIM, Microsoft ti chiederà di aggiungere due record CNAME al tuo DNS.

In genere hanno questo aspetto:

selector1._domainkey.tuodominio.com → selector1-tuodominio-com._domainkey.tuodominio.onmicrosoft.com

selector2._domainkey.tuodominio.com → selector2-tuodominio-com._domainkey.tuodominio.onmicrosoft.com

Dopo aver pubblicato questi record, torna al portale di amministrazione e clicca su «Abilita» per DKIM. Una volta attivato, Microsoft inizierà a firmare tutte le e-mail in uscita con DKIM.

Configurazione automatica di DKIM (tramite PowerDMARC)

La configurazione di DKIM può risultare complessa, soprattutto per gli amministratori che non hanno familiarità con i record CNAME e i formati dei selettori.

PowerDMARC semplifica questa operazione generando automaticamente i record DKIM corretti per il tuo dominio, offrendo la pubblicazione automatica tramite DNS per eliminare gli errori di inserimento manuale e mettendo a disposizione uno strumento di verifica DKIM per assicurarti che il protocollo sia abilitato correttamente

Come configurare DMARC per Office 365?

Una volta configurati correttamente SPF e DKIM, è possibile passare alla configurazione di DMARC. In Microsoft 365, questa procedura viene eseguita a livello di DNS, ma per eseguirla correttamente è necessario comprendere il proprio ecosistema di posta elettronica, scegliere la politica adeguata e monitorare i risultati prima di procedere all'applicazione.

Fase 1: Identificare tutte le fonti di invio delle e-mail

Prima di pubblicare un record DMARC, è necessario avere un quadro completo di chi invia e-mail per conto del proprio dominio. Si tratta di uno dei passaggi più importanti, poiché tralasciare un mittente legittimo può causare in seguito problemi di consegna.

Le fonti di invio includono solitamente:

• Microsoft 365 (Exchange Online)
• Piattaforme di marketing (Mailchimp, HubSpot, ecc.)
• Sistemi CRM (Salesforce)
• Strumenti di assistenza (Zendesk, Freshdesk)
• Applicazioni o server interni

Se uno qualsiasi di questi elementi non viene autenticato correttamente tramite SPF o DKIM, non supererà il controllo DMARC una volta attivata l'applicazione delle regole.

💡Suggerimento: se non sei sicuro di tutte le fonti, inizia con una politica di monitoraggio (p=none) e utilizza i rapporti DMARC per individuare i mittenti sconosciuti prima di applicare politiche più rigorose.

Passaggio 2: Crea il tuo record DMARC

Un record DMARC è un record TXT pubblicato nel proprio DNS. Definisce la politica adottata e indica ai server destinatari come gestire le e-mail che non superano l'autenticazione. È possibile creare un record DMARC di Office 365 unico per il proprio dominio utilizzando lo strumento di generazione istantanea di record DMARC di PowerDMARC.

Un record DMARC di base ha questo aspetto: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Analizziamo la questione:

v=DMARC1 – Specifica la versione DMARC
p=none – Modalità di monitoraggio (nessuna applicazione)
rua=mailto:[email protected] – Indirizzo a cui vengono inviati i rapporti aggregati
fo=1 – Abilita la segnalazione degli errori

Questo è il punto di partenza consigliato perché consente di raccogliere dati senza compromettere la consegna delle e-mail.

Passaggio 3: Pubblica il record DMARC nel DNS

Una volta che il tuo record è pronto, devi aggiungerlo al tuo DNS.

Utilizza le seguenti impostazioni:

Tipo di record: TXT
Host/Nome: _dmarc
Valore: Il tuo record DMARC
TTL: 1 ora (o valore predefinito)

📝Nota: dopo la pubblicazione, potrebbero essere necessari alcuni minuti o alcune ore prima che il record venga diffuso a livello globale.

💡Suggerimento: dopo la pubblicazione, controlla sempre il tuo record utilizzando uno strumento di verifica DMARC per assicurarti che non ci siano errori di sintassi.

Fase 4: Monitorare i rapporti DMARC

Dopo aver abilitato DMARC con una politica p=none, inizierai a ricevere rapporti dai server destinatari. Questi rapporti consentono di verificare chi invia e-mail utilizzando il tuo dominio, quali messaggi superano o falliscono l'autenticazione e lo stato di allineamento per SPF e DKIM.

I rapporti DMARC vengono solitamente inviati in formato XML e possono risultare difficili da interpretare manualmente. Senza un'analisi adeguata, è facile trascurare eventuali errori di configurazione o mittenti non autorizzati.

💡Suggerimento: utilizza uno strumento di analisi dei report DMARC per trasformare i report grezzi in informazioni chiari e comprensibili. In questo modo sarà più facile individuare i problemi e procedere in tutta sicurezza verso l'applicazione delle misure.

Fase 5: Passare gradualmente all'applicazione delle misure

Una volta esaminati i rapporti e verificato che tutti i mittenti legittimi siano correttamente autenticati, potrai iniziare a rendere più rigorosa la tua politica DMARC.

Una sequenza tipica si presenta così:

Inizia con il monitoraggio: v=DMARC1; p=none; rua=mailto:[email protected]

↓

Spostare in quarantena (le e-mail sospette vengono inviate nella cartella spam): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Infine, applicare il rifiuto: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

💡Suggerimento: non affrettarti a rifiutare. L'applicazione prematura delle regole è una delle cause principali del blocco delle e-mail legittime.

Passaggio 6: Configurare DMARC per diversi tipi di dominio

L'approccio può variare a seconda del dominio che stai configurando.

Passaggio 7: Verifica e gestisci la configurazione DMARC di Microsoft 365

DMARC non è una configurazione che si imposta una volta per tutte. Man mano che il vostro ecosistema di posta elettronica cambia, anche la configurazione deve evolversi. Anche dopo aver raggiunto il valore p=reject, è fondamentale un monitoraggio costante per garantire la deliverability e la sicurezza.

Dovresti fare regolarmente:

• Controlla i rapporti DMARC
• Aggiornare l'SPF quando si aggiungono nuovi mittenti
• Assicurarsi che DKIM rimanga abilitato e configurato correttamente
• Monitorare le attività non autorizzate

Implementazione della politica DMARC: perché è importante un'applicazione graduale

Passare direttamente a una politica di rifiuto è uno degli errori più comuni nell'implementazione del DMARC. Senza una visione chiara dei flussi di posta elettronica, l'applicazione di tale politica può compromettere le comunicazioni legittime.

Un'implementazione graduale consente di monitorare e risolvere eventuali problemi prima di applicare criteri rigorosi. La maggior parte delle organizzazioni segue un percorso che va dal monitoraggio alla quarantena e infine al rifiuto. La durata di ciascuna fase dipende dalla complessità del proprio ambiente di posta elettronica, ma saltare dei passaggi aumenta il rischio di errori di consegna involontari.

Come Exchange Online gestisce i messaggi DMARC in entrata

Exchange Online Protection valuta automaticamente il DMARC su tutti i messaggi in entrata e, a partire da luglio 2023, Microsoft rispetta per impostazione predefinita la politica pubblicata dal mittente. Quando il record MX del dominio del destinatario punta direttamente a Microsoft 365, i messaggi che non superano il controllo DMARC in base a una politica p=reject vengono respinti al gateway. Allo stesso modo, i messaggi che non superano il controllo DMARC con una politica p=quarantine vengono inviati in quarantena. Ciò è controllato dall'impostazione "Rispetta la politica del record DMARC quando il messaggio viene rilevato come spoof"nella politica anti-phishing, che è abilitata per impostazione predefinita.

Fonte immagine

Spiegazione del comportamento "oreject"

Prima del luglio 2023, Microsoft applicava un'impostazione interna denominata action=oreject (rifiuto all'origine) ai messaggi in entrata che non soddisfacevano la politica p=reject del mittente. Anziché respingere immediatamente il messaggio al gateway, EOP lo indirizzava alla cartella della posta indesiderata del destinatario e contrassegnava l'intestazione con l'azione oreject.

Microsoft ha agito in questo modo deliberatamente, poiché le e-mail inoltrate e il traffico delle mailing list spesso violano i protocolli SPF e DKIM durante il transito. Ciò significa che un messaggio legittimo che supera l'autenticazione presso il mittente originale può fallire tale autenticazione nel momento in cui viene ricevuto da un destinatario secondario. Un rifiuto categorico con impostazione p=reject avrebbe comportato l'eliminazione di un volume significativo di posta legittima insieme ai messaggi contraffatti. La cartella della posta indesiderata rappresentava un compromesso: i destinatari potevano comunque recuperare l'e-mail se necessario e la politica del mittente veniva tecnicamente rispettata.

Il compromesso era che i messaggi contraffatti, che avrebbero dovuto essere respinti, continuavano ad arrivare nelle caselle di posta degli utenti (nella cartella della posta indesiderata), dove un destinatario distratto avrebbe potuto aprirli. Per i team di sicurezza, ciò significava che l'applicazione del DMARC non risultava mai così rigorosa come suggeriva la politica.

Quando vedrai ancora "oreject" oggi

Poiché l'impostazione predefinita è cambiata, EOP ora considera "p=reject" come un vero e proprio rifiuto per i flussi Direct-MX. Tuttavia, il comportamento precedente non è scomparso del tutto. Si continuerà a vedere "oreject" in tre casi:

1. L'opzione «Honor DMARC» è disattivata nella tua politica anti-phishing.

Per risolvere il problema: controlla l'impostazione in Microsoft 365 Defender → Posta elettronica e collaborazione → Criteri di protezione → Anti-phishing → Impostazioni di spoofing. L'opzione è attivata per impostazione predefinita, ma nei tenant che sono stati migrati da configurazioni precedenti potrebbe essere disattivata.

2. La posta passa attraverso un gateway di terze parti prima di raggiungere Microsoft 365.

Se il tuo server MX punta a un dispositivo di sicurezza (Proofpoint, Mimecast, ecc.) che a sua volta inoltra i messaggi a EOP, Microsoft non può rivalutare il DMARC a meno che tu non abiliti il «Filtraggio avanzato per i connettori» nel portale di Defender. In assenza di tale impostazione, EOP si affida al verdetto del gateway a monte e, per impostazione predefinita, rifiuta i messaggi non conformi.

3. Una regola di autorizzazione a livello di utente sta aggirando il filtro.

I mittenti presenti nella lista bianca, i connettori in entrata attendibili o le regole di trasporto che assegnano un livello di affidabilità antispam (SCL -1) non saranno soggetti all'applicazione delle regole DMARC e il messaggio arriverà nella posta in arrivo indipendentemente dalla politica applicata.

Per un controllo più rigoroso, attiva la funzione "Spoof Intelligence" nel portale Defender insieme all'opzione "Honor DMARC". Spoof Intelligence valuta la reputazione del mittente indipendentemente dal DMARC e mette in quarantena i messaggi che sembrano tentativi di usurpazione d'identità, anche quando l'autenticazione risulta tecnicamente valida.

Rafforzamento dei controlli in entrata attraverso le norme sui trasporti

Per le organizzazioni che desiderano garantire il rifiuto dei messaggi non conformi a DMARC, una regola di trasporto di Exchange Online rappresenta il meccanismo più affidabile.

Come impostare la regola:

1. Vai su Centro di amministrazione di Exchange → Flusso di posta → Regole e crea una nuova regola.
2. Imposta la condizione: un'intestazione del messaggio contiene una di queste parole. Nome dell'intestazione: Authentication-Results. Valore dell'intestazione: dmarc=fail action=oreject.
3. Imposta l'azione: rifiuta il messaggio con la seguente spiegazione: inserisci un testo del tipo «Il messaggio non ha superato l'autenticazione DMARC ed è stato rifiutato in base alla politica aziendale».
4. (Facoltativo) Aggiungere un'eccezione per i mittenti interni affidabili o per i mittenti che inoltrano messaggi legittimi, al fine di evitare falsi positivi.
5. Imposta la modalità della regola su "Prova con suggerimenti sulle politiche" per la prima settimana. Esamina i messaggi corrispondenti nella traccia dei messaggi prima di passare alla modalità "Applica".

Per ulteriori informazioni, è possibile consultare la documentazione approfondita di Microsoft sulle regole di flusso della posta.

Quando utilizzare questo approccio:

Le regole di trasporto sono utili quando le normative o le politiche interne impongono il rifiuto effettivo dei messaggi non validi, quando la vostra organizzazione è un bersaglio privilegiato per gli attacchi di spoofing (settore finanziario, legale, comunicazioni dirigenziali) o quando si desidera garantire un comportamento coerente tra i flussi diretti MX e quelli dei gateway di terze parti.

L'applicazione del protocollo DMARC da parte di Microsoft a maggio 2025: cosa è cambiato

Nel maggio 2025, Microsoft ha introdotto un cambiamento significativo nella gestione delle e-mail non autenticate provenienti da mittenti esterni. Questa modifica riguarda principalmente i mittenti che inviano grandi volumi di messaggi, ma ha implicazioni più ampie per tutte le organizzazioni.

In linea di massima, i requisiti di Microsoft relativi ai mittenti di posta elettronica sono in linea con la tendenza generale del settore verso un’autenticazione più rigorosa e una maggiore responsabilità dei mittenti. L’aggiornamento introduce soglie chiare, misure coercitive e aspettative che in precedenza venivano applicate in modo meno rigoroso.

Principali modifiche introdotte da Microsoft

• Obbligo di DMARC per i mittenti di posta in massa: i domini che inviano più di 5.000 e-mail al giorno ai servizi consumer di Microsoft devono ora disporre di un record DMARC valido.
• Vale per Outlook.com, Hotmail.com e Live.com: l'applicazione delle norme riguarda specificatamente l'ecosistema delle caselle di posta elettronica consumer di Microsoft, non solo i tenant aziendali.
• Requisito minimo: DMARC con p=none: è accettabile anche una politica di monitoraggio, ma l'assenza di un record DMARC non è più tollerata su larga scala.
• Maggiore attenzione all'allineamento dei domini: l'autenticazione da sola non è sufficiente; affinché DMARC venga superato, SPF e DKIM devono corrispondere al dominio visibile nel campo "Da".
• Rifiuto definitivo per mancata conformità: le e-mail che non soddisfano i requisiti potrebbero essere bloccate con il messaggio: 550 5.7.515 Accesso negato, il dominio mittente [SendingDomain] non soddisfa il livello di autenticazione richiesto.

Con questa modifica, Microsoft si allinea a Google e Yahoo, che hanno introdotto requisiti simili nel febbraio 2024; ciò significa che i tre principali fornitori di caselle di posta elettronica impongono ora tutti l'autenticazione per i mittenti di messaggi in massa.

Piattaforme come PowerDMARC colmano questa lacuna offrendo programmi di conformità dedicati, pensati per soddisfare i requisiti dei provider di caselle di posta elettronica su tutte le vostre fonti di invio.

Perché Microsoft 365 da solo non basta

Sebbene Microsoft 365 garantisca un'efficace protezione in entrata, offre funzionalità limitate per la gestione e il monitoraggio di DMARC su larga scala – funzionalità che invece sono fornite dalle piattaforme dedicate all'autenticazione delle e-mail.

Mancanza di report leggibili dall'utente

Sebbene Microsoft invii ora i rapporti DMARC agli utenti aziendali, non esiste un sistema integrato che consenta di aggregare e interpretare tali rapporti in modo significativo. Questi rapporti vengono inviati in formato XML e possono risultare difficili da analizzare senza strumenti specializzati. Di conseguenza, le organizzazioni spesso non hanno una visione chiara di chi invia e-mail per loro conto e se tali mittenti siano correttamente autenticati.

Assenza di linee guida applicative

Microsoft non fornisce indicazioni automatizzate per passare dalla fase di monitoraggio a quella di applicazione delle regole. Ciò costringe gli amministratori a interpretare manualmente i dati e a prendere decisioni che possono influire sulla consegna delle e-mail.

Non adatto alla gestione continuativa

Una soluzione DMARC dedicata trasforma i report grezzi in informazioni utili. Consente un monitoraggio continuo, semplifica la gestione delle politiche e aiuta le organizzazioni a procedere in modo sicuro verso la piena applicazione delle misure, su una scala che Microsoft 365 non offre di serie.

Risoluzione dei problemi comuni relativi al DMARC in Office 365

1. Nessun record DMARC pubblicato

Questo è il problema più comune. Il messaggio «Nessun record DMARC pubblicato» significa, in sostanza, che nel DNS del tuo dominio manca il record TXT DMARC, quindi i destinatari non dispongono di alcuna politica su cui basarsi.

Per risolvere il problema, innanzitutto

• Verificalo utilizzando uno strumento di controllo DMARC.
• Se lo strumento restituisce un errore del tipo «Record DMARC mancante», la soluzione consiste nel pubblicare un record che inizi con v=DMARC1; p=none; rua=mailto:[email protected], in modo da poter iniziare a raccogliere i rapporti prima di inasprire la politica.
• Una volta che ti senti a tuo agio con la configurazione, puoi passare gradualmente all'applicazione delle regole, monitorando nel contempo i tuoi report.

2. L'inoltro compromette l'integrità di SPF e DKIM

L'inoltro delle e-mail è la principale causa di messaggi legittimi ma non recapitabili. Quando un intermediario (una mailing list, un servizio di inoltro o un dispositivo di sicurezza) modifica un'intestazione inclusa nella firma DKIM, la firma non viene più verificata e il controllo DKIM fallisce. Di solito anche l'autenticazione SPF fallisce contemporaneamente, poiché l'IP del server di inoltro non è presente nel tuo record.

Ecco tre possibili procedure consigliate per risolvere il problema:

• È preferibile utilizzare la firma DKIM all'origine, poiché il DKIM resiste meglio all'inoltro rispetto all'SPF quando le intestazioni non vengono riscritte
• Evita di utilizzare lo Scheme di Riscrittura del Mittente (SRS) come soluzione, poiché, pur correggendo l'SPF, non ripristina l'allineamento del dominio "Da", quindi il DMARC continua a dare esito negativo
• Configura i sigillatori ARC (Authenticated Received Chain) attendibili in Microsoft Defender per qualsiasi servizio di inoltro che modifichi legittimamente la tua posta. Microsoft accetterà il risultato dell'autenticazione a monte tramite la catena ARC, anziché respingere immediatamente il messaggio.

3. Errore permanente SPF dovuto a un numero eccessivo di ricerche DNS

Se l'SPF smette improvvisamente di funzionare per tutte le fonti legittime e restituisce un errore permanente, la causa è solitamente di natura strutturale piuttosto che legata alla configurazione.

Ci potrebbero essere due possibili cause:

• Il primo è che hai superato il limite di 10 ricerche imposto dall'SPF sui meccanismi include, a, mx, redirect, exists e ptr. Anche le ricerche annidate all'interno degli include dei fornitori vengono conteggiate, quindi un record che a prima vista sembra corretto potrebbe in realtà arrivare a 12 o 13. Quando si supera questo limite, ogni destinatario restituisce un errore permanente (permerror) e l'allineamento DMARC basato sull'SPF crolla immediatamente per l'intero dominio.

Cosa fare: inizia verificando il tuo record tramite uno strumento di ricerca SPF ed eliminando i provider che non utilizzi più. Tuttavia, questa è solo una soluzione temporanea. Una soluzione a lungo termine consiste nell'utilizzare una soluzione SPF in hosting come PowerSPF, dotata di ottimizzazione delle macro SPF per la gestione dinamica della ricerca SPF.

• La seconda causa, se si riscontrano errori "temperror" specificamente nei confronti di destinazioni Microsoft, potrebbe essere rappresentata dai timeout del DNS. Se i timeout si verificano su un dominio specifico, è quello il provider da eliminare o rimuovere dall'elenco.

4. Le politiche "p=reject" non vengono rispettate

Da luglio 2023, Microsoft applica per impostazione predefinita il principio "p=reject", ovvero un messaggio non valido dovrebbe essere immediatamente respinto. Se ciò non avviene, è perché si verifica una delle quattro seguenti situazioni:

• L'applicazione delle regole DMARC potrebbe essere disattivata nella tua politica anti-phishing: assicurati che l'opzione "Applica le regole del record DMARC quando il messaggio viene rilevato come contraffatto" sia abilitata e che l'azione per p=reject sia impostata su Rifiuta (non Metti in quarantena).
• Un gateway di terze parti è posizionato a monte di Microsoft 365: se il tuo record MX punta a un gateway di sicurezza di terze parti, Microsoft non applicherà il DMARC a meno che tu non abiliti il "Filtraggio avanzato per i connettori".
• L'autenticazione composita ha prevalso sul risultato: Microsoft integra i segnali di reputazione nel DMARC. Un messaggio può non superare il controllo DMARC ed essere comunque recapitato se compauth=pass
  (Per ulteriori informazioni su questo argomento, consultare la community di formazione di Microsoft).
• Una regola di autorizzazione dell'inquilino bypassa il filtro: un mittente presente nell'elenco delle autorizzazioni, un connettore in entrata attendibile o una regola che assegna un livello di affidabilità dello spam ( SCL) pari a 1 non saranno soggetti all'applicazione delle regole DMARC.

Passare a DMARC su Microsoft 365

Il DMARC su Microsoft 365 presenta un duplice problema. Exchange Online Protection gestisce automaticamente la convalida dei messaggi in entrata, ma la protezione dei messaggi in uscita è interamente a carico dell'utente. Le modifiche alle regole di applicazione previste per maggio 2025 rendono tale responsabilità urgente per chiunque invii grandi volumi di messaggi.

Il metodo più sicuro è quello graduale: imposta inizialmente p=none, monitora i tuoi report per due o quattro settimane, risolvi i problemi relativi ai mittenti che emergono, poi passa a p=quarantine e infine a p=reject. Saltare dei passaggi è la causa principale per cui la posta legittima smette di funzionare durante l'implementazione.

Una volta attivata l'applicazione delle regole, il lavoro passa dalla configurazione al monitoraggio. Vengono aggiunti nuovi mittenti e i fornitori terzi modificano la propria infrastruttura: tutti fattori che possono compromettere silenziosamente l'allineamento se nessuno tiene d'occhio i report. È qui che una piattaforma DMARC dedicata dimostra il proprio valore. Gli strumenti di reportistica e analisi di PowerDMARC trasformano i dati XML grezzi in informazioni chiari e segnalano gli scostamenti prima che si trasformino in un problema di deliverability.

Inizia controllando il tuo attuale record DMARC per capire qual è la tua situazione attuale.

Domande frequenti

Microsoft 365 configura automaticamente il DMARC?

Microsoft verifica la validità del DMARC per le e-mail in entrata, ma non lo configura per il tuo dominio personalizzato. Devi pubblicare manualmente il record TXT DMARC in uscita.

Microsoft richiede l'uso di DMARC?

Sì, Microsoft richiede l'adozione del protocollo DMARC ai mittenti con volumi elevati. Inoltre, se ne raccomanda vivamente l'adozione a tutte le organizzazioni per garantire la recapitabilità e la protezione.

Che cos'è l'errore 550 5.7.515?

Questo errore indica che le tue e-mail vengono respinte a causa di criteri DMARC mancanti o non conformi alle regole di applicazione di Microsoft.

Perché le e-mail continuano ad essere recapitate con il flag "p=reject"?

Microsoft ha storicamente applicato un'impostazione interna denominata «oreject» (origin reject), che reindirizza i messaggi non conformi al DMARC alla cartella «Posta indesiderata» anziché respingerli immediatamente al gateway. Questa funzione è stata concepita per proteggere i mittenti legittimi da una perdita accidentale, ma rende i messaggi contraffatti visibili ai destinatari.

Due cose da sapere:

1) A seguito delle modifiche alle norme di applicazione entrate in vigore nel maggio 2025, Microsoft sta adottando un approccio più rigoroso, che prevede il vero e proprio rifiuto dei messaggi inviati da mittenti che generano volumi elevati.

2) Se desideri garantire il rifiuto dei messaggi all'interno del tuo tenant Microsoft 365, crea una regola di trasporto di Exchange che rifiuti categoricamente i messaggi.

È meglio scegliere "quarantena" o "rifiuta"?

Inizia con il monitoraggio (p=nessuno) per tenere sotto controllo le tue fonti di invio e i canali e-mail, poi passa alla quarantena e ricorri al rifiuto solo quando sei certo che tutte le fonti legittime siano state identificate.

"`

• Informazioni su
• Ultimi messaggi

Yunes Tarada

Esperto di sicurezza dei domini e delle e-mail presso PowerDMARC

Yunes è un Operations Team Lead di PowerDMARC, esperto di autenticazione e sicurezza delle e-mail. Yunes è un Azure Administrator Associate certificato da Microsoft con certificazioni in CompTIA A+ e molte altre.

Ultimi messaggi di Yunes Tarada (vedi tutti)

• DMARCbis: cosa cambia e come prepararsi - 16 aprile 2026
• Il formato del numero di serie SOA non è valido: cause e soluzioni - 13 aprile 2026
• Come inviare email sicure su Gmail: guida passo passo - 7 aprile 2026