begrip · SMTP-gegevens Office 365

Wat zijn de SMTP-gegevens van Office 365 en wat betekenen ze voor applicatiemail?

Voor Office 365 SMTP bestaat er niet één universele host en één wachtwoord. Microsoft documenteert verschillende patronen voor applicaties en apparaten, waaronder geauthenticeerde clientsubmission via smtp.office365.com, SMTP relay op basis van connectors via het MX-endpoint van de tenant en Direct Send aan interne Microsoft 365-ontvangers. Ze verschillen in authenticatie, TLS, poorten, afzenderidentiteit, ondersteuning voor externe ontvangers, licenties, limieten en administratieve configuratie. Kies het patroon op basis van de workload en vertrouwensgrens, gebruik OAuth waar clientsubmission van toepassing is, houd SMTP AUTH beperkt ingeschakeld, test exacte envelope- en From-identiteiten en behandel relayacceptatie los van uiteindelijke bezorging of inboxplaatsing.

Office 365 SMTP-details beschrijven verschillende routes

De documentatie van Microsoft 365 en Office 365 maakt onderscheid tussen SMTP-clientsubmission, SMTP-relay en Direct Send. Clientsubmission authenticeert als een mailbox in Exchange Online en verzendt via smtp.office365.com. SMTP-relay behandelt de applicatie of het apparaat als een mailserver van de organisatie en authenticeert de verbinding met een inbound connector. Direct Send dient berichten anoniem in bij het Microsoft 365-MX-endpoint van de tenant, voor ontvangers binnen de organisatie. Dit zijn operationeel verschillende producten achter vergelijkbare SMTP-commando's. Kopieer geen hostnaam en poort van een forum zonder eerst te bepalen welke route bedoeld is. Leg eerst de tenant, geaccepteerde domeinen, beheerder, workload, afzenderidentiteiten, het bronnetwerk, de ontvangersscope, authenticatiemethode, het TLS-beleid, het volume en de verantwoordelijke voor fouten vast. SMTP-transport autoriseert niet de onderliggende zakelijke gebeurtenis, stelt geen toestemming van ontvangers vast en maakt een wachtrij in je applicatie niet duurzaam.

Instellingen voor SMTP-clientsubmission

De huidige installatiehandleiding van Microsoft noemt smtp.office365.com als DNS-naam voor clientsubmission en zegt dat je die niet door een IP-adres moet vervangen. Microsoft raadt TCP-poort 587 aan, staat poort 25 toe in het gedocumenteerde scenario en vereist TLS 1.2 of TLS 1.3 met STARTTLS ingeschakeld. De applicatie authenticeert als een mailbox in Microsoft 365 of Office 365 met licentie en kan binnen de gedocumenteerde limieten naar interne en externe ontvangers verzenden. Gebruik het mailboxadres als expliciete identiteit en test Send As-rechten als het zichtbare From-adres afwijkt. Bewaar credentials of tokens in een server-side secret manager. Een geslaagde login bewijst niet dat het zichtbare From-adres is toegestaan, dat de ontvanger geldig is of dat het bericht in een inbox terechtkomt. Clientsubmission is een pad dat aan een mailbox is gebonden, dus opschorting van een gebruiker, licentiewijzigingen, beslissingen van voorwaardelijke toegang en SMTP AUTH-instellingen kunnen een verder ongewijzigde applicatie onderbreken.

Gebruik OAuth en schakel SMTP AUTH zo beperkt mogelijk in

Microsoft raadt moderne authenticatie met OAuth aan voor SMTP-clientsubmission. De OAuth-documentatie definieert de scope SMTP.Send en het SASL XOAUTH2-formaat, met gedelegeerde en applicatiegerichte flows die afhankelijk zijn van registratie in Microsoft Entra en Exchange-rechten. Behandel access- en refreshtokens als secrets, vraag alleen de nodige rechten aan, valideer de koppeling met tenant en mailbox, roteer applicatiecredentials en verwijder ongebruikte toestemmingen. Microsoft raadt ook aan SMTP AUTH voor de hele Exchange Online-organisatie uit te schakelen en het alleen in te schakelen voor mailboxen die het nog nodig hebben. Er bestaan zowel een instelling voor de hele organisatie als een override per mailbox, en de mailboxinstelling kan voorrang hebben. Security defaults schakelen SMTP AUTH uit. Schakel een beveiligingsbaseline voor de hele tenant niet uit alleen om één verouderd apparaat werkend te houden. Kies liever een connector, een ondersteunde moderne client, een on-premises relay of een andere gedocumenteerde dienst als de workload niet aan de OAuth- en TLS-eisen kan voldoen.

Limieten van clientsubmission beïnvloeden het ontwerp van je applicatie

De huidige vergelijking van Microsoft documenteert voor SMTP-clientsubmission een throttling van 10.000 ontvangers per dag en 30 berichten per minuut. Beschouw dit als huidige servicelimieten die kunnen veranderen en kunnen samenhangen met andere limieten van Exchange Online. Tel ontvangers, niet alleen berichten, over To, Cc, Bcc, retries en fan-out. Leg de controles op verzendsnelheid, eerlijke verdeling tussen tenants, concurrency, pogingen en leeftijd in de wachtrij in je applicatie onder het plafond van de service. Een gedeeld mailboxpad kan tot concurrentie tussen menselijk en geautomatiseerd gebruik leiden, terwijl één credential die door veel applicaties wordt gebruikt het eigenaarschap verhult. Monitor de ruimte in snelheid en ontvangers, maar omzeil nooit een limiet door mailboxen of afzenderdomeinen te rouleren. Als de workload regelmatig de submissionlimieten van een mailbox nadert, beoordeel dan volgens de actuele richtlijnen van Microsoft relay via een connector, High Volume Email voor geschikt intern verkeer, Azure Communication Services Email voor bezorging vanuit applicaties of een ander transport dat daarvoor is gebouwd.

Gegevens voor SMTP-relay via een connector

SMTP-relay in Microsoft 365 gebruikt het MX-endpoint van de tenant in plaats van smtp.office365.com, plus een inbound connector die het verzendende systeem van de organisatie identificeert. Microsoft raadt aan de connector te authenticeren met een TLS-certificaat; een openbaar statisch IP-adres is een andere gedocumenteerde identificatiemethode. De applicatie verbindt via TCP-poort 25 en kan verzenden vanaf adressen in een geaccepteerd domein zonder dat elke afzender een mailbox met licentie nodig heeft. Dit patroon past bij beheerde mailservers, appliances of gateways met een stabiel certificaat en duidelijk netwerkeigenaarschap. Het vraagt meer beheer: de scope van de connector, de levenscyclus van certificaten, wijzigingen in openbare IP-adressen, reverse DNS, beleid voor geaccepteerde domeinen, misbruikpreventie en monitoring van blocklists. Maak nooit een open relay. Beperk welke interne systemen, tenants, afzenders, ontvangers en berichtklassen de gateway accepteert. Een connector herkent de verbinding als afkomstig van de organisatie; hij controleert niet of willekeurige invoer uit een applicatie legitiem is.

Direct Send is bezorging aan interne ontvangers, geen algemene relay

Direct Send dient berichten in bij het MX-endpoint van de tenant als externe SMTP-server, zonder te authenticeren als mailbox of connector. Microsoft documenteert het voor bezorging aan ontvangers binnen de Microsoft 365- of Office 365-organisatie, niet als route naar willekeurige externe adressen. Het apparaat of de applicatie heeft toegang tot TCP-poort 25 nodig en moet een afzender in een geaccepteerd domein gebruiken. Omdat het pad vanuit het perspectief van de internetgerichte dienst anoniem is, spelen afzenderreputatie, DNS, het bron-IP en beslissingen tegen spoofing een grote rol. Stel een Direct Send-gateway niet bloot aan onbetrouwbare netwerken en gebruik hem niet om mailboxauthenticatie te omzeilen. Modelleer non-delivery reports en de verantwoordelijkheid voor support, want een printer of applicatie kan bounceberichten mogelijk niet veilig ontvangen. Als bezorging aan externe ontvangers nodig is, kies dan na beoordeling van identiteit en volume voor clientsubmission, relay via een connector, Azure Communication Services Email of een andere ondersteunde methode.

Houd envelope-identiteit, zichtbare From en authenticatie gescheiden

Elke route bevat een SMTP-envelope-afzender en ontvangercommando's, plus zichtbare RFC 5322-headers. De envelope-afzender bepaalt waar transportbounces heen gaan en vaak de SPF-identiteit; het zichtbare From-adres bepaalt wat lezers zien en is de centrale identiteit voor DMARC. Mailboxauthenticatie via OAuth, een connectoridentiteit of acceptatie op basis van bron-IP zorgt niet automatisch voor SPF-, DKIM- of DMARC-alignment voor elk eigen From-domein. Inventariseer op gecontroleerde ontvangen voorbeelden de exacte MAIL FROM, From, Reply-To, het DKIM d=-domein en de selector, en het verbindende IP-adres. Publiceer één geldig SPF-beleid voor het betreffende domein, configureer DKIM-ondertekening waar dat wordt ondersteund en beoordeel de DMARC-alignment. Voeg geen tweede SPF-record toe en versoepel het DMARC-beleid van je organisatie niet om één apparaat te laten werken. Houd in statusmodellen acceptatie door Microsoft, acceptatie door de bestemmingsserver, latere bounces, mailboxfiltering, inboxplaatsing en menselijke actie uit elkaar.

Implementeer een duurzame applicatiegrens

Plaats SMTP van Microsoft 365 achter een geautoriseerde serverworker of een gecontroleerde relay. Sla een zakelijk event op voordat je verbindt, met een stabiele idempotentiesleutel, tenant, berichtklasse, templaterevisie, goedgekeurde afzender en ontvangers, de grondslag van toestemming of noodzaak, de suppressiestatus en de geschiedenis van pogingen. Dwing afzender- en ontvangerregels per tenant af voordat je SMTP-commando's genereert. Begrens de berichtgrootte, de fan-out naar ontvangers, bijlagen en headerwaarden. Bewaar tokens, wachtwoorden, private sleutels van certificaten en connectorbeheer buiten broncode, logs, analytics, tickets en prompts. Stel eindige timeouts in en classificeer 4xx-responses als kandidaten voor een begrensde retry en 5xx-responses als permanent voor die poging, op basis van de volledige enhanced diagnose en de richtlijnen van Microsoft. Een verbroken verbinding na DATA maar vóór het laatste antwoord is dubbelzinnig; bewaar de poging en reconcilieer die voordat je opnieuw verstuurt. SMTP biedt geen exactly-once-garantie op productniveau.

Test configuratie en faalscenario's vóór de uitrol

Gebruik speciale ontvangers die je zelf beheert en een bronnetwerk dat op productie lijkt. Controleer DNS-resolutie, bereikbaarheid van poorten, STARTTLS-onderhandeling, hostnaam en keten van het certificaat, het verkrijgen en de scope van OAuth-tokens, SMTP AUTH-instellingen voor organisatie en mailbox, Send As-autorisatie, het matchen van connectors, geaccepteerde domeinen en de keuze van het MX-endpoint. Verstuur voorbeelden met platte tekst, HTML, bijlagen, Unicode, bounces en het verwachte volume. Leg ruwe headers, vertrouwde Authentication-Results, SMTP-antwoorden, trace-identifiers en message trace-gegevens vast zonder klantcontent te bewaren. Negatieve tests moeten ingetrokken tokens, verlopen connectorcertificaten, een gewijzigd openbaar IP, uitgeschakelde SMTP AUTH voor een mailbox, security defaults, een ongeldig From-adres, een externe ontvanger via Direct Send, limieten per minuut en per ontvanger, tijdelijk uitstel, permanente weigering en verbindingsverlies rond DATA omvatten. Oefen het pauzeren van de workload en het verplaatsen van duurzame jobs zonder permanente beleids- of ontvangersfouten te omzeilen.

Gebruik actuele Microsoft-richtlijnen en test je tenant

De SMTP-configuratie van Microsoft 365 is afhankelijk van het beleid, de identiteiten, connectors en netwerkomgeving van de tenant. Gebruik actuele Microsoft Learn-documentatie en test de geselecteerde route in je tenant voordat je erop vertrouwt voor productie-e-mail.

Veelgestelde vragen

Wat is de SMTP-hostnaam voor clients in Microsoft 365?

Microsoft documenteert momenteel smtp.office365.com voor geauthenticeerde clientsubmission en zegt dat je de DNS-naam moet gebruiken in plaats van een vast IP-adres van de dienst.

Welke poort gebruik je voor SMTP-clientsubmission?

Microsoft raadt TCP-poort 587 aan en documenteert poort 25 voor het ondersteunde scenario voor clientsubmission, waarbij STARTTLS en TLS 1.2 of TLS 1.3 vereist zijn.

Ondersteunt clientsubmission in Microsoft 365 OAuth?

Ja. Microsoft raadt OAuth aan en documenteert de scope SMTP.Send plus SASL XOAUTH2. Registratie in de tenant, rechten, het bewaren van tokens en de koppeling met de mailbox vragen nog steeds om zorgvuldige configuratie.

Wat is het verschil tussen SMTP-relay en Direct Send?

Relay via een connector authenticeert een mailsysteem van de organisatie en kan externe ontvangers ondersteunen. Direct Send gebruikt het MX-endpoint van de tenant zonder die connector en is bedoeld voor interne ontvangers.

Moet SMTP AUTH voor elke mailbox zijn ingeschakeld?

Nee. Microsoft raadt aan het voor de hele organisatie uit te schakelen en alleen in te schakelen voor mailboxen die het nog nodig hebben, en de voorkeur te geven aan moderne authenticatie en ondersteunde alternatieven.

Betekent acceptatie door SMTP van Office 365 bezorging in de inbox?

Nee. Acceptatie is een afgebakende transportuitkomst. Latere bezorging, niet-bezorging, filtering door de ontvanger, de map waarin het bericht belandt en betrokkenheid van de ontvanger blijven afzonderlijk bewijs.

Kan een applicatie poort 465 gebruiken voor clientsubmission bij Microsoft?

Volgens de huidige handleiding van Microsoft ondersteunt een apparaat dat standaard poort 465 gebruikt niet de TLS-versies die voor clientsubmission via deze Microsoft 365-route vereist zijn.

Waar moet ik een SMTP-configuratie van Microsoft 365 verifiëren?

Gebruik actuele Microsoft Learn-documentatie en test de geselecteerde route in je tenant voordat je erop vertrouwt voor productie-e-mail.

Bronnen

Verder leren

Een SMTP-relayservice beoordelenBeoordeel SMTP-relayservices op beveiliging van submission, authenticatie, wachtrijen, retrygedrag, limieten, bezorgevents, suppressie, isolatie en geschiktheid voor migratie.De SMTP-relayservice van Google beoordelenBeoordeel de SMTP-relay van Google Workspace op autorisatiemodel, TLS, afzenderidentiteit, quota, foutafhandeling, authenticatie, observability en migratierisico.SMTP als mailprotocol: hoe applicatiemail zich verplaatstLeer hoe SMTP-submission, relay, envelopes, responscodes, TLS, retries en berichtinhoud de e-mailworkflow van een applicatie bepalen.SMTP-poorten 25, 465 en 587: een praktische gidsKies de juiste SMTP-poort op basis van rol en TLS-modus en analyseer daarna fouten in verbinding, handshake, authenticatie en acceptatie van berichten.Een deliverabilityservice voor e-mail beoordelenBeoordeel deliverabilityservices voor e-mail op scope, bewijs, authenticatie, feedbackloops, suppressies, privacy, overdraagbaarheid en operationele fit.