Fine del Basic Auth SMTP su Microsoft Exchange Online: calendario, errore 550 5.7.30 e guida alla migrazione
Di CaptainDNS
Pubblicato il 20 febbraio 2026
- Microsoft ritira Basic Auth per SMTP AUTH (Client Submission) su Exchange Online: disattivato di default a fine dicembre 2026 per i tenant esistenti, ritiro definitivo annunciato nel secondo semestre 2027.
- Ogni client ancora in Basic Auth riceverà l'errore
550 5.7.30 Basic authentication is not supported for Client Submission. - Cinque alternative: OAuth 2.0 SMTP, High Volume Email (HVE), Azure Communication Services, relay SMTP on-premises, Microsoft Graph API.
- Inventaria subito i tuoi mittenti in Basic Auth tramite il report SMTP AUTH nell'Exchange Admin Center.
Dal 2019 Microsoft sta eliminando progressivamente l'autenticazione Basic (nome utente + password) dai suoi protocolli Exchange Online. EAS, POP, IMAP, EWS, PowerShell: tutti sono stati migrati verso Modern Auth a fine 2022. L'ultimo baluardo rimasto era SMTP AUTH Client Submission, il protocollo utilizzato da stampanti multifunzione, script di invio e applicazioni aziendali per inviare email tramite smtp.office365.com sulla porta 587.
Ad aprile 2024 Microsoft ha annunciato la fine di quest'ultimo baluardo. Dopo diversi rinvii (settembre 2025, poi marzo 2026), il calendario aggiornato di gennaio 2026 concede un ulteriore periodo di grazia, ma il messaggio resta chiaro: Basic Auth SMTP è destinato a sparire, e ogni organizzazione deve pianificare la migrazione.
Questo articolo descrive il calendario esatto, i sistemi impattati, le cinque alternative disponibili e una checklist concreta di migrazione.
Cos'è Basic Auth SMTP e perché è un problema?
L'autenticazione Basic per SMTP funziona in modo semplice: il client codifica nome utente e password in Base64 e li trasmette al server nel comando AUTH LOGIN o AUTH PLAIN. Anche se la connessione è crittografata con TLS (STARTTLS sulla porta 587), le credenziali sono riutilizzabili, senza scadenza e senza secondo fattore.
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: dXNlckBjYXB0YWluZG5zLmNvbQ==
S: 334 UGFzc3dvcmQ6
C: bW90ZGVwYXNzZQ==
S: 235 2.7.0 Authentication successful
Questo meccanismo presenta tre problemi principali:
| Rischio | Descrizione |
|---|---|
| Furto di credenziali | Un attaccante che intercetta la sessione (anche crittografata) o compromette lo storage locale ottiene una password permanente |
| Attacchi brute force | Senza rate-limiting lato client, le credenziali possono essere testate su larga scala |
| Incompatibilità MFA | Basic Auth non supporta l'autenticazione multifattore, pilastro di Zero Trust |
OAuth 2.0 risolve tutti e tre i problemi: i token sono temporanei (60 minuti di default), revocabili, legati a uno scope preciso (SMTP.Send) e compatibili con MFA e accesso condizionale.
SMTP AUTH Client Submission vs SMTP Relay
È importante distinguere due meccanismi di invio tramite Exchange Online:
| Caratteristica | Client Submission (porta 587) | SMTP Relay (porta 25) |
|---|---|---|
| Endpoint | smtp.office365.com | Connettore in entrata Exchange Online |
| Autenticazione | Nome utente + password (Basic o OAuth) | Indirizzo IP sorgente (nessuna credenziale) |
| Impattato da questo ritiro | Sì | No |
| Destinatari | Interni ed esterni | Solo interni (di default) |
Il ritiro di Basic Auth riguarda solo Client Submission. I relay SMTP basati sull'indirizzo IP (opzione 2 della documentazione Microsoft) non sono interessati.
Calendario completo del ritiro
Il calendario è stato rivisto più volte. Ecco la timeline consolidata al 19 febbraio 2026:
| Data | Evento |
|---|---|
| Novembre 2019 | Annuncio iniziale "Improving Security Together" |
| Ottobre 2022 | Basic Auth disattivato per EAS, POP, IMAP, EWS, PowerShell. SMTP AUTH risparmiato |
| Aprile 2024 | Annuncio del ritiro di Basic Auth per SMTP AUTH Client Submission (previsto settembre 2025) |
| Metà ottobre 2024 | Report SMTP AUTH aggiornato nell'EAC (distinzione Basic vs OAuth) |
| Dicembre 2025 | Rinvio: nuova data prevista marzo-aprile 2026 |
| 27 gennaio 2026 | Timeline aggiornata: proroga fino a fine 2026 |
| Fine dicembre 2026 | Basic Auth SMTP disattivato di default per i tenant esistenti (riattivabile dall'admin) |
| Dopo dicembre 2026 | Nuovi tenant: Basic Auth SMTP non disponibile di default, solo OAuth |
| Secondo semestre 2027 | Microsoft annuncerà la data di ritiro definitivo (irreversibile) |
L'errore 550 5.7.30
Dopo la disattivazione, ogni client che tenta un'autenticazione Basic riceverà:
550 5.7.30 Basic authentication is not supported for Client Submission.
Questo errore è un rifiuto permanente (codice 5xx). Il server mittente non riproverà. Le email non vengono messe in coda: vanno perse immediatamente.
Chi è impattato?
Ogni applicazione o dispositivo che invia email tramite smtp.office365.com o smtp-legacy.office365.com con nome utente e password è coinvolto.
Sistemi tipicamente impattati
| Categoria | Esempi |
|---|---|
| Stampanti multifunzione | Scan-to-email (Xerox, HP, Canon, Ricoh, Konica Minolta) |
| Applicazioni aziendali (LOB) | ERP, CRM, sistemi di ticketing, helpdesk |
| Script automatizzati | PowerShell Send-MailMessage, Python smtplib, cron job |
| Server di stampa | Notifiche di fine lavoro |
| Sistemi di monitoring | Avvisi Nagios, Zabbix, PRTG via SMTP |
| Dispositivi IoT | NAS (Synology, QNAP), telecamere IP, controller domotici |
| Applicazioni SaaS legacy | Strumenti interni senza aggiornamento OAuth |
Come identificare i mittenti in Basic Auth?
Microsoft ha aggiornato il report SMTP AUTH nell'Exchange Admin Center (EAC) a ottobre 2024 per distinguere le connessioni Basic Auth da quelle OAuth.
- Accedi a admin.exchange.microsoft.com
- Vai in Report > Flusso di posta > Report client SMTP Auth
- Filtra per tipo di autenticazione per isolare i mittenti in Basic Auth
Ogni riga indica l'indirizzo del mittente, il numero di messaggi e il tipo di autenticazione utilizzato.
Alternativa 1: OAuth 2.0 per SMTP AUTH
È la soluzione raccomandata da Microsoft per i client e le applicazioni in grado di gestire token OAuth.
Prerequisiti
- Registrare un'applicazione in Microsoft Entra (Azure AD)
- Aggiungere il permesso SMTP.Send (flusso interattivo) o SMTP.SendAsApp (flusso applicativo)
- Ottenere il consenso admin del tenant
Due flussi possibili
| Flusso | Utilizzo | MFA | Token |
|---|---|---|---|
| Authorization Code | App interattive (utente presente) | Sì | A nome dell'utente |
| Client Credentials | Script server, daemon, servizi | No (service principal) | A nome dell'applicazione |
Sessione SMTP con OAuth
Il client utilizza il meccanismo SASL XOAUTH2:
C: AUTH XOAUTH2 dXNlcj1hbGVydHNAY2FwdGFpbmRucy5jb20BYXV0aD1CZWFyZXIgZXl
KMGVYQUlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUo5Li4uAQE=
S: 235 2.7.0 Authentication successful
Il token Base64 codifica user=alerts@captaindns.com seguito dal Bearer token OAuth. Il token scade dopo 60 minuti; il client deve gestire il rinnovo tramite il refresh token.
Limiti
- Le stampanti MFP e i dispositivi IoT generalmente non supportano OAuth
- Richiede la registrazione di un'applicazione in Entra ID
- Il flusso Client Credentials richiede la registrazione di un Service Principal in Exchange Online tramite PowerShell
Alternativa 2: High Volume Email (HVE)
Il servizio HVE è progettato per gli invii interni ad alto volume da applicazioni e dispositivi.
| Caratteristica | Valore |
|---|---|
| Endpoint | smtp-hve.office365.com |
| Porta | 587 (TLS richiesto) |
| Autenticazione | Basic Auth (mantenuta per HVE) |
| Destinatari | Solo interni (invio esterno rimosso a giugno 2025) |
| Limite account | 100 account HVE per tenant |
| Limite destinatari | 50 per messaggio |
| Cartella Posta inviata | No |
Quando usare HVE?
HVE è adatto quando:
- Il dispositivo non supporta OAuth (MFP, IoT)
- Le email sono esclusivamente interne (avvisi, notifiche, scan-to-email verso caselle del tenant)
- Il volume è elevato (nessun rate-limit sui destinatari)
Creazione di un account HVE
Tramite l'EAC: Flusso di posta > High Volume Email (Preview) > Aggiungi un account HVE.
Oppure tramite PowerShell:
New-MailUser -HVEAccount -Name "Scanner Alerts" -PrimarySmtpAddress "scanner-alerts@captaindns.com"
Attenzione: HVE è in preview pubblica. Microsoft si riserva il diritto di sospendere il servizio. Non assegnare licenze agli account HVE.
Alternativa 3: Azure Communication Services Email
Azure Communication Services (ACS) Email consente l'invio interno ed esterno tramite API REST o SDK (.NET, Python, JavaScript, Java).
| Caratteristica | Valore |
|---|---|
| Protocollo | API REST / SDK |
| Autenticazione | Chiave di accesso o Managed Identity |
| Destinatari | Interni ed esterni |
| Tariffazione | A consumo (per email inviata) |
| SMTP nativo | No (solo API) |
ACS è indicato per le applicazioni cloud-native che possono integrare un SDK. Non è adatto ai dispositivi fisici (stampanti, scanner) che comunicano solo tramite SMTP.
Alternativa 4: relay SMTP on-premises
Per le organizzazioni in configurazione ibrida (Exchange Online + Exchange Server on-premises), il relay SMTP locale resta un'opzione.
Funzionamento
- I dispositivi (MFP, IoT, script) inviano al server Exchange locale tramite la porta 25 (anonymous relay)
- Il connettore Receive è configurato per accettare le connessioni da un range IP interno
- Il server Exchange locale inoltra verso Exchange Online tramite il connettore Send
Configurazione del connettore Receive
New-ReceiveConnector -Name "Anonymous Relay" `
-TransportRole FrontendTransport `
-Usage Custom `
-Bindings 0.0.0.0:25 `
-RemoteIPRanges 192.168.1.0/24 `
-PermissionGroups AnonymousUsers
Vantaggi e svantaggi
| Vantaggio | Svantaggio |
|---|---|
| Nessun bisogno di OAuth lato dispositivo | Mantenere un server Exchange on-premises |
| Funziona con qualsiasi dispositivo SMTP | Complessità infrastrutturale e di licenza |
| Invio interno ed esterno | Punto di guasto aggiuntivo |
Alternativa 5: Microsoft Graph API
Per script e applicazioni, l'API Graph offre l'endpoint /users/{id}/sendMail che sostituisce vantaggiosamente SMTP.
curl -X POST "https://graph.microsoft.com/v1.0/users/alerts@captaindns.com/sendMail" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"message": {
"subject": "Alerte monitoring",
"body": {"contentType": "Text", "content": "Le serveur DNS est indisponible."},
"toRecipients": [{"emailAddress": {"address": "ops@captaindns.com"}}]
}
}'
Graph API è ideale per sostituire gli script PowerShell (Send-MailMessage è deprecato) e le applicazioni server. Non è adatto ai dispositivi hardware che possono eseguire solo SMTP.
Tabella comparativa delle alternative
| Criterio | OAuth SMTP | HVE | Azure CS | Relay on-prem | Graph API |
|---|---|---|---|---|---|
| Invio interno | Sì | Sì | Sì | Sì | Sì |
| Invio esterno | Sì | No | Sì | Sì | Sì |
| Supporta MFP/IoT | No | Sì | No | Sì | No |
| Basic Auth mantenuto | No | Sì | N/A | Sì | No |
| Sforzo di migrazione | Medio | Basso | Medio | Elevato | Medio |
| Costo aggiuntivo | Nessuno | Nessuno | A consumo | Licenza Exchange | Nessuno |
| MFA/Accesso condizionale | Sì | No | No | No | Sì |
Checklist di migrazione
Migrare da Basic Auth SMTP a un'alternativa sicura
- Passaggio 1: attivare e consultare il report SMTP AUTH
Accedi all'Exchange Admin Center. Vai in Report > Flusso di posta > Report client SMTP Auth. Filtra per tipo di autenticazione Basic. Esporta la lista dei mittenti.
- Passaggio 2: inventariare e categorizzare ogni mittente
Per ogni mittente identificato, determina: il tipo di dispositivo o applicazione, la sua capacità di supportare OAuth, i destinatari (solo interni o interni + esterni) e il volume di invio mensile.
- Passaggio 3: scegliere l'alternativa adatta a ogni categoria
App compatibili con OAuth: migra verso OAuth SMTP. Stampanti/scanner interni: usa HVE. Script: passa a Graph API. Dispositivi legacy con invio esterno: distribuisci un relay on-premises o Azure Communication Services.
- Passaggio 4: implementare e testare in parallelo
Configura il nuovo metodo di autenticazione per ogni mittente. Testa l'invio in parallelo con Basic Auth finché è ancora attivo. Verifica gli header delle email ricevute per confermare l'autenticazione OAuth.
- Passaggio 5: disattivare proattivamente Basic Auth
Prima della disattivazione da parte di Microsoft, crea un'Authentication Policy in Exchange Online che blocchi Basic Auth per SMTP:
Set-AuthenticationPolicy -AllowBasicAuthSmtp:$false. Applicala a un gruppo pilota, poi estendi progressivamente. - Passaggio 6: monitorare i rifiuti dopo la migrazione
Dopo il passaggio, monitora i log di trasporto Exchange per rilevare gli errori
550 5.7.30. Ogni occorrenza segnala un mittente non migrato. Gestiscili uno per uno applicando l'alternativa appropriata.
Impatto sulla deliverability e sulla sicurezza
Il ritiro di Basic Auth non influisce su SPF, DKIM o DMARC. Questi protocolli di autenticazione email funzionano a livello DNS e restano indipendenti dal metodo di autenticazione SMTP.
La migrazione offre però l'opportunità di rafforzare la tua postura di sicurezza:
- MFA ovunque: OAuth permette di imporre l'autenticazione multifattore sugli account di invio interattivi
- Token revocabili: a differenza di una password compromessa che resta valida fino alla modifica, un token OAuth scade automaticamente
- Accesso condizionale: puoi limitare l'invio SMTP a range IP specifici, dispositivi conformi o fasce orarie precise
- Audit granulare: le connessioni OAuth sono tracciabili nei log di Entra ID con il dettaglio dell'applicazione e dello scope utilizzato
Questo movimento di Microsoft si inserisce in una tendenza più ampia. Google e Yahoo hanno imposto requisiti di autenticazione rafforzati per i mittenti ad alto volume già dal 2024. La messa in sicurezza del canale di invio SMTP è il passo successivo logico.
FAQ
Basic Auth SMTP è già disattivato su Exchange Online?
No. Al 19 febbraio 2026, Basic Auth SMTP funziona ancora normalmente. La disattivazione di default è prevista per fine dicembre 2026 sui tenant esistenti. Gli admin potranno temporaneamente riattivarlo. La data di ritiro definitivo sarà annunciata nel secondo semestre 2027.
La mia stampante non supporta OAuth, cosa faccio?
Due opzioni: utilizzare High Volume Email (HVE), che mantiene Basic Auth su un endpoint dedicato (smtp-hve.office365.com) per l'invio solo interno. Oppure distribuire un relay SMTP on-premises (Exchange Server ibrido o server SMTP di terze parti) che accetta connessioni senza OAuth e inoltra verso Exchange Online.
Si può richiedere un'eccezione a Microsoft?
No. Microsoft è esplicita: nessuna eccezione sarà concessa. Il supporto tecnico non può né riattivare Basic Auth definitivamente né concedere deroghe. L'unica soluzione è migrare verso un'alternativa.
HVE supporta l'invio verso destinatari esterni?
No. Da giugno 2025 HVE supporta solo l'invio interno (destinatari all'interno dello stesso tenant). Per l'invio esterno, usa OAuth SMTP, Azure Communication Services, un relay on-premises o Graph API.
Come faccio a sapere se le mie applicazioni usano Basic Auth?
Consulta il report SMTP AUTH nell'Exchange Admin Center (Report > Flusso di posta > Report client SMTP Auth). Da ottobre 2024 questo report distingue le connessioni Basic Auth da quelle OAuth. Puoi anche consultare i Sign-in log in Microsoft Entra per le connessioni SMTP.
L'errore 550 5.7.30 è definitivo?
Sì. Il codice 550 è un rifiuto permanente (5xx). Il server mittente non riproverà la consegna. L'email va persa. Occorre correggere la sorgente migrando verso OAuth o un'altra alternativa prima che Basic Auth venga disattivato.
Graph API può sostituire SMTP per uno scanner?
No. Scanner e stampanti multifunzione comunicano esclusivamente tramite SMTP. Graph API richiede un client HTTP in grado di eseguire richieste REST con token OAuth, il che supera le capacità di questi dispositivi. Usa HVE o un relay on-premises per questi casi.
Qual è la differenza tra SMTP Client Submission e SMTP Relay?
Client Submission (porta 587) autentica il mittente con credenziali (Basic o OAuth) tramite smtp.office365.com. SMTP Relay (porta 25) autentica tramite indirizzo IP sorgente con un connettore Exchange Online. Solo Client Submission è impattato dal ritiro di Basic Auth.
Scarica la checklist di deploy
Gli assistenti possono riutilizzare la checklist tramite gli export JSON o CSV qui sotto.
Glossario
- Basic Auth: metodo di autenticazione che trasmette nome utente e password codificati in Base64. Nessuna protezione intrinseca contro il replay.
- OAuth 2.0: protocollo di autorizzazione basato su token temporanei. Supporta MFA e accesso condizionale.
- SASL XOAUTH2: meccanismo SASL utilizzato per trasmettere un token OAuth 2.0 in una sessione SMTP, IMAP o POP.
- Client Submission: metodo di invio SMTP autenticato tramite
smtp.office365.com(porta 587). Il mittente si autentica con credenziali. - SMTP Relay: metodo di invio SMTP basato sull'indirizzo IP sorgente, senza credenziali. Utilizza un connettore in entrata Exchange Online.
- HVE (High Volume Email): servizio Microsoft 365 per l'invio interno ad alto volume tramite
smtp-hve.office365.com. In preview pubblica. - Microsoft Entra: nuovo nome di Azure Active Directory. Gestisce la registrazione delle applicazioni, i permessi e i token OAuth.
- Service Principal: identità dell'applicazione in Exchange Online, necessaria per il flusso Client Credentials OAuth.
- MFA: autenticazione multifattore. Impossibile con Basic Auth, nativa con OAuth 2.0.
Fonti
- Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) - Exchange Team Blog, aprile 2024
- Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline - Exchange Team Blog, gennaio 2026
- Deprecation of Basic authentication in Exchange Online - Microsoft Learn
- Authenticate an IMAP, POP or SMTP connection using OAuth - Microsoft Learn
- Manage High Volume Email for Microsoft 365 - Microsoft Learn
