Guida alla configurazione di DMARC per Office 365 (2026)

Segui questa guida passo passo per configurare DMARC su Office 365. Scopri le modifiche relative alla conformità, i metodi più comuni per la risoluzione dei problemi e perché Microsoft 365 da solo non è sufficiente per garantire la sicurezza della posta elettronica.

Microsoft supporta e incoraggia la configurazione di DMARC per Office 365, noto anche come Microsoft 365 o M365. Ciò consente agli utenti di adottare protocolli di autenticazione delle e-mail in modo uniforme su tutti i propri domini registrati. In qualità di esperti in materia di protocolli di autenticazione, utilizziamo questo blog per illustrare le procedure di configurazione di DMARC per Office 365 al fine di convalidare tutte le e-mail che presentano:

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

Leggi questa guida per comprendere il funzionamento di DMARC per Microsoft 365, i passaggi necessari per configurarlo, come modificare i requisiti di autenticazione e perché strumenti come PowerDMARC sono indispensabili per implementare gradualmente le misure di applicazione.

Risposta rapida

Se vuoi una versione sintetica, ecco la procedura di base per la configurazione del DMARC in Microsoft 365:

1. Configurare l'SPF: aggiungere v=spf1 include:spf.protection.outlook.com -all al proprio DNS
2. Abilita DKIM: vai su Microsoft 365 Defender → Posta elettronica e collaborazione → Criteri e regole → Criteri relativi alle minacce → DKIM → seleziona il dominio → Abilita (richiede due record CNAME)
3. Pubblica DMARC: crea un record TXT su _dmarc.tuodominio.com che inizi con v=DMARC1; p=none; rua=mailto:[email protected]
4. Monitorare i rapporti per 2–4 settimane, quindi passare gradualmente a p=quarantena → p=rifiuto

Per una guida più dettagliata da seguire passo dopo passo, leggi questo blog fino alla fine.
Nota: questa procedura rapida funziona solo se tutte le fonti di invio legittime di Microsoft 365 e di terze parti sono correttamente autenticate e allineate. Se utilizzi piattaforme quali CRM, strumenti di automazione del marketing, sistemi di help desk o strumenti di fatturazione, identificale prima di procedere all’applicazione delle regole.

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

DMARC è l'acronimo di Domain-based Message Authentication, Reporting, and Conformance. Si tratta di un protocollo di autenticazione delle e-mail che contribuisce a proteggere i domini da spoofing, phishing e uso non autorizzato.

DMARC si basa su SPF e DKIM. Verifica se un messaggio supera i controlli SPF o DKIM e se il dominio che supera tali controlli corrisponde al dominio visibile nel campo "Da". Successivamente, indica ai server di posta riceventi come gestire i messaggi che non superano l'autenticazione.

Per gli utenti di Microsoft 365, il protocollo DMARC è importante per due motivi:

• Aiuta a impedire agli hacker di spacciarsi per il tuo dominio.
• Migliora la fiducia e la deliverability delle e-mail in uscita legittime.

Exchange Online Protection verifica il DMARC sulla posta in arrivo, ma ciò non protegge automaticamente il proprio dominio dal rischio di spoofing da parte di terzi. Per proteggere l'identità della posta in uscita, è necessario pubblicare i record SPF, DKIM e DMARC relativi al proprio dominio.

Per un riferimento più completo sull'implementazione, consultare la guida DMARC di PowerDMARC.

DMARC 2026: Aggiornamento delle RFC 9989, 9990 e 9991

Nel maggio 2026, DMARC è stato aggiornato tramite tre RFC dell'IETF:

L'RFC 9989 rende obsolete le RFC 7489 e 9091 e porta il DMARC allo status di "Proposed Standard". Per i proprietari dei domini, il cambiamento pratico più importante è il passaggio dall'individuazione dei domini organizzativi basata sulla Public Suffix List al DNS Tree Walk.

I record DMARC esistenti iniziano ancora con:

txt

v=DMARC1

Quindi la maggior parte degli amministratori di Microsoft 365 non necessità di ricostruire immediatamente i propri record DNS. Tuttavia, è opportuno verificare:

• sp= comportamento della politica dei sottodomini
• Qualsiasi struttura complessa di sottodomini delegati
• Domini e sottodomini che inviano e-mail tramite Microsoft 365 o piattaforme di terze parti
• Domini inattivi e che non generano traffico che dovrebbero essere bloccati

Se la vostra organizzazione utilizza una gerarchia di domini complessa, pubblicate record DMARC espliciti per ogni dominio e sottodominio che invia e-mail. Ciò riduce l’ambiguità man mano che i destinatari passano dalla vecchia elaborazione DMARC al comportamento previsto dalla RFC 9989.

Per ulteriori dettagli, consulta la guida di PowerDMARC relativa ai aggiornamento degli RFC 9989, 9990 e 9991 relativi a DMARC.

Microsoft 365 gestisce il DMARC al posto tuo?

Microsoft 365 esegue la convalida DMARC per le e-mail in entrata, ma non configura completamente la protezione del dominio in uscita per il tuo dominio personalizzato.

Exchange Online Protection valuta automaticamente i campi SPF, DKIM e DMARC dei messaggi ricevuti dalla tua organizzazione. Ciò contribuisce a proteggere gli utenti dalla posta in arrivo contraffatta.

Per le email in uscita, la responsabilità è diversa. È necessario configurare l'SPF, abilitare il DKIM e pubblicare un record DMARC nel DNS per ogni dominio mittente.

Il modo più semplice per comprendere questa distinzione è il seguente: Microsoft protegge la tua casella di posta di Microsoft 365, mentre DMARC protegge l'identità del tuo dominio nell'ecosistema della posta elettronica in generale.

Se si fa affidamento esclusivamente sui controlli nativi di Microsoft 365, potrebbero comunque mancare:

• Report DMARC leggibili dall'utente
• Visibilità sui mittenti di terze parti
• Linee guida per il passaggio da "p=none" all'applicazione delle norme
• Monitoraggio centralizzato su tutti i domini
• Gestione del limite di consultazioni SPF
• Avvisi in caso di disallineamento dei provider o dei record DNS

Per un'analisi dettagliata, consultare perché gli utenti di Microsoft 365 hanno ancora bisogno di DMARC.

Prerequisiti: configurare SPF e DKIM per Microsoft 365

Prima di pubblicare un record DMARC, assicurati che sia SPF che DKIM siano configurati correttamente per il tuo dominio. DMARC non autentica le e-mail autonomamente, ma si basa interamente sui risultati di SPF e/o DKIM. Se questi sono assenti o non allineati, DMARC non funzionerà correttamente e le e-mail legittime potrebbero risentirne una volta abilitata 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 proprio dominio.

Per un dominio dedicato esclusivamente a Microsoft 365, il record SPF standard è:

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

Se utilizzi mittenti di terze parti, includili nello stesso record SPF:

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

Importante: Per ogni dominio può esistere un solo record TXT SPF. La presenza di più record SPF causa un errore SPF PermError e può compromettere l'autenticazione.

SPF prevede inoltre un limite massimo di 10 ricerche DNS. Il superamento di tale limite provoca un errore SPF PermError, che DMARC interpreta come un fallimento. Se si utilizzano più servizi SaaS, utilizzare il servizio SPF ospitato di PowerSPF con macro per rimanere sempre al di sotto del limite senza dover modificare manualmente i record DNS. Puoi anche verificare il proprio record SPF attuale oppure utilizzare questo generatore SPF gratuitamente.

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.

⚠️  DKIM in Microsoft 365 non è abilitato per impostazione predefinita per i domini personalizzati. È necessario abilitarlo esplicitamente nel Centro di amministrazione.

Configurazione manuale di DKIM: DNS + Centro di amministrazione

1. Vai al portale di Microsoft 365 Defender
2. Accedi a Posta elettronica e collaborazione → Politiche e regole → Politiche sulle minacce → Impostazioni di autenticazione della posta elettronica → DKIM
3. Seleziona il tuo dominio.

Prima di poterlo abilitare, Microsoft ti chiederà di aggiungere due record CNAME:

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. Dopo aver pubblicato questi record CNAME, torna al portale Defender e attiva l'opzione "Abilita" per DKIM

Una volta attivato, Microsoft inizia a firmare tutte le e-mail in uscita con DKIM. Verifica la tua configurazione utilizzando il strumento gratuito di verifica DKIM.

Come configurare DMARC per Office 365

Una volta configurati SPF e DKIM, è possibile pubblicare DMARC. Per la maggior parte dei domini personalizzati, la procedura di configurazione di DMARC in Microsoft 365 avviene nel DNS, non all’interno del Centro di amministrazione di Microsoft 365.

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. Tralasciare un mittente legittimo può causare errori di consegna una volta attivata l'applicazione delle regole.

Tra le fonti di invio più comuni di Microsoft 365 figurano:

• Microsoft 365 (Exchange Online)
• Piattaforme di marketing (Mailchimp, HubSpot, Klaviyo)
• Sistemi CRM (Salesforce, HubSpot CRM)
• Strumenti di assistenza (Zendesk, Freshdesk, Intercom)
• Applicazioni interne o server di posta in locale
• Gateway di posta elettronica o dispositivi di sicurezza di terze parti

È proprio qui che molti progetti di implementazione di DMARC falliscono. Un dominio può sembrare “esclusivamente Microsoft 365”, ma fatture, newsletter, reimpostazioni delle password, aggiornamenti sui ticket e notifiche delle risorse umane spesso provengono da fonti esterne a Microsoft 365.

Se non sei sicuro di quali sistemi effettuino invii per tuo conto, inizia con p=none e utilizza i report aggregati DMARC per individuarli.

Passaggio 2: Crea il tuo record DMARC

Un record DMARC è un record TXT pubblicato nel proprio DNS all'indirizzo _dmarc.tuodominio.com. Utilizza il Generatore di record DMARC per creare in pochi secondi un record valido e privo di errori.

Un record iniziale consigliato si presenta così:

v=DMARC1; p=none; rua=mailto:[email protected];

Analizziamo la questione:

• v=DMARC1 — specifica la versione di DMARC
• p=none — modalità di monitoraggio (nessuna applicazione delle regole; solo raccolta dati)
• rua=mailto:… — dove vengono inviati i rapporti aggregati (RUA)

Passaggio 3: Pubblica il record DMARC nel DNS

Aggiungi il seguente record TXT presso il tuo provider di hosting DNS:

Nota: dopo la pubblicazione, potrebbe essere necessario un po’ di tempo (in genere da pochi minuti a qualche ora) prima che il record venga diffuso a livello globale.

Dopo la pubblicazione, verifica il tuo record utilizzando uno strumento di controllo DMARC per assicurarti che non vi siano errori di sintassi e che il record venga risolto correttamente.

Fase 4: Monitorare i rapporti DMARC

Dopo aver abilitato DMARC con una politica p=none, inizierai a ricevere rapporti aggregati DMARC (RUA) dai server destinatari. Questi rapporti forniscono informazioni su: chi sta inviando e-mail utilizzando il tuo dominio, quali messaggi superano o falliscono l’autenticazione e lo stato di allineamento per SPF e DKIM.

I report DMARC vengono forniti in formato XML grezzo, difficile da interpretare senza strumenti appositi. L'analizzatore di report di PowerDMARC li converte in dashboard di facile comprensione, consentendoti di identificare i problemi e procedere in tutta sicurezza verso l’applicazione delle misure di sicurezza.

Fase 5: Passare gradualmente all'applicazione delle misure

Una volta verificato che tutti i mittenti legittimi siano correttamente autenticati, rendi più rigorosa la tua politica DMARC in più fasi:

Fase 1 — Monitoraggio (p=nessuno):

v=DMARC1; p=none; rua=mailto:[email protected]

Fase 2 — Quarantena (le e-mail sospette vengono spostate nella cartella dello spam):

v=DMARC1; p=quarantena; rua=mailto:[email protected]; pct=25; t=y

Fase 3 — Applicazione (rifiuto della posta non autenticata):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Suggerimento: non affrettatevi a rifiutare. L'applicazione prematura delle regole è la causa più comune del blocco delle e-mail legittime durante la fase di implementazione.

Passaggio 6: Configurare DMARC per diversi tipi di dominio

L'approccio da adottare varia a seconda del dominio che si sta 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 correggere 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, e saltare dei passaggi non fa che aumentare 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. 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. Analogamente, i messaggi che non superano il controllo DMARC in base a una politica p=quarantine vengono inviati in quarantena. Ciò è gestito dalla politica "Rispetta la politica del record DMARC quando il messaggio viene rilevato come spoof» nella politica anti-phishing, abilitata per impostazione predefinita.

Per una guida dettagliata alla configurazione di questa impostazione e di tutte le opzioni correlate, consulta la guida di PowerDMARC su politica anti-phishing di Office 365.

Fonte: Microsoft

Spiegazione del comportamento "oreject"

In precedenza, Microsoft applicava un’override interna denominata action=oreject (origin reject) ai messaggi in entrata che non soddisfacevano la politica p=reject del mittente. Anziché respingere immediatamente il messaggio al gateway, EOP lo reindirizzava alla cartella della posta indesiderata del destinatario e contrassegnava l’intestazione con l’azione oreject.

Microsoft ha agito in questo modo deliberatamente; le e-mail inoltrate e il traffico delle mailing list spesso violano i protocolli SPF e DKIM durante il transito, e un rifiuto categorico con p=reject avrebbe comportato lo scarto di volumi significativi di posta legittima. La cartella "Posta indesiderata" rappresentava un compromesso: i destinatari potevano recuperare i messaggi se necessario e la politica del mittente veniva tecnicamente rispettata.

Quando vedrai ancora "oreject" oggi

Da quando l'impostazione predefinita è cambiata, EOP ora considera "p=reject" come un vero e proprio rifiuto per i flussi MX diretti. 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: controlla in Microsoft 365 Defender → Posta elettronica e collaborazione → Politiche sulle minacce → Anti-phishing → Impostazioni di spoofing
2. La posta passa attraverso un gateway di terze parti (Proofpoint, Mimecast) prima di raggiungere Microsoft 365: abilitare il “Filtraggio avanzato per i connettori” nel portale Defender
3. Una regola di autorizzazione a livello di destinatario aggira il filtro: i mittenti presenti nella lista bianca, i connettori in entrata attendibili o le regole con SCL pari a -1 ignorano completamente l'applicazione del DMARC

Comprendere compauth e l'autenticazione composita

Microsoft integra i segnali di reputazione ai risultati DMARC tramite un sistema denominato “autenticazione composita” (compauth). Ciò significa che un messaggio può tecnicamente non superare il controllo DMARC ma essere comunque consegnato se i segnali di reputazione di Microsoft indicano che il mittente è legittimo (compauth=pass). Al contrario, un messaggio può superare il controllo DMARC ed essere comunque filtrato come spam se compauth fallisce. Quando si risolvono i problemi di consegna DMARC in M365, controllare sempre l’intestazione Authentication-Results per il codice reason=. Consultare questa guida completa al fallimento di compauth e all’autenticazione composita per ulteriori informazioni.

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:

1. Vai a Centro di amministrazione di Exchange → Flusso di posta → Regole → Crea una nuova regola
2. Condizione impostata: l'intestazione di un messaggio contiene una qualsiasi di queste parole. Nome dell'intestazione: Authentication-Results. Valore dell'intestazione: dmarc=fail action=oreject
3. Azione impostata: Rifiutare il messaggio con la spiegazione “Il messaggio non ha superato l’autenticazione DMARC ed è stato rifiutato in base alla politica aziendale”

1. (Facoltativo) Aggiungere un'eccezione per i mittenti interni affidabili o per i mittenti che inoltrano messaggi legittimi e noti
2. Imposta la modalità delle regole su “Test senza criteri” o “Test con suggerimenti sui criteri”, se disponibile, per la prima settimana; esamina i messaggi corrispondenti nella traccia dei messaggi prima di passare alla modalità “Applica”

Utilizza questo approccio quando le normative o le politiche interne richiedono il rifiuto effettivo dei messaggi non validi, quando la tua organizzazione è un bersaglio di spoofing di alto valore (comunicazioni finanziarie, legali o dirigenziali) oppure quando desideri 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 e-mail, ma ha implicazioni più ampie per tutte le organizzazioni.

Confronto tra le politiche di applicazione dei provider di caselle di posta

Requisiti chiave introdotti da Microsoft

• DMARC obbligatorio 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 disporre di un record DMARC valido
• Si applica all'ecosistema di caselle di posta elettronica per utenti privati di Microsoft: Outlook.com, Hotmail.com e Live.com
• 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
• Grande enfasi sull'allineamento dei domini: l'autenticazione da sola non è sufficiente, SPF e DKIM devono corrispondere al dominio visibile nel campo "Da"
• Rifiuto definitivo per mancata conformità: 550 5.7.515 Accesso negato, il dominio mittente non soddisfa il livello di autenticazione richiesto

Questa modifica allinea Microsoft ad Apple, Google e Yahoo, il che significa che i principali provider di caselle di posta elettronica ora applicano tutti l’autenticazione per i mittenti di messaggi di massa. Vedi i requisiti DMARC di Microsoft per Outlook per una checklist completa sulla conformità.

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.

Assenza di report leggibili dall'uomo

Microsoft ora invia rapporti DMARC per gli utenti aziendali quando il record MX punta direttamente a Office 365. Tuttavia, questi file XML grezzi sono difficili da interpretare senza strumenti specializzati. Senza un'analisi adeguata, le organizzazioni non hanno visibilità su chi invia e-mail per loro conto e se tali fonti siano correttamente autenticate.

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 non si limita a trasformare i report grezzi in informazioni utili. Consente infatti un monitoraggio continuo, semplifica la gestione delle politiche e aiuta le organizzazioni a progredire in sicurezza verso la piena applicazione delle norme, su una scala che Microsoft 365 semplicemente non è in grado di offrire.

Risoluzione dei problemi comuni relativi al DMARC in Office 365

Puoi anche far parte di comunità di formazione di Microsoft per rimanere aggiornato su Office 365 e sui requisiti relativi al protocollo di autenticazione.

Passare a DMARC su Microsoft 365

Il DMARC su Microsoft 365 rappresenta un problema a doppio taglio. 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 posta, mentre la pubblicazione di DMARCbis a maggio 2026 segnala che il settore della posta elettronica sta considerando DMARC come un'infrastruttura permanente e formale.

Il percorso più sicuro è più lento ma efficace: imposta p=none, monitora i tuoi report per due o quattro settimane, correggi i mittenti che emergono, poi passa a p=quarantine e infine a p=reject. Saltare questi passaggi è il motivo per cui la posta aziendale legittima smette di funzionare durante l’implementazione.

Una volta raggiunta la fase di applicazione, 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. Date priorità alla sicurezza delle e-mail verificando il vostro attuale record DMARC per capire a che punto siete oggi.

Per una panoramica completa di tutti i tag, le politiche e le opzioni di implementazione DMARC, consultare la guida DMARC.

Domande frequenti

Microsoft 365 configura automaticamente il DMARC?

Microsoft verifica la validità di 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. La protezione del dominio richiede che tu pubblichi autonomamente i record SPF, DKIM e DMARC nel DNS.

Microsoft richiede l'uso di DMARC?

Sì. Microsoft ha reso obbligatorio l'uso di DMARC (almeno con p=none) per i domini che inviano più di 5.000 e-mail al giorno a Outlook.com, Hotmail.com e Live.com a partire dal 2025. I mittenti non conformi vengono respinti a livello di server, senza raggiungere alcuna casella di posta in arrivo. Microsoft raccomanda inoltre vivamente a tutti i mittenti di implementare DMARC, indipendentemente dal volume di invio.

Che cos'è l'errore 550 5.7.515?

Questo errore di Microsoft 365 indica che le tue e-mail vengono respinte perché il tuo dominio di invio non soddisfa i requisiti di autenticazione. Per risolvere il problema, devi pubblicare un record DMARC valido (almeno p=none) e assicurarti che sia SPF che DKIM siano configurati e allineati con il tuo dominio "Da".

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

Esistono quattro motivi comuni: (1) l’opzione “Honor DMARC” è disabilitata nella politica anti-phishing; (2) un gateway di terze parti è posizionato a monte di Microsoft 365; (3) il “Filtraggio avanzato per i connettori” non è abilitato; (4) l’autenticazione composita di Microsoft (compauth) sta sovrascrivendo il risultato di errore DMARC; (5) una regola di autorizzazione del tenant sta aggirando completamente il filtraggio. Sebbene Microsoft abbia adottato un approccio più rigoroso di vero rifiuto per i mittenti con volumi elevati, queste sovrascritture rimangono attive in ambienti configurati in modo errato.

È meglio scegliere "quarantena" o "rifiuta"?

Inizia con il monitoraggio (p=nessuno) per comprendere le tue fonti di invio, poi passa alla quarantena e ricorri al rifiuto solo quando sei certo che tutte le fonti legittime siano state identificate. Passare direttamente al rifiuto senza prima effettuare il monitoraggio è la causa principale della perdita di email legittime durante l’implementazione di DMARC.

Cosa comporta l'introduzione di DMARCbis per gli amministratori di Microsoft 365?

DMARCbis (RFC 9989, pubblicato nel maggio 2026) eleva ufficialmente DMARC allo status di standard proposto. Per la maggior parte degli amministratori di M365 non sono necessarie modifiche immediate al DNS; i record DMARC esistenti rimangono validi. La modifica principale da tenere presente è l’approccio «DNS Tree Walk» per l’identificazione dei domini organizzativi, che sostituisce la Public Suffix List. Verificate il vostro tag sp= (subdomain policy) per assicurarvi che sia ancora applicato correttamente secondo la nuova logica.

Il protocollo DMARC si applica ai domini onmicrosoft.com?

Sì. Il dominio onmicrosoft.com (MOERA) viene spesso trascurato, ma gli autori degli attacchi lo utilizzano attivamente per lo spoofing. Microsoft configura automaticamente l'SPF per i domini MOERA, ma DKIM e DMARC devono essere configurati manualmente. Si raccomanda di applicare una politica rigorosa (p=reject) su questi domini, poiché in genere non vengono utilizzati per l'invio legittimo di posta in uscita.

Il DMARC è obbligatorio ai fini della conformità allo standard PCI DSS?

A partire dal 31 marzo 2025, la sezione 5.4.1 dello standard PCI DSS v4.0 ha reso obbligatori per tutte le organizzazioni che trattano dati relativi alle carte di pagamento i controlli anti-phishing, inclusi DMARC, SPF e DKIM. Tutte le valutazioni del 2026 saranno condotte in base allo standard PCI DSS v4.0.1 senza alcun periodo di tolleranza. Se la vostra organizzazione elabora pagamenti con carta e utilizza Microsoft 365, DMARC è un requisito di conformità inderogabile.

• Informazioni su
• Ultimi messaggi

Yunes Tarada

Esperto di sicurezza dei domini e della posta elettronica 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)

• Appiattimento SPF: che cos’è e a cosa serve? - 28 luglio 2026
• Guida alla configurazione di DMARC per Office 365 (2026) - 21 luglio 2026
• Come risolvere gli errori “Firma DKIM non valida” e “Hash del corpo del messaggio non verificato” - 16 luglio 2026