Defaults.Exposed › Correzioni › Guides

Outlook rifiuta le Sue email: 550 5.7.515, 550 5.7.509 e compauth=fail, spiegati e risolti (2026)

Pubblicato 2026-07-08

Cifre aggiornate al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Veda come assegniamo i voti.

Due sistemi Microsoft diversi rifiutano la posta. Outlook.com consumer respinge i mittenti ad alto volume che falliscono l’autenticazione (550 5.7.515, applicato da maggio 2025); Exchange Online respinge la posta che fallisce la Sua stessa policy DMARC reject (550 5.7.509). Su 10.205.070 domini che autorizzano spf.protection.outlook.com, il 85,0% ha SPF rigoroso ma solo il 21,7% applica DMARC, secondo il censimento Defaults.Exposed di 261.086.232 domini.

La maggior parte dei problemi “Outlook rifiuta le mie email” non sono affatto rifiuti — è posta che finisce silenziosamente nella Posta indesiderata con compauth=fail nelle intestazioni. Questa guida decodifica i codici Microsoft, Le mostra come leggere l’intestazione Authentication-Results, e percorre la soluzione in ordine: confermare SPF, abilitare DKIM per il dominio personalizzato, pubblicare e applicare DMARC, ritestare.

Quale errore Microsoft ha davvero?

Microsoft gestisce due superfici di ricezione separate, che rifiutano per motivi diversi. Individui prima il Suo sintomo — la diagnosi sbagliata fa perdere una giornata.

La formulazione esatta degli NDR cambia; verifichi le stringhe che cita rispetto a un bounce reale prima di farci affidamento.

Cosa significa 550 5.7.515?

È il requisito di Outlook.com/Hotmail consumer, non un errore di tenant Microsoft 365. Da maggio 2025, chi invia più di 5.000 messaggi al giorno a indirizzi Outlook consumer deve superare SPF, superare DKIM e pubblicare un record DMARC (almeno p=none) allineato con il dominio From. Se non raggiunge quella soglia, Outlook consumer rifiuta con una formulazione come:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Due cose che questo non è: non è un obbligo del 2026 (se la Sua posta ha iniziato a rimbalzare adesso, è cambiato il Suo volume o il Suo DNS, non la regola), e non riguarda le impostazioni del tenant M365 del destinatario. La soluzione è la scala di autenticazione qui sotto — e contano anche le giornate di campagna occasionali che superano i 5.000/giorno.

Cosa significa 550 5.7.509?

Questo arriva da Exchange Online Protection sui tenant aziendali, e significa che la Sua stessa policy DMARC viene rispettata:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Lo legga con attenzione — non è Microsoft che fa la difficile. Il Suo dominio pubblica p=reject, questo messaggio ha fallito DMARC, e il ricevente ha fatto esattamente ciò che Lei ha chiesto. Se la posta respinta è legittima, qualche sorgente di invio (uno strumento di newsletter, un CRM, un dispositivo scan-to-email) non è autenticata in modo allineato. Non indebolisca la policy; dia a quella sorgente SPF o DKIM allineato — veda correggere DMARC e da p=none a p=reject.

Perché Outlook cestina la mia posta con compauth=fail invece di respingerla?

La maggior parte dei problemi di deliverability su Microsoft non produce mai un bounce. Il messaggio viene accettato, valutato e archiviato nella Posta indesiderata — l’unica prova è l’intestazione Authentication-Results. Nella casella del destinatario (o nella Sua casella di test outlook.com), apra il messaggio, scelga Visualizza origine messaggio e trovi la riga:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth è il verdetto di autenticazione composita di Microsoft: anche quando un dominio non pubblica alcun record DMARC, Microsoft applica controlli impliciti simili a DMARC. Valori osservati comunemente:

• compauth=fail reason=000 — il messaggio ha fallito l’autenticazione esplicita: la policy DMARC del Suo dominio è quarantine/reject e il messaggio l’ha fallita.
• compauth=fail reason=001 — il messaggio ha fallito l’autenticazione implicita: il Suo dominio non pubblica record di autenticazione (o non a sufficienza), e il messaggio non sembrava provenire da Lei. La classica firma del “non abbiamo mai configurato DKIM/DMARC”.
• compauth=fail reason=6xx — varianti di fallimento dell’autenticazione implicita; 601 significa specificamente che il dominio mittente è uno dei domini accettati della Sua stessa organizzazione (spoofing intra-organizzazione, da sé a sé).

La lezione: su Microsoft, legga l’intestazione, non solo l’NDR. I verdetti spf=, dkim= e dmarc= su quella stessa riga Le dicono esattamente quale gamba correggere.

Come si risolvono i rifiuti e i cestinamenti di Outlook?

1. Esegua prima la scansione gratuita. Valuta SPF, DKIM e DMARC in un solo passaggio e mostra quale gamba sta fallendo prima di toccare il DNS.
2. Confermi SPF — di solito già a posto su Microsoft 365. Il record standard è v=spf1 include:spf.protection.outlook.com -all, e la configurazione di M365 lo mette lì: il 85,0% dei 10.205.070 domini che autorizzano spf.protection.outlook.com termina già con un rigoroso -all (dati al 2026-06-29). Un’avvertenza: i server riceventi valutano SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’intestazione From — quindi uno strumento di newsletter può superare SPF sul suo dominio di bounce senza fare nulla per il Suo. Ecco perché i passi 3 e 4 contano di più.
3. Abiliti DKIM per il Suo dominio personalizzato — due CNAME di selettore. M365 firma con un default onmicrosoft.com non allineato finché non attiva la firma con dominio personalizzato: pubblichi i CNAME selector1._domainkey e selector2._domainkey che puntano alle chiavi del Suo tenant, poi abiliti la firma nel portale Defender. Percorso completo: configurare DKIM su Microsoft 365. Se DKIM mostra “pass” ma DMARC fallisce ancora, è nella trappola della firma di default.
4. Pubblichi DMARC, poi lo applichi. Inizi con v=DMARC1; p=none; rua=mailto:... per ricevere i report, sistemi ogni sorgente legittima che rivelano, poi salga a p=quarantine e p=reject — il percorso graduale è in correggere DMARC. È il passo che la maggior parte delle aziende Microsoft salta: solo il 21,7% dei domini che inviano via M365 applica DMARC.
5. Ritesti leggendo l’intestazione. Invii a una casella outlook.com consumer, apra l’origine del messaggio e confermi spf=pass, dkim=pass, dmarc=pass e compauth=pass.
6. Mittenti ad alto volume: rispettino la soglia di Outlook consumer. Oltre i 5.000/giorno Le servono anche un From/reply-to valido e presidiato, una disiscrizione funzionante e liste pulite — l’autenticazione risolve il 5.7.515; il tasso di reclami La tiene fuori dai blocchi IP S3140/S3150. Se il Suo IP è già bloccato, sistemare SPF/DKIM/DMARC non rimuove il blocco: richieda la rimozione tramite il supporto mittenti di Microsoft, e consideri l’autenticazione come il motivo per cui non ci ricascherà.

Perché così tanti domini Microsoft 365 falliscono ancora?

Perché il default fa il primo passo al posto Suo e nessuno dei successivi. Tra i 10.205.070 domini che autorizzano spf.protection.outlook.com, il 85,0% ha SPF rigoroso — il record che M365 Le consegna alla configurazione — ma solo il 21,7% applica DMARC, secondo il censimento Defaults.Exposed di 261.086.232 domini. M365 Le dà SPF rigoroso di default, poi la maggior parte dei tenant si ferma lì — esattamente la popolazione per cui compauth è stato creato (comunque avanti rispetto al 10,59% di applicazione DMARC su tutti i domini valutati). Confronto completo dei provider: la nostra classifica SPF dei provider email.

Domande frequenti

Il 550 5.7.515 è un errore di Microsoft 365? No. Proviene da Outlook.com/Hotmail consumer e riguarda chi invia >5.000 messaggi/giorno, con applicazione da maggio 2025. I rifiuti di Exchange Online aziendale usano codici diversi — più comunemente il 550 5.7.509 (la Sua policy DMARC reject) o il 5.7.511 (mittente bloccato).

Abbiamo ricevuto un 550 5.7.509 ma la posta era legittima — dovremmo abbandonare p=reject? No — la Sua policy ha intercettato una sorgente non autenticata: sta funzionando. Trovi la sorgente nell’intestazione o nei Suoi report DMARC e le dia DKIM allineato (o SPF allineato). Indebolire a p=none riapre lo spoofing del dominio esatto per chiunque.

compauth=fail significa che qualcuno ci sta spoofando? Non necessariamente. reason=001 di solito significa che la Sua stessa posta non riesce a dimostrare di essere Sua — niente DKIM allineato, niente DMARC. Solo il 21,7% dei 10.205.070 domini che inviano via M365 applica DMARC (dati al 2026-06-29), quindi Microsoft applica controlli impliciti a tutti gli altri, e anche la posta legittima non autenticata li fallisce.

Invio meno di 5.000 email al giorno — posso ignorare tutto questo? Eviterà il 550 5.7.515, ma non la Posta indesiderata: compauth si applica a qualsiasi volume. Gmail gioca la stessa partita — veda la guida al 550 5.7.26 di Gmail. Le soluzioni sono gratuite; l’ostacolo è la consapevolezza, non il costo.

Invii il report al titolare

Se sistema l’email per qualcun altro — un cliente, il Suo capo, l’azienda le cui fatture rimbalzavano — concluda il lavoro con le prove. Riesegua la scansione gratuita dopo che il DNS si è propagato e inoltri il report con il voto. Mostra SPF, DKIM e DMARC che diventano verdi in un linguaggio semplice che un titolare d’azienda può leggere, ed è il documento che servirà la prossima volta che il rinnovo dell’assicurazione cyber o il questionario di sicurezza di un cliente chiederà se la loro email è autenticata. Risolto va bene; dimostrabilmente risolto è ciò che La fa pagare e li tiene coperti.

Controlli il Suo dominio gratis

Veda su quale gamba Microsoft La sta bocciando — SPF, DKIM, DMARC — in modo privato e visibile solo al titolare.

Controlli il Suo dominio → · Correggere DMARC → · DKIM passa ma DMARC fallisce → · Come assegniamo i voti → · Solo dati aggregati. Dati archiviati ed elaborati nell’UE.