Compauth=fail su Microsoft 365: capire l'autenticazione composita e correggere i reason code

⚡TL;DR

• compauth è il verdetto di autenticazione composita di Microsoft 365: combina SPF, DKIM, DMARC e segnali interni (reputazione, cronologia, PTR), non è uno standard RFC
• Il campo si scrive compauth=<pass|softpass|fail|none> reason=<codice> nell'header Authentication-Results; il reason indica perché
• compauth=fail non blocca automaticamente un messaggio nel caso generale: Microsoft applica una valutazione olistica (SCL, CAT, SFTY) prima di decidere tra posta in arrivo, posta indesiderata o quarantena. Riserva: dal 2023, un errore DMARC esplicito contro p=reject può essere rifiutato al gateway (NDR 550 5.7.509) quando l'MX punta direttamente a Microsoft 365
• La correzione duratura passa quasi sempre per l'allineamento di SPF + DKIM + DMARC sul dominio del From:
• I codici 604, 605 e 703 citati da alcuni strumenti di terze parti non sono documentati da Microsoft: non basare una diagnosi su di essi

Stai esaminando gli header di un messaggio in Microsoft 365 e ti imbatti in compauth=fail reason=001. La posta proviene da un mittente noto, SPF sembra corretto, eppure il messaggio finisce nella posta indesiderata o in quarantena. Il campo compauth è uno dei più fraintesi di Exchange Online, perché non corrisponde ad alcun protocollo standard: è un meccanismo proprietario di Microsoft.

Questa guida è un riferimento esaustivo. Spiega cos'è l'autenticazione composita, come Microsoft 365 calcola questo verdetto a partire da SPF, DKIM, DMARC e dai segnali interni, la differenza essenziale tra autenticazione implicita ed esplicita, e poi fornisce la tabella completa dei reason code verificata sulla documentazione Microsoft ufficiale. Vi troverai infine un piano di diagnosi e correzione organizzato per famiglia di codici.

Si rivolge agli amministratori Microsoft 365 ed Exchange Online i cui messaggi legittimi vengono contrassegnati come spoofing o messi in quarantena, e ai responsabili della deliverability che devono leggere e interpretare un header di autenticazione Microsoft.

Che cos'è l'autenticazione composita (compauth) di Microsoft 365?

L'autenticazione composita è un verdetto proprietario di Microsoft. A differenza di SPF (RFC 7208), DKIM (RFC 6376) e DMARC (RFC 7489), compauth non è definito da alcuno standard. È un livello di valutazione che Microsoft 365 aggiunge sopra questi tre protocolli per produrre un giudizio complessivo sull'autenticità di un mittente.

In pratica, Exchange Online Protection (EOP) non si limita a inoltrare i risultati di SPF, DKIM e DMARC. Li aggrega con segnali aggiuntivi: la reputazione dell'indirizzo IP mittente, la cronologia dei messaggi già ricevuti da questa infrastruttura, il record PTR (DNS inverso) dell'IP e i modelli comportamentali derivati dall'analisi di massa del traffico Microsoft. Il risultato di questa aggregazione viene inscritto nel campo compauth dell'header Authentication-Results.

L'unità di base della valutazione è il dominio del From: visibile al destinatario, ossia l'indirizzo dell'header 5322.From (chiamato anche dominio P2). È questo il dominio che Microsoft cerca di proteggere dallo spoofing, ed è su di esso che ricadono l'allineamento e il verdetto composito. Questa precisazione non è banale: un messaggio può benissimo superare SPF sul dominio della busta (5321.MailFrom) e al tempo stesso fallire l'autenticazione composita, perché questo dominio della busta non corrisponde al dominio visualizzato nel From:. L'utente finale non vede mai la busta, ma soltanto il From:; è quindi logico che la protezione contro lo spoofing si fondi su questo indirizzo.

Perché Microsoft ha creato questo livello aggiuntivo invece di limitarsi a DMARC? Perché l'adozione di DMARC resta parziale. Una parte importante dei domini legittimi non ha alcuna politica DMARC, oppure pubblica un p=none che non fornisce alcuna istruzione di applicazione. Senza un segnale composito, Microsoft dovrebbe scegliere se fidarsi ciecamente di questi domini (e lasciar passare lo spoofing) oppure penalizzarli sistematicamente (e bloccare posta legittima). L'autenticazione composita è la risposta a questo dilemma: permette di valutare un mittente anche quando i protocolli standard non forniscono un verdetto netto, basandosi su segnali osservabili lato Microsoft.

Il campo appare tipicamente in questa forma in un header:

Authentication-Results: spf=pass (sender IP is 40.107.0.1)
 smtp.mailfrom=captaindns.com; dkim=pass (signature was verified)
 header.d=captaindns.com; dmarc=pass action=none
 header.from=captaindns.com; compauth=pass reason=100

La sintassi generale è compauth=<risultato> reason=<codice>. Il risultato assume uno di quattro valori, e il codice a tre cifre precisa la ragione esatta del verdetto.

compauth=pass / softpass / fail / none: cosa significa ogni valore?

Il risultato composito non si riduce a successo o errore. Microsoft distingue quattro stati, ciascuno con un significato preciso.

Valore	Significato
pass	Il messaggio ha superato l'autenticazione composita, per via esplicita (SPF/DKIM/DMARC allineati) o implicita (segnali interni sufficienti).
softpass	Il messaggio ha superato parzialmente l'autenticazione implicita. I segnali sono positivi ma deboli (allineamento tramite PTR o sottorete, per esempio).
fail	Il messaggio non ha superato l'autenticazione composita, esplicita o implicita. Non è un verdetto di blocco, ma un fattore di rischio.
none	Il messaggio non è stato valutato per l'autenticazione composita, oppure l'ha aggirata (routing particolare, messaggio già elaborato a monte).

La sfumatura tra fail e none è importante. fail segnala un errore attivo di autenticazione: Microsoft ha valutato il messaggio e concluso di non poter garantire l'identità del mittente. none segnala un'assenza di valutazione, spesso dovuta a un routing complesso o a un messaggio che ha già attraversato un altro gateway.

Autenticazione implicita ed esplicita: la chiave per capire compauth

È la distinzione più importante di tutto l'articolo. Microsoft 365 valuta l'autenticazione di un messaggio seguendo due vie, e il reason code indica quale è stata seguita.

L'autenticazione esplicita si basa sui record DNS pubblicati dal dominio mittente: SPF, DKIM e la politica DMARC. È l'autenticazione standard. Se il dominio pubblica un DMARC severo (p=quarantine o p=reject) e il messaggio si allinea correttamente, il verdetto è esplicito.

L'autenticazione implicita è un'estensione propria di Microsoft. Quando un dominio non pubblica DMARC, o pubblica una politica permissiva (p=none, SPF in ~all o ?all), Microsoft non può basarsi su un'intenzione dichiarata. Applica allora i propri segnali per decidere: reputazione IP, cronologia di invio, allineamento tramite PTR, MX del dominio. Questa via permette a un messaggio legittimo senza DMARC di passare (per esempio il reason 109), ma espone anche a un errore implicito (reason 001 o 6xx) quando i segnali sono insufficienti.

Questo meccanismo spiega due situazioni che spesso disorientano gli amministratori. Un messaggio proveniente da un dominio senza alcuna autenticazione può ottenere compauth=pass se il suo IP ha un'ottima reputazione e una cronologia pulita (autenticazione implicita riuscita). Al contrario, un messaggio proveniente da un dominio con un DMARC severo ma mal allineato ottiene compauth=fail reason=000 (autenticazione esplicita fallita), anche se l'IP mittente è peraltro reputato.

La via esplicita ha sempre la priorità. Se il dominio pubblica un DMARC utilizzabile, Microsoft applica la sua politica prima di ricorrere ai segnali impliciti. Per questo pubblicare un DMARC correttamente allineato è la leva di controllo più potente di cui dispone un mittente sul proprio verdetto composito.

Dove trovare compauth=fail nei tuoi header?

Il verdetto composito si legge nell'header Authentication-Results, ma l'analisi completa richiede di incrociare diversi header Microsoft.

L'header Authentication-Results raccoglie i verdetti SPF, DKIM, DMARC e compauth. È il punto di partenza. Ma per capire l'impatto reale di un compauth=fail, occorre leggere anche l'header X-Forefront-Antispam-Report, che contiene i campi decisionali di EOP.

In X-Forefront-Antispam-Report diversi campi sono utili:

Campo	Ruolo
CAT	Categoria del verdetto EOP (SPM per spam, PHSH per phishing, SPOOF per spoofing, BULK, ecc.).
SFV	Verdetto del filtro (per esempio SKS per regola di trasporto, SPM per spam).
SCL	Spam Confidence Level, da -1 a 9. Più il valore è alto, più il messaggio è giudicato indesiderato.
SFTY	Indicatore di sicurezza, in particolare 9.x per i messaggi di tipo spoofing o phishing: 9.19 spoofing di dominio, 9.20 spoofing di utente, 9.25 avviso di sicurezza « primo contatto ».

Ecco un esempio di header reale, commentato, in cui l'autenticazione composita fallisce:

Authentication-Results: spf=none (sender IP is 203.0.113.20)
 smtp.mailfrom=marketing.captaindns.com; dkim=none (message not signed)
 header.d=none; dmarc=none action=none header.from=captaindns.com;
 compauth=fail reason=001
X-Forefront-Antispam-Report: CIP:203.0.113.20; CTRY:US;
 CAT:SPOOF; SFV:SPM; SCL:5; SFTY:9.19

Qui il dominio non pubblica né SPF utilizzabile, né DKIM, né DMARC: l'autenticazione esplicita è impossibile e quella implicita fallisce (reason=001). EOP classifica il messaggio in CAT:SPOOF con un SCL:5 e un indicatore SFTY:9.19, il che lo destina alla posta indesiderata. È l'incrocio tra compauth=fail e questi campi decisionali a determinare la sorte reale del messaggio.

Bisogna ancora sapere dove recuperare questi header. In Outlook sul web, apri il messaggio, poi il menu delle opzioni e « Visualizza dettagli messaggio » per copiare il sorgente grezzo. Nel client Outlook desktop, apri il messaggio nella sua finestra, poi File e Proprietà: il campo « Intestazioni Internet » contiene tutto. Lato amministratore, il tracciamento dei messaggi (message trace) dell'interfaccia di amministrazione di Exchange permette di ritrovare il verdetto EOP di un messaggio recapitato senza nemmeno accedere alla casella del destinatario. Per una diagnosi su larga scala, i rapporti aggregati DMARC (RUA) incrociano le fonti di invio che falliscono e completano utilmente la lettura del singolo header.

Per estrarre e leggere questi header senza errori, copia il sorgente completo del messaggio e analizzalo con un analizzatore dedicato. L'argomento della lettura degli header è trattato nella nostra guida Come leggere gli header di un'email.

La tabella completa dei reason code compauth

Ecco il riferimento centrale di questo articolo. La tabella seguente è verificata sulla documentazione Microsoft ufficiale (pagina « Anti-spam message headers » di Microsoft Learn, aggiornata all'8 ottobre 2025). Ogni riga indica il codice, il risultato composito associato, il significato esatto secondo Microsoft, la causa tipica e la risoluzione.

Codice	compauth	Significato (Microsoft)	Causa tipica	Risoluzione
000	fail	Errore di autenticazione esplicita. DMARC fallisce con una politica p=quarantine o p=reject. Dal 2023, un p=reject onorato per impostazione predefinita può comportare un rifiuto al gateway (NDR 550 5.7.509), non solo una classificazione in Posta indesiderata.	Il dominio pubblica un DMARC severo ma il messaggio non si allinea (SPF/DKIM rompono l'allineamento, spesso durante l'inoltro o da una fonte non autorizzata).	Allineare SPF e DKIM sul From:; autorizzare la fonte di invio; configurare un ARC sealer attendibile in caso di inoltro.
001	fail	Errore di autenticazione implicita. Nessun record di autenticazione pubblicato, oppure politica debole.	Il dominio non ha (o ha poca) autenticazione: SPF in ~all/?all, oppure DMARC in p=none. Microsoft non ha segnali.	Pubblicare SPF + DKIM + DMARC allineati; rafforzare progressivamente verso ~all e poi -all.
002	fail	Una politica del tenant vieta esplicitamente questa coppia mittente/dominio.	Voce inserita manualmente da un amministratore (Tenant Allow/Block List, blocco anti-spoofing).	Verificare e rimuovere la voce di blocco se il mittente è legittimo.
010	fail	DMARC fallisce con p=reject/p=quarantine, e il dominio mittente è un dominio accettato della tua organizzazione.	Spoofing intra-organizzazione: un servizio di terze parti invia « per conto » del tuo stesso dominio senza esservi autorizzato.	Autorizzare la fonte in SPF/DKIM o tramite la Tenant Allow/Block List.
1xx	pass	Il messaggio ha superato l'autenticazione esplicita o implicita.	Successo.	Nessuna azione.
100	pass	SPF ha avuto successo o DKIM ha avuto successo, e MAIL FROM e From sono allineati.	Successo nominale.	Nessuna azione.
101	pass	Il messaggio è firmato in DKIM dal dominio del From:.	Successo DKIM allineato.	Nessuna azione.
102	pass	MAIL FROM e From allineati, e SPF ha avuto successo.	Successo SPF allineato.	Nessuna azione.
103	pass	Il From: è allineato con il PTR (DNS inverso) dell'IP di origine.	Successo tramite PTR.	Nessuna azione.
104	pass	Il PTR dell'IP di origine è allineato con il dominio del From:.	Successo tramite PTR.	Nessuna azione.
108	pass	DKIM è fallito a causa di una modifica del corpo da parte di un hop legittimo precedente.	Tollerato (ambiente on-premises, per esempio).	Monitorare le modifiche in transito; valutare ARC.
109	pass	Nessun DMARC, ma il messaggio supererebbe comunque la valutazione.	Tollerato.	Pubblicare DMARC per formalizzare l'intenzione.
111	pass	Nonostante un temperror o permerror DMARC, SPF o DKIM è allineato con il From:.	Tollerato nonostante un errore DNS.	Correggere il record DMARC.
112	pass	Un timeout DNS ha impedito il recupero del DMARC.	Errore DNS transitorio.	Verificare la risoluzione DNS del dominio.
115	pass	Il messaggio proviene da un'organizzazione Microsoft 365 in cui il From: è un dominio accettato.	Tollerato (Microsoft 365 verso Microsoft 365).	Nessuna azione.
116	pass	L'MX del From: è allineato con il PTR dell'IP di connessione.	Tollerato.	Nessuna azione.
130	pass	Il risultato ARC di un ARC sealer attendibile ha sostituito un errore DMARC.	Inoltro tramite un servizio ARC attendibile.	Configurare ARC sealer attendibili.
2xx	softpass	Il messaggio ha superato parzialmente l'autenticazione implicita.	Segnali parziali.	Rafforzare SPF/DKIM/DMARC.
201	softpass	Il PTR del From: è allineato con la sottorete del PTR dell'IP di connessione.	Allineamento debole (sottorete).	Rafforzare l'autenticazione.
202	softpass	Il From: è allineato con il dominio del PTR dell'IP di connessione.	Allineamento debole (PTR).	Rafforzare l'autenticazione.
3xx	none	Il messaggio non è stato verificato per l'autenticazione composita.	Non valutato.	Nessuna.
4xx	none	Il messaggio ha aggirato l'autenticazione composita.	Aggiramento.	Nessuna.
501	(n.d.)	DMARC non applicato: NDR (rapporto di mancato recapito) valido, contatto stabilito in precedenza.	Tolleranza NDR.	Nessuna azione.
502	(n.d.)	DMARC non applicato: NDR valido per un messaggio inviato da questa organizzazione.	Tolleranza NDR.	Nessuna azione.
6xx	fail	Errore di autenticazione email implicita.	Errore implicito.	Pubblicare e allineare SPF, DKIM, DMARC.
601	fail	Il dominio mittente è un dominio accettato della tua organizzazione (invio a sé stessi / spoofing intra-org).	Applicazione o servizio interno o di terze parti che invia « come te » senza autenticazione.	Autorizzare la fonte (SPF/DKIM, relay autenticato, Tenant Allow/Block List).
7xx	pass	Il messaggio ha superato l'autenticazione implicita.	Successo implicito.	Nessuna azione.
701-704	pass	DMARC non applicato grazie a una cronologia di messaggi legittimi da questa infrastruttura.	Reputazione e cronologia.	Nessuna azione.
9xx	none	Il messaggio ha aggirato l'autenticazione composita.	Aggiramento.	Nessuna.
905	none	DMARC non applicato a causa di un routing complesso (on-premises o servizio di terze parti prima di Microsoft 365).	Routing ibrido.	Configurare ARC o un relay autenticato.

Riquadro accuratezza: i codici 604, 605 e 703

Alcuni strumenti di terze parti (tra cui analizzatori DMARC commerciali) citano i codici 604, 605 e 703 come reason code compauth distinti. Questi codici non compaiono nella documentazione Microsoft ufficiale attuale. Nella famiglia 6xx, Microsoft documenta soltanto il codice 601. Nella famiglia 7xx, la documentazione copre l'intervallo 701-704 senza isolare 703 con un significato proprio. Nessun 604 né 605 è definito.

Non attribuiamo quindi loro alcun significato. Se incontri uno di questi codici, trattalo in base alla sua famiglia: un 6xx è un errore implicito (da correggere come un 601), un 7xx è un successo implicito. Non basare una diagnosi su una definizione non documentata.

Codici di errore: 000, 001, 002, 010 e 6xx/601

Sono i codici che portano un amministratore a leggere questo articolo. Si suddividono in due logiche.

I codici 000 e 010 rientrano nell'errore esplicito: il dominio pubblica un DMARC severo, ma il messaggio non si allinea. Il 010 è il caso particolare in cui il dominio in errore è un dominio accettato della tua stessa organizzazione. Il 000, invece, riguarda qualsiasi dominio esterno con DMARC severo mal allineato.

I codici 001, 6xx e 601 rientrano nell'errore implicito: Microsoft non ha potuto basarsi su una politica dichiarata e i suoi segnali interni non sono bastati. Il 601 è il sottocaso del dominio accettato dell'organizzazione. Il 002, infine, è un caso a parte: non riflette un difetto tecnico ma una decisione dell'amministratore (una voce di blocco manuale).

Codici di successo (1xx, 7xx) e softpass (2xx)

La famiglia 1xx raggruppa i successi, siano essi espliciti (100, 101, 102) o tollerati nonostante una debolezza (108, 109, 111, 112). Il 130 merita un'attenzione particolare: indica che un ARC sealer attendibile ha permesso di recuperare un messaggio che sarebbe fallito in DMARC a causa di un inoltro.

La famiglia 7xx raggruppa i successi impliciti basati sulla reputazione e sulla cronologia. La famiglia 2xx (softpass) segnala un successo debole: l'allineamento si fonda su segnali tenui come il PTR o la sottorete. Un softpass non è un errore, ma è meglio rafforzarlo pubblicando un'autenticazione esplicita.

Codici none / bypass (3xx, 4xx, 9xx, 905) e NDR (501/502)

Le famiglie 3xx, 4xx e 9xx corrispondono a messaggi non valutati o che hanno aggirato l'autenticazione composita. Il 905 è il più istruttivo: segnala un routing complesso (passaggio per un server on-premises o un servizio di terze parti prima di Microsoft 365) che impedisce la normale applicazione del DMARC. La risposta a un 905 è in genere l'implementazione di ARC o di un relay autenticato.

I codici 501 e 502 riguardano gli NDR (rapporti di mancato recapito) legittimi: Microsoft non applica loro DMARC perché rispondono a un contatto stabilito in precedenza.

Diagnosi e risoluzione per famiglia di codici

La tabella offre la visione d'insieme. Questa sezione approfondisce i casi più frequenti e i passaggi concreti da seguire.

reason=000: un DMARC severo rotto dall'allineamento

Il reason=000 significa che il dominio mittente pubblica un DMARC in p=quarantine o p=reject, ma il messaggio non rispetta l'allineamento DMARC. L'allineamento DMARC richiede che SPF o DKIM abbia successo e che il dominio verificato corrisponda al dominio del From:. Da notare: da metà agosto 2023, quando il destinatario punta il suo MX direttamente a Microsoft 365, un reason=000 di fronte a un p=reject non si limita più a degradare il messaggio, ma può comportare un rifiuto a livello di gateway (NDR 550 5.7.509). La correzione non è quindi più in gioco solo per la scelta tra posta in arrivo e Posta indesiderata, ma per il recapito stesso del messaggio.

La causa più frequente è l'inoltro dell'email. Quando un messaggio viene reinoltrato, l'IP mittente cambia (l'IP del server di inoltro sostituisce l'IP di origine), il che rompe l'allineamento SPF. Se DKIM non è presente o se il corpo viene modificato in transito, anche DKIM fallisce, e DMARC fallisce quindi completamente.

La seconda causa è l'invio da una fonte non autorizzata: un fornitore di emailing che non è stato dichiarato nello SPF né configurato per firmare in DKIM con il tuo dominio.

La risoluzione dipende dal caso. Per una fonte di invio legittima, autorizzala: aggiungi il suo meccanismo include: allo SPF e configura la firma DKIM allineata al tuo dominio. Per l'inoltro, l'unica risposta robusta è ARC: il server di inoltro deve apporre una firma ARC, e il destinatario Microsoft 365 deve riconoscere questo sealer come attendibile (il che produce allora un reason=130).

Prendiamo un esempio concreto di inoltro che produce un reason=000. Un messaggio parte da contabilita@captaindns.com, debitamente firmato in DKIM con d=captaindns.com ed emesso da un IP autorizzato dallo SPF del dominio. All'origine tutto è allineato. Il destinatario ha configurato un inoltro automatico verso una casella ospitata su Microsoft 365. Il server di inoltro rispedisce il messaggio dal proprio IP, che non è nello SPF di captaindns.com: SPF fallisce lato Microsoft. Se il server di inoltro ha inoltre aggiunto un avviso « messaggio inoltrato » al corpo, l'hash DKIM non corrisponde più e anche DKIM fallisce. Il From: è rimasto contabilita@captaindns.com con un DMARC severo: DMARC fallisce quindi completamente, e Microsoft inscrive compauth=fail reason=000. Eppure il messaggio è perfettamente legittimo. Solo ARC, preservando i risultati di autenticazione di origine lungo tutta la catena, permette di recuperare questo caso senza ammorbidire la politica del dominio mittente.

reason=001: autenticazione mancante o troppo debole

Il reason=001 è l'errore implicito per eccellenza. Il dominio non fornisce a Microsoft gli elementi per decidere: nessun DMARC utilizzabile, SPF in ~all o ?all, nessun DKIM allineato. Microsoft tenta un'autenticazione implicita, ma i segnali (reputazione IP, cronologia) non bastano per concludere positivamente.

La risoluzione è strutturale. Pubblica i tre pilastri dell'autenticazione email. Uno SPF corretto che dichiari tutte le tue fonti di invio, firme DKIM allineate al tuo dominio e un record DMARC. Inizia DMARC in p=none correttamente allineato per osservare senza bloccare, poi rafforza verso p=quarantine una volta che le tue fonti sono sotto controllo. Lato SPF, fai evolvere il meccanismo finale da ~all a -all quando sei certo della completezza delle tue fonti.

Una sfumatura importante: un dominio in p=none o uno SPF in ~all non è « rotto », è soltanto permissivo. Microsoft interpreta questa permissività come un'assenza di intenzione chiara e passa all'autenticazione implicita. Il reason=001 non è quindi la sanzione di un errore di sintassi, ma la constatazione che il dominio non fornisce a Microsoft gli elementi per concludere positivamente per la via standard. È esattamente per questo che rafforzare le politiche fa scomparire il codice: porti la valutazione dalla via implicita (incerta) alla via esplicita (deterministica).

reason=010 e reason=601: lo spoofing intra-organizzazione

Questi due codici condividono una caratteristica: il dominio mittente è un dominio accettato della tua stessa organizzazione Microsoft 365. In altre parole, un messaggio pretende di provenire dal tuo dominio, ma Microsoft non può confermare che sia stato effettivamente emesso da una fonte autorizzata. Il 010 corrisponde al versante esplicito (DMARC severo in errore), il 601 al versante implicito.

È uno scenario estremamente comune nella pratica: una stampante di rete, un'applicazione aziendale, un CRM, uno strumento di fatturazione o un fornitore marketing invia email « per conto » del tuo dominio senza essere stato dichiarato nello SPF né configurato in DKIM. Microsoft interpreta questo come un potenziale spoofing interno. Questo meccanismo è collegato all'avviso « via » che Microsoft 365 mostra a volte; lo trattiamo nel nostro articolo sullo spoofing intra-organizzazione e l'avviso Microsoft.

La risoluzione consiste nell'autorizzare esplicitamente la fonte legittima. Tre opzioni, in ordine di preferenza: aggiungere la fonte al tuo record SPF e configurarla per firmare in DKIM con il tuo dominio; far transitare i suoi invii attraverso un relay SMTP autenticato del tuo tenant; come ultima risorsa, creare una voce nella Tenant Allow/Block List. Evita di affidarti a lungo termine alla lista di autorizzazione: è una correzione di attesa, non un'autenticazione.

reason=002: un blocco manuale da parte della politica del tenant

Il reason=002 non riflette alcun difetto tecnico. Segnala che un amministratore ha esplicitamente bloccato questa coppia mittente/dominio, in genere tramite la Tenant Allow/Block List o una regola anti-spoofing. Se il mittente è legittimo, la risoluzione è semplice: rimuovere la voce di blocco. Prima di farlo, verifica perché il blocco è stato impostato, in modo da non riaprire una porta chiusa per una buona ragione.

reason=130: un ARC sealer ha legittimamente sostituito l'errore DMARC

Il reason=130 è un successo, non un problema. Indica che un messaggio sarebbe fallito in DMARC (tipicamente a causa di un inoltro), ma che un ARC sealer attendibile ha preservato i risultati di autenticazione di origine, cosa che Microsoft ha accettato. È esattamente il comportamento desiderato per l'inoltro legittimo. Se vedi questo codice, la tua catena ARC funziona. Il funzionamento di ARC è trattato nella nostra guida Che cos'è ARC (Authenticated Received Chain).

Compauth=fail significa che la mia email è bloccata?

No nel caso generale, ma con una riserva importante dal 2023. La documentazione Microsoft resta esplicita sul principio: un compauth=fail non comporta, da solo, un rifiuto né una messa in quarantena automatica. Il verdetto composito è un fattore tra gli altri nella valutazione olistica di EOP. Questo vale in particolare per un errore implicito (reason=001) e per i domini senza DMARC severo: il messaggio viene allora valutato globalmente e finisce spesso nella posta indesiderata, non rifiutato.

La riserva riguarda l'errore esplicito di fronte a una politica DMARC severa. Da metà agosto 2023, quando il dominio destinatario punta il suo MX direttamente a Microsoft 365, Exchange Online Protection onora per impostazione predefinita la politica DMARC pubblicata dal dominio mittente. Un errore DMARC contro p=reject comporta allora un rifiuto a livello di gateway (con un rapporto di mancato recapito, NDR), e p=quarantine una messa in quarantena, al posto del vecchio comportamento che classificava tutto in Posta indesiderata. Questo cambiamento deriva dall'impostazione anti-phishing « Onora la politica DMARC quando un messaggio viene rilevato come spoofing », attiva per impostazione predefinita, con azioni configurabili distinte per p=quarantine e per p=reject. In concreto, un errore esplicito tipo reason=000 contro un p=reject può ora essere rifiutato al gateway, e non più solo classificato in Posta indesiderata. L'NDR restituito assume la forma: 550 5.7.509: Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject.

Una riserva nella riserva: questo rifiuto predefinito si applica quando l'MX del destinatario punta direttamente a Microsoft 365. Se l'MX punta a un gateway di terze parti posto davanti a Microsoft 365, EOP onora la politica DMARC solo se il « filtro avanzato per i connettori » (Enhanced Filtering for Connectors) è attivato, perché deve poter ritrovare l'IP di invio reale dietro il relay.

Dopo aver stabilito il verdetto composito, EOP combina questa informazione con altri segnali per decidere la sorte del messaggio: lo SCL (Spam Confidence Level), la categoria CAT, l'indicatore di sicurezza SFTY, la reputazione dell'IP, il contenuto del messaggio e le politiche anti-spam e anti-phishing configurate nel tenant. Un messaggio può benissimo ottenere compauth=fail e arrivare comunque nella posta in arrivo se gli altri segnali sono rassicuranti.

Al contrario, è quando compauth=fail si combina con una categoria sfavorevole che il messaggio viene degradato. Un CAT:SPOOF accompagnato da un SFTY:9.x orienta il messaggio verso la posta indesiderata o la quarantena, spesso con un banner di avviso di spoofing. È quindi il contesto globale, non il solo compauth, a determinare il recapito.

In concreto, coesistono diversi percorsi decisionali. Un compauth=fail reason=001 proveniente da un IP con buona reputazione, senza contenuto sospetto, può finire nella posta in arrivo con un semplice SCL basso. Lo stesso reason=001 proveniente da un IP nuovo o poco reputato, con link o allegati sospetti, eredita uno SCL elevato e una categoria SPM o PHSH, e finisce nella posta indesiderata. Infine, un compauth=fail con CAT:SPOOF e SFTY:9.19 (spoofing di dominio) attiva la protezione anti-spoofing e può portare direttamente alla quarantena. Lo stesso valore compauth=fail produce dunque tre esiti diversi a seconda dell'ambiente di segnali che lo circonda.

Questa logica ha una conseguenza pratica. Correggere un compauth=fail non si riduce a far scomparire un flag: si tratta di ridurre il rischio globale percepito da Microsoft. Allineare SPF, DKIM e DMARC fa risalire il verdetto composito verso pass, ma migliora anche la reputazione della tua infrastruttura nel tempo, il che agisce sull'insieme dei segnali. Se i tuoi messaggi finiscono nella posta indesiderata nonostante un'autenticazione corretta, la nostra guida Perché le tue email finiscono nello spam copre le altre leve della deliverability.

Piano d'azione consigliato per correggere un compauth=fail

Ecco i passaggi da seguire, dalla diagnosi alla verifica, applicabili qualunque sia il reason code.

Diagnosi e correzione dell'autenticazione composita, dal reason code alla verifica

1. Apri il sorgente completo del messaggio e annota il valore esatto di compauth=fail reason=<codice> nell'header Authentication-Results. Annota anche CAT, SCL e SFTY in X-Forefront-Antispam-Report. Il reason code orienta tutta la diagnosi.

2. Controlla che tutte le tue fonti di invio figurino nel record SPF e che l'allineamento MAIL FROM/From sia rispettato. Tieni d'occhio il numero di query DNS (limite di 10) che provoca un permerror.

3. Assicurati che i tuoi messaggi siano firmati in DKIM e che il dominio di firma (header.d=) corrisponda al dominio del From:. Senza allineamento DKIM, DMARC non può avere successo per questa via.

4. Controlla la presenza e la coerenza del record DMARC. Verifica l'allineamento e la politica (p=). Una politica severa mal allineata provoca un reason=000; una politica assente o in p=none favorisce un reason=001.

5. Se l'errore deriva da un inoltro, implementa ARC. Il server di inoltro deve sigillare il messaggio, e Microsoft 365 deve riconoscere il sealer come attendibile per produrre un reason=130.

6. Per un reason=010 o 601, autorizza la fonte interna: aggiunta allo SPF e firma DKIM allineata, relay SMTP autenticato, o come ultima risorsa Tenant Allow/Block List.

7. Dopo la correzione, invia un messaggio di prova e ispeziona di nuovo l'header. Il verdetto deve risalire verso compauth=pass (reason 100 o 130 a seconda del caso).

Per i passaggi SPF e DKIM, due strumenti accelerano la diagnosi: il verificatore SPF conferma l'allineamento e conta le query DNS, e il verificatore DKIM valida la pubblicazione e la sintassi della tua chiave. Le cause dettagliate di un errore di firma sono trattate nella nostra guida DKIM fail: cause e soluzioni, e gli errori SPF in SPF permerror: diagnosi e risoluzione e SPF: troppe query DNS.

I nuovi requisiti di Microsoft per i mittenti ad alto volume

Il compauth di Exchange Online Protection riguarda la posta ricevuta dalle organizzazioni Microsoft 365. Parallelamente, Microsoft ha alzato l'asticella per la posta in entrata nelle sue caselle consumer Outlook. Questi due meccanismi sono distinti, ma convergono verso lo stesso requisito: autenticare la propria posta.

Dal 5 maggio 2025, ogni mittente di più di 5.000 messaggi al giorno verso caselle consumer @outlook.com, @hotmail.com e @live.com deve pubblicare i tre pilastri SPF, DKIM e DMARC, con una politica DMARC di almeno p=none allineata su SPF o su DKIM. Questa soglia riprende la logica già imposta da Gmail e Yahoo nel febbraio 2024.

Secondo Microsoft, i messaggi non conformi vengono dapprima instradati verso la Posta indesiderata, poi, dopo una fase iniziale di filtraggio, vengono rifiutati (non recapitati). Il rifiuto associato assume la forma: 550 5.7.515 Access denied, sending domain [dominio] does not meet the required authentication level.

Un punto essenziale per evitare ogni confusione con il resto di questo articolo: questi requisiti riguardano le caselle consumer Outlook, Hotmail e Live, e rientrano in un meccanismo distinto dal compauth di Exchange Online Protection lato aziendale Microsoft 365. Gli stessi codici SMTP differiscono: 5.7.515 segnala un difetto di autenticazione lato consumer ad alto volume, mentre 5.7.509 corrisponde a un rifiuto DMARC onorato da EOP lato aziendale (vedi sopra). Non confondere i due.

La buona notizia è che la messa in conformità risolve anche il problema di fondo trattato in questa guida. Pubblicare SPF, DKIM e DMARC allineati per superare questa barriera elimina per costruzione le cause di un reason=001 (errore implicito): la valutazione Microsoft passa allora dalla via implicita (incerta) alla via esplicita (deterministica). La traiettoria è chiara: Microsoft onora DMARC per impostazione predefinita lato EOP nel 2023, poi impone l'autenticazione ai grandi mittenti Outlook nel 2025, sulla scia di Gmail e Yahoo. L'autenticazione email non è più opzionale.

FAQ

Che cos'è l'autenticazione composita (compauth) di Microsoft?

È un verdetto proprietario di Microsoft 365 che aggrega i risultati di SPF, DKIM e DMARC con segnali interni: reputazione dell'IP mittente, cronologia dei messaggi, record PTR e modelli comportamentali. Il risultato viene inscritto nel campo compauth dell'header Authentication-Results. Non è uno standard RFC, ma un livello di valutazione proprio di Exchange Online Protection.

Cosa significa compauth=fail in un header Authentication-Results?

Il verdetto compauth=fail indica che Microsoft 365 non ha potuto confermare l'autenticità del mittente, per via esplicita (SPF/DKIM/DMARC allineati) o implicita (segnali interni). Il reason che segue precisa il perché. Non è un verdetto di blocco in sé, ma un fattore di rischio nella valutazione globale del messaggio.

Un compauth=fail blocca sempre la mia email?

No. Microsoft applica una valutazione olistica: il verdetto composito viene combinato con lo SCL, la categoria CAT, l'indicatore SFTY e la reputazione dell'IP prima di ogni decisione. Un messaggio in compauth=fail può arrivare nella posta in arrivo se gli altri segnali sono favorevoli. Finisce nella posta indesiderata o in quarantena soprattutto quando è accompagnato da un CAT:SPOOF e da un SFTY:9.x.

Cosa significa reason=000?

Il reason=000 è un errore di autenticazione esplicita: il dominio mittente pubblica un DMARC severo (p=quarantine o p=reject), ma il messaggio non rispetta l'allineamento DMARC. La causa più frequente è l'inoltro dell'email, che rompe l'allineamento SPF, oppure un invio da una fonte non dichiarata. La correzione passa per l'allineamento SPF/DKIM o l'implementazione di ARC per l'inoltro.

Cosa significa reason=001?

Il reason=001 è un errore di autenticazione implicita: il dominio non pubblica un'autenticazione utilizzabile (nessun DMARC, SPF in ~all o ?all, nessun DKIM allineato), e i segnali interni di Microsoft non bastano per concludere. La risoluzione consiste nel pubblicare SPF, DKIM e DMARC correttamente allineati, poi nel rafforzare progressivamente le politiche.

Cosa significano reason=010 e reason=601?

I due codici segnalano che il dominio mittente è un dominio accettato della tua stessa organizzazione: un servizio o un'applicazione invia « per conto » del tuo dominio senza esservi autorizzato. Il 010 è il versante esplicito (DMARC severo in errore), il 601 il versante implicito. La risoluzione consiste nell'autorizzare la fonte legittima tramite SPF/DKIM, un relay autenticato, o la Tenant Allow/Block List.

Che differenza c'è tra compauth=pass, softpass, fail e none?

pass significa che l'autenticazione composita ha avuto successo, esplicitamente o implicitamente. softpass è un successo parziale dell'autenticazione implicita, basato su segnali deboli (PTR, sottorete). fail è un errore di autenticazione, fattore di rischio ma non blocco automatico. none significa che il messaggio non è stato valutato o ha aggirato l'autenticazione composita.

Il compauth fail è diverso da un errore SPF, DKIM o DMARC?

Sì. SPF, DKIM e DMARC sono protocolli standardizzati con verdetti indipendenti. Il compauth è un verdetto composito proprio di Microsoft, che aggrega questi tre risultati con segnali interni. Un messaggio può avere dmarc=fail ma compauth=pass (per esempio tramite un ARC sealer attendibile, reason 130), o il contrario a seconda dei segnali impliciti.

Perché un'email legittima ottiene compauth=fail?

Le cause più frequenti sono l'inoltro dell'email (che rompe l'allineamento SPF e spesso DKIM), una fonte di invio non dichiarata nello SPF, un dominio senza DMARC né DKIM allineato, o un servizio interno che invia per conto del tuo dominio senza autorizzazione. L'autenticità reale del messaggio non è in discussione: è l'incapacità di Microsoft di dimostrarla tecnicamente a produrre l'errore.

Microsoft rifiuta davvero le email in p=reject ora?

Sì, in un caso preciso. Da metà agosto 2023, quando il destinatario punta il suo MX direttamente a Microsoft 365, Exchange Online Protection onora per impostazione predefinita la politica DMARC pubblicata dal mittente. Un errore DMARC contro p=reject provoca allora un rifiuto al gateway (NDR 550 5.7.509), e p=quarantine una messa in quarantena. Per un errore implicito (reason=001) o un dominio senza DMARC severo, il messaggio resta valutato globalmente e finisce il più delle volte in Posta indesiderata, non rifiutato. Se l'MX passa per un gateway di terze parti, questo comportamento presuppone che il « filtro avanzato per i connettori » sia attivato.

Sono interessato dai requisiti per alto volume di Outlook?

Lo sei se invii più di 5.000 messaggi al giorno verso caselle consumer @outlook.com, @hotmail.com o @live.com. Dal 5 maggio 2025, questi invii richiedono SPF, DKIM e DMARC pubblicati, con una politica DMARC di almeno p=none allineata su SPF o DKIM. I messaggi non conformi vengono filtrati verso la Posta indesiderata, poi rifiutati (NDR 550 5.7.515). Questo dispositivo riguarda le caselle consumer e resta distinto dal compauth di Exchange Online Protection lato aziendale Microsoft 365.

I reason code 604, 605 e 703 esistono davvero?

Sono citati da alcuni strumenti di terze parti, ma non sono documentati da Microsoft. La documentazione ufficiale descrive nella famiglia 6xx solo il codice 601, e copre l'intervallo 701-704 senza isolare 703; nessun 604 né 605 vi figura. Se incontri uno di questi codici, trattalo in base alla sua famiglia (6xx = errore implicito, 7xx = successo implicito) senza basarti su una definizione non documentata.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

• Scarica i reason code (CSV)
• Scarica i reason code (JSON)

📖 Glossario

• Authentication-Results: header (RFC 7001/8601) aggiunto dal server di ricezione, che registra i verdetti SPF, DKIM, DMARC e, in Microsoft, compauth.
• Autenticazione composita (compauth): verdetto proprietario di Microsoft 365 che aggrega SPF, DKIM, DMARC e segnali interni.
• Autenticazione esplicita: valutazione basata sui record DNS pubblicati (SPF, DKIM, politica DMARC).
• Autenticazione implicita: valutazione basata sui segnali interni di Microsoft (reputazione, cronologia, PTR) in assenza di una politica utilizzabile.
• Allineamento: corrispondenza tra il dominio verificato da SPF (5321.MailFrom) o DKIM e il dominio visibile del From: (5322.From).
• Reason code: codice a tre cifre che precisa la ragione del verdetto composito.
• ARC sealer: servizio che appone una firma ARC (RFC 8617) preservando i risultati di autenticazione durante un inoltro.
• SCL / SFTY / CAT: campi decisionali di Exchange Online Protection (livello di spam, indicatore di sicurezza, categoria del verdetto).

Fonti

• Microsoft Learn: Anti-spam message headers in EOP (doc aggiornata all'8 ottobre 2025)
• Microsoft Learn: Email authentication in Microsoft 365
• Microsoft Learn: Use DMARC to validate email
• Microsoft Tech Community: Announcing new DMARC policy handling defaults for enhanced email security (2023)
• Microsoft Tech Community: Strengthening Email Ecosystem: Outlook's new requirements for high-volume senders (2025)
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8617: The Authenticated Received Chain (ARC) Protocol