Quali sono le impostazioni SMTP di Office 365 e che impatto hanno sulle email applicative?

I dettagli SMTP di Office 365 descrivono diversi percorsi

La documentazione di Microsoft 365 e Office 365 distingue submission SMTP client, relay SMTP e Direct Send. La submission client si autentica come casella di Exchange Online e invia tramite smtp.office365.com. Il relay SMTP tratta l'applicazione o il dispositivo come un server di posta dell'organizzazione e autentica la connessione con un connettore in entrata. Direct Send invia in modo anonimo all'endpoint MX di Microsoft 365 del tenant per i destinatari dell'organizzazione. Dal punto di vista operativo sono prodotti diversi dietro comandi SMTP simili. Non copiare hostname e porta da un forum senza aver deciso quale percorso intendi usare. Registra prima tenant, domini accettati, amministratore, carico, identità dei mittenti, rete di origine, ambito dei destinatari, metodo di autenticazione, policy TLS, volume e responsabile degli errori. Il trasporto SMTP non autorizza l'evento di business di origine, non stabilisce il consenso del destinatario e non rende persistente la coda dell'applicazione.

Impostazioni della submission SMTP client

L'attuale guida di configurazione di Microsoft indica smtp.office365.com come nome DNS per la submission client e raccomanda di non sostituirlo con un indirizzo IP. Consiglia la porta TCP 587, ammette la porta 25 nello scenario documentato e richiede TLS 1.2 o TLS 1.3 con STARTTLS abilitato. L'applicazione si autentica come casella Microsoft 365 o Office 365 con licenza e può inviare a destinatari interni ed esterni entro i limiti documentati. Usa l'indirizzo della casella come identità esplicita e testa i permessi Send As quando il From visibile è diverso. Conserva credenziali o token in un secret manager lato server. Un accesso all'account riuscito non dimostra che il From visibile sia consentito, che il destinatario sia valido o che il messaggio arriverà in inbox. La submission client è un percorso legato a una casella, quindi sospensione dell'utente, modifiche di licenza, decisioni di accesso condizionale e impostazioni SMTP AUTH possono interrompere un'applicazione che per il resto non è cambiata.

Usa OAuth e abilita SMTP AUTH in modo mirato

Microsoft consiglia l'autenticazione moderna con OAuth per la submission SMTP client. La sua documentazione OAuth definisce lo scope SMTP.Send e il formato SASL XOAUTH2, con flussi delegati e orientati alle applicazioni soggetti alla registrazione in Microsoft Entra e ai permessi di Exchange. Tratta access token e refresh token come segreti, richiedi solo i permessi necessari, convalida il legame con tenant e casella, ruota le credenziali dell'applicazione e rimuovi le autorizzazioni inutilizzate. Microsoft consiglia inoltre di disabilitare SMTP AUTH per l'organizzazione Exchange Online e di abilitarlo solo per le caselle che ne hanno ancora bisogno. Esistono sia un'impostazione a livello di organizzazione sia un override per casella, e l'impostazione della casella può avere la precedenza. I Security defaults disabilitano SMTP AUTH. Non disabilitare una baseline di sicurezza dell'intero tenant solo per mantenere in funzione un dispositivo legacy. Preferisci un connettore, un client moderno supportato, un relay on-premises o un altro servizio documentato quando il carico non può soddisfare i requisiti OAuth e TLS.

I limiti della submission client influenzano il design dell'applicazione

L'attuale confronto di Microsoft documenta per la submission SMTP client un throttling di 10.000 destinatari al giorno e 30 messaggi al minuto. Trattali come limiti di servizio attuali che possono cambiare e interagire con altri limiti di Exchange Online. Conta i destinatari, non solo i messaggi, considerando To, Cc, Bcc, nuovi tentativi e fan-out. Imposta i controlli applicativi su velocità, equità tra tenant, concorrenza, tentativi ed età in coda al di sotto del tetto del servizio. Un percorso tramite casella condivisa può creare contesa tra uso umano e automatico, mentre una sola credenziale usata da molte applicazioni nasconde chi ne è responsabile. Monitora il margine su velocità e destinatari, ma non aggirare mai un limite ruotando caselle o domini mittente. Se il carico si avvicina regolarmente ai limiti di submission della casella, valuta il relay tramite connettore, High Volume Email per il traffico interno idoneo, Azure Communication Services Email per la consegna applicativa o un altro trasporto dedicato, seguendo le indicazioni attuali di Microsoft.

Impostazioni del relay SMTP basato su connettore

Il relay SMTP di Microsoft 365 usa l'endpoint MX del tenant invece di smtp.office365.com, insieme a un connettore in entrata che identifica il sistema di invio dell'organizzazione. Microsoft consiglia di autenticare il connettore con un certificato TLS; un indirizzo IP pubblico statico è un altro metodo di identificazione documentato. L'applicazione si connette sulla porta TCP 25 e può inviare da indirizzi di un dominio accettato senza richiedere una casella con licenza per ogni mittente. Questo modello è adatto a server di posta, appliance o gateway controllati, con una gestione stabile di certificati e rete. Richiede più amministrazione: ambito del connettore, ciclo di vita dei certificati, cambi di IP pubblico, DNS inverso, policy sui domini accettati, prevenzione degli abusi e monitoraggio delle blocklist. Non creare mai un open relay. Limita quali sistemi interni, tenant, mittenti, destinatari e classi di messaggi il gateway accetta. Un connettore riconosce la connessione come appartenente all'organizzazione, ma non verifica che un input applicativo arbitrario sia legittimo.

Direct Send è una consegna a destinatari interni, non un relay generico

Direct Send invia all'endpoint MX del tenant come un server SMTP esterno, senza autenticarsi come casella o connettore. Microsoft lo documenta per la consegna a destinatari dell'organizzazione Microsoft 365 o Office 365, non come percorso verso indirizzi esterni arbitrari. Il dispositivo o l'applicazione ha bisogno di accesso alla porta TCP 25 e dovrebbe usare un mittente in un dominio accettato. Poiché dal punto di vista del servizio esposto su Internet il percorso è anonimo, contano la reputazione del mittente, il DNS, l'IP di origine e le decisioni anti-spoofing. Non esporre un gateway Direct Send a reti non attendibili e non usarlo per aggirare l'autenticazione della casella. Modella i report di mancato recapito e la responsabilità del supporto, perché una stampante o un'applicazione potrebbero non ricevere i messaggi di bounce in modo sicuro. Se serve la consegna esterna, scegli la submission client, il relay tramite connettore, Azure Communication Services Email o un altro metodo supportato dopo aver valutato identità e volume.

Tieni separati identità della busta, From visibile e autenticazione

Ogni percorso trasporta un mittente della busta SMTP e comandi per i destinatari, oltre alle intestazioni visibili RFC 5322. Il mittente della busta gestisce i bounce di trasporto e spesso l'identità SPF; il From visibile determina ciò che vedono i lettori ed è l'identità centrale per DMARC. L'autenticazione OAuth della casella, l'identità del connettore o l'accettazione in base all'IP di origine non creano automaticamente l'allineamento SPF, DKIM o DMARC per ogni dominio From personalizzato. Fai un inventario di MAIL FROM, From, Reply-To, dominio d= e selettore DKIM e IP di connessione esatti su campioni ricevuti controllati. Pubblica una sola policy SPF valida per il dominio interessato, configura la firma DKIM dove supportata e valuta l'allineamento DMARC. Non aggiungere un secondo record SPF e non allentare la policy DMARC dell'organizzazione per sistemare un singolo dispositivo. Nei modelli di stato, tieni separati accettazione da parte di Microsoft, accettazione da parte del server di destinazione, bounce successivo, filtraggio della casella, arrivo in inbox e azione della persona.

Implementa un confine applicativo persistente

Metti SMTP di Microsoft 365 dietro un worker server autorizzato o un relay controllato. Salva un evento di business prima di connetterti, includendo una chiave di idempotenza stabile, tenant, classe di messaggi, revisione del template, mittente e destinatari approvati, base di consenso o necessità, stato di soppressione e cronologia dei tentativi. Applica le regole per tenant su mittenti e destinatari prima di generare i comandi SMTP. Limita dimensione dei messaggi, fan-out dei destinatari, allegati e valori delle intestazioni. Conserva token, password, chiavi private dei certificati e amministrazione dei connettori fuori dal codice sorgente, dai log, dagli analytics, dai ticket e dai prompt. Imposta timeout finiti e classifica le risposte 4xx come candidate a un numero limitato di nuovi tentativi e le risposte 5xx come permanenti per quel tentativo, usando la diagnostica estesa completa e le indicazioni di Microsoft. Una disconnessione dopo DATA ma prima della risposta finale è ambigua: conserva il tentativo e riconcilialo prima di inviare di nuovo. SMTP non offre alcuna garanzia exactly-once a livello di prodotto.

Testa configurazione e modalità di errore prima del rilascio

Usa destinatari controllati dedicati e una rete di origine configurata come in produzione. Verifica risoluzione DNS, raggiungibilità delle porte, negoziazione STARTTLS, hostname e catena del certificato, acquisizione e scope del token OAuth, impostazioni SMTP AUTH di organizzazione e casella, autorizzazione Send As, corrispondenza del connettore, domini accettati e scelta dell'endpoint MX. Invia campioni in testo semplice, HTML, con allegato, Unicode, di bounce e con il volume previsto. Registra intestazioni raw, Authentication-Results attendibili, risposte SMTP, identificatori di trace e prove della traccia dei messaggi senza conservare contenuti dei clienti. I test negativi dovrebbero coprire token revocati, certificati del connettore scaduti, IP pubblico cambiato, SMTP AUTH disabilitato sulla casella, Security defaults, From non valido, destinatario esterno tramite Direct Send, limiti al minuto e sui destinatari, rinvio temporaneo, rifiuto permanente e perdita di connessione intorno a DATA. Prova a sospendere il carico e a spostare i job persistenti senza aggirare errori permanenti di policy o dei destinatari.

Usa le linee guida Microsoft correnti e testa il tuo tenant

La configurazione SMTP di Microsoft 365 dipende dalle policy, dalle identità, dai connettori e dall'ambiente di rete del tenant. Usa la documentazione corrente di Microsoft Learn e testa il percorso selezionato nel tuo tenant prima di farvi affidamento per email di produzione.

Domande frequenti

Fonti

• Configurare un dispositivo multifunzione o un'applicazione per inviare email con Microsoft 365 o Office 365 — Microsoft Learn
• Autenticare una connessione IMAP, POP o SMTP con OAuth — Microsoft Learn
• Abilitare o disabilitare la submission SMTP client autenticata in Exchange Online — Microsoft Learn
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — RFC Editor
• RFC 3207: estensione del servizio SMTP per SMTP sicuro su TLS — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor