Begriff · Office 365 SMTP-Einstellungen

Was sind die Office-365-SMTP-Einstellungen, und wie wirken sie sich auf Anwendungs-E-Mails aus?

Office-365-SMTP-Details bestehen nicht aus einem universellen Host und einem Passwort. Microsoft dokumentiert mehrere Anwendungs- und Gerätemuster, darunter authentifizierte Client-Submission über smtp.office365.com, Connector-basiertes SMTP-Relay über den MX-Endpunkt des Mandanten und Direct Send an interne Microsoft-365-Empfänger. Sie unterscheiden sich bei Authentifizierung, TLS, Ports, Absenderidentität, Unterstützung externer Empfänger, Lizenzierung, Limits und administrativer Einrichtung. Wählen Sie das Muster nach Arbeitslast und Vertrauensgrenze, verwenden Sie OAuth bei Client-Submission, aktivieren Sie SMTP AUTH nur eng begrenzt, testen Sie exakte Envelope- und From-Identitäten und behandeln Sie Relay-Annahme getrennt von endgültiger Zustellung oder Platzierung im Posteingang.

Office-365-SMTP-Details beschreiben mehrere Wege

Die Dokumentation zu Microsoft 365 und Office 365 unterscheidet Client-SMTP-Submission, SMTP-Relay und Direct Send. Bei der Client-Submission authentifiziert sich die Anwendung als Exchange-Online-Postfach und sendet über smtp.office365.com. Beim SMTP-Relay wird die Anwendung oder das Gerät als Mailserver der Organisation behandelt, und die Verbindung wird über einen Inbound-Connector authentifiziert. Direct Send liefert anonym an den Microsoft-365-MX-Endpunkt des Mandanten für Empfänger innerhalb der Organisation. Hinter ähnlichen SMTP-Befehlen stehen betrieblich unterschiedliche Produkte. Kopieren Sie Hostnamen und Port nicht aus einem Forum, ohne zu entscheiden, welche Route gemeint ist. Halten Sie zuerst Mandant, akzeptierte Domains, Administrator, Workload, Absenderidentitäten, Quellnetzwerk, Empfängerumfang, Authentifizierungsmethode, TLS-Richtlinie, Volumen und die für Fehler zuständige Stelle fest. SMTP-Transport autorisiert weder das ursprüngliche Geschäftsereignis noch begründet er die Einwilligung der Empfänger oder macht eine Anwendungswarteschlange dauerhaft.

Einstellungen für Client-SMTP-Submission

Der aktuelle Einrichtungsleitfaden von Microsoft nennt smtp.office365.com als DNS-Namen für die Client-Submission und verbietet, eine IP-Adresse zu verwenden. Er empfiehlt TCP-Port 587, erlaubt im dokumentierten Szenario Port 25 und verlangt TLS 1.2 oder TLS 1.3 mit aktiviertem STARTTLS. Die Anwendung authentifiziert sich als lizenziertes Microsoft-365- oder Office-365-Postfach und kann im Rahmen der dokumentierten Limits an interne und externe Empfänger senden. Verwenden Sie die Postfachadresse als explizite Identität und testen Sie die Berechtigung „Senden als“, wenn das sichtbare From abweicht. Bewahren Sie Zugangsdaten oder Tokens in einem serverseitigen Secret-Manager auf. Eine erfolgreiche Kontoanmeldung belegt weder, dass das sichtbare From erlaubt ist, noch dass der Empfänger gültig ist oder die Nachricht in einem Posteingang landet. Client-Submission ist ein postfachbezogener Pfad; Sperrung von Nutzern, Lizenzänderungen, Entscheidungen des bedingten Zugriffs und SMTP-AUTH-Einstellungen können daher eine sonst unveränderte Anwendung unterbrechen.

OAuth verwenden und SMTP AUTH gezielt aktivieren

Microsoft empfiehlt für die Client-SMTP-Submission moderne Authentifizierung mit OAuth. Die OAuth-Dokumentation definiert den Scope SMTP.Send und das SASL-Format XOAUTH2, mit delegierten und anwendungsorientierten Abläufen, die Microsoft-Entra-Registrierung und Exchange-Berechtigungen voraussetzen. Behandeln Sie Zugriffs- und Refresh-Tokens als Geheimnisse, fordern Sie nur nötige Berechtigungen an, validieren Sie die Bindung an Mandant und Postfach, rotieren Sie Anwendungszugangsdaten und entfernen Sie ungenutzte Freigaben. Microsoft empfiehlt außerdem, SMTP AUTH für die Exchange-Online-Organisation zu deaktivieren und nur für Postfächer zu aktivieren, die es noch benötigen. Es gibt sowohl eine organisationsweite Einstellung als auch eine Überschreibung pro Postfach, und die Postfacheinstellung kann Vorrang haben. Security Defaults deaktivieren SMTP AUTH. Deaktivieren Sie keine mandantenweite Sicherheitsbasis, nur um ein einzelnes Altgerät weiter zu betreiben. Bevorzugen Sie einen Connector, einen unterstützten modernen Client, ein lokales Relay oder einen anderen dokumentierten Dienst, wenn die Workload die Anforderungen an OAuth und TLS nicht erfüllen kann.

Limits der Client-Submission beeinflussen das Anwendungsdesign

Der aktuelle Vergleich von Microsoft dokumentiert für die Client-SMTP-Submission eine Drosselung auf 10.000 Empfänger pro Tag und 30 Nachrichten pro Minute. Behandeln Sie diese Werte als aktuelle Dienstlimits, die sich ändern können und mit anderen Exchange-Online-Limits zusammenwirken können. Zählen Sie Empfänger, nicht nur Nachrichten, über To, Cc, Bcc, Wiederholungen und Fan-out hinweg. Legen Sie Anwendungsrate, Fairness zwischen Mandanten, Nebenläufigkeit, Versuche und Alter in der Warteschlange unterhalb der Dienstobergrenze fest. Ein gemeinsam genutzter Postfachpfad kann zu Konflikten zwischen menschlicher und automatisierter Nutzung führen, während ein Zugang, den viele Anwendungen teilen, die Verantwortlichkeit verschleiert. Überwachen Sie Rate und verbleibenden Empfängerspielraum, umgehen Sie ein Limit aber nie durch rotierende Postfächer oder Absenderdomains. Nähert sich die Workload regelmäßig den Submission-Limits des Postfachs, prüfen Sie anhand aktueller Microsoft-Leitlinien Connector-Relay, High Volume Email für geeigneten internen Verkehr, Azure Communication Services Email für die Anwendungszustellung oder einen anderen dafür gebauten Transport.

Details zum Connector-basierten SMTP-Relay

Das Microsoft-365-SMTP-Relay nutzt den MX-Endpunkt des Mandanten statt smtp.office365.com sowie einen Inbound-Connector, der das Sendesystem der Organisation identifiziert. Microsoft empfiehlt, den Connector mit einem TLS-Zertifikat zu authentifizieren; eine öffentliche statische IP-Adresse ist als weitere dokumentierte Identitätsmethode möglich. Die Anwendung verbindet sich über TCP-Port 25 und kann von Adressen einer akzeptierten Domain senden, ohne dass für jeden Absender ein lizenziertes Postfach nötig ist. Dieses Muster passt zu kontrollierten Mailservern, Appliances oder Gateways mit stabiler Verantwortung für Zertifikat und Netzwerk. Es verlangt mehr Administration: Connector-Geltungsbereich, Zertifikatslebenszyklus, Änderungen der öffentlichen IP, Reverse DNS, Richtlinie für akzeptierte Domains, Missbrauchsprävention und Überwachung von Blocklists. Richten Sie niemals ein Open Relay ein. Beschränken Sie, welche internen Systeme, Mandanten, Absender, Empfänger und Nachrichtenklassen das Gateway akzeptiert. Ein Connector erkennt die Verbindung als organisationszugehörig; er prüft nicht, ob beliebige Anwendungseingaben legitim sind.

Direct Send ist Zustellung an interne Empfänger, kein allgemeines Relay

Direct Send liefert als externer SMTP-Server an den MX-Endpunkt des Mandanten, ohne sich als Postfach oder Connector zu authentifizieren. Microsoft dokumentiert es für die Zustellung an Empfänger in der Microsoft-365- oder Office-365-Organisation, nicht als Weg zu beliebigen externen Adressen. Das Gerät oder die Anwendung braucht Zugriff auf TCP-Port 25 und sollte einen Absender aus einer akzeptierten Domain verwenden. Weil der Pfad aus Sicht des internetseitigen Dienstes anonym ist, spielen Absenderreputation, DNS, Quell-IP und Anti-Spoofing-Entscheidungen eine Rolle. Legen Sie ein Direct-Send-Gateway nicht für nicht vertrauenswürdige Netze offen und umgehen Sie damit nicht die Postfachauthentifizierung. Modellieren Sie Nichtzustellungsberichte und die Zuständigkeit im Support, denn ein Drucker oder eine Anwendung erhält Bounce-Nachrichten unter Umständen nicht sicher. Wenn externe Zustellung nötig ist, wählen Sie nach Prüfung von Identität und Volumen Client-Submission, Connector-Relay, Azure Communication Services Email oder eine andere unterstützte Methode.

Envelope-Identität, sichtbares From und Authentifizierung getrennt halten

Jede Route trägt einen SMTP-Envelope-Absender und Empfängerbefehle sowie sichtbare Header nach RFC 5322. Der Envelope-Absender steuert Transport-Bounces und ist häufig die SPF-Identität; das sichtbare From steuert, was Leser sehen, und ist die zentrale DMARC-Identität. Postfachauthentifizierung über OAuth, Connector-Identität oder Akzeptanz per Quell-IP erzeugt nicht automatisch SPF-, DKIM- oder DMARC-Alignment für jede benutzerdefinierte From-Domain. Erfassen Sie anhand kontrolliert empfangener Stichproben das exakte MAIL FROM, From, Reply-To, die DKIM-Domain d= samt Selektor und die verbindende IP. Veröffentlichen Sie eine gültige SPF-Richtlinie für die jeweilige Domain, konfigurieren Sie DKIM-Signierung, wo unterstützt, und prüfen Sie das DMARC-Alignment. Fügen Sie keinen zweiten SPF-Eintrag hinzu und lockern Sie keine organisationsweite DMARC-Richtlinie, um ein einzelnes Gerät zu reparieren. Trennen Sie in Statusmodellen Annahme durch Microsoft, Annahme durch den Zielserver, späteren Bounce, Postfachfilterung, Platzierung im Posteingang und menschliche Handlung.

Eine dauerhafte Anwendungsgrenze schaffen

Setzen Sie Microsoft-365-SMTP hinter einen autorisierten Server-Worker oder ein kontrolliertes Relay. Speichern Sie ein Geschäftsereignis, bevor Sie sich verbinden, einschließlich eines stabilen Idempotenzschlüssels, Mandanten, der Nachrichtenklasse, der Template-Revision, des genehmigten Absenders und der Empfänger, der Einwilligungs- oder Erforderlichkeitsgrundlage, des Sperrstatus und des Versuchsverlaufs. Erzwingen Sie Absender- und Empfängerregeln pro Mandant, bevor Sie SMTP-Befehle erzeugen. Begrenzen Sie Nachrichtengröße, Empfänger-Fan-out, Anhänge und Header-Werte. Speichern Sie Tokens, Passwörter, private Zertifikatsschlüssel und Connector-Administration außerhalb von Quellcode, Logs, Analytics, Tickets und Prompts. Setzen Sie endliche Timeouts und klassifizieren Sie 4xx-Antworten als Kandidaten für begrenzte Wiederholung und 5xx-Antworten als dauerhaft für diesen Versuch, anhand der vollständigen erweiterten Diagnose und der Microsoft-Leitlinien. Eine Verbindungstrennung nach DATA, aber vor der finalen Antwort ist mehrdeutig; bewahren Sie den Zustellversuch auf und gleichen Sie ihn ab, bevor Sie erneut senden. SMTP bietet auf Produktebene keine Exactly-once-Garantie.

Konfiguration und Fehlerfälle vor dem Rollout testen

Verwenden Sie dedizierte kontrollierte Empfänger und ein Quellnetzwerk, das dem Produktivbetrieb entspricht. Prüfen Sie DNS-Auflösung, Erreichbarkeit des Ports, STARTTLS-Aushandlung, Hostname und Kette des Zertifikats, Beschaffung und Scope des OAuth-Tokens, SMTP-AUTH-Einstellungen von Organisation und Postfach, „Senden als“-Berechtigung, Connector-Zuordnung, akzeptierte Domains und die Auswahl des MX-Endpunkts. Senden Sie Stichproben mit Plain Text, HTML, Anhang, Unicode, Bounce und erwartetem Volumen. Halten Sie rohe Header, vertrauenswürdige Authentication-Results, SMTP-Antworten, Trace-Kennungen und Nachweise aus dem Message Trace fest, ohne Kundeninhalte aufzubewahren. Negativtests sollten widerrufene Tokens, abgelaufene Connector-Zertifikate, geänderte öffentliche IP, deaktiviertes SMTP AUTH am Postfach, Security Defaults, ungültiges From, externe Empfänger über Direct Send, Limits pro Minute und pro Empfänger, temporäre Zurückstellung, dauerhafte Ablehnung und Verbindungsverlust rund um DATA abdecken. Üben Sie, die Workload zu pausieren und dauerhafte Jobs zu verschieben, ohne dauerhafte Richtlinien- oder Empfängerfehler zu umgehen.

Aktuelle Microsoft-Anleitungen verwenden und Ihren Mandanten testen

Die Microsoft-365-SMTP-Konfiguration hängt von Richtlinien, Identitäten, Connectors und der Netzwerkumgebung des Mandanten ab. Verwenden Sie aktuelle Microsoft-Learn-Dokumentation und testen Sie den gewählten Weg in Ihrem Mandanten, bevor Sie sich für Produktiv-E-Mails darauf verlassen.

Häufig gestellte Fragen

Wie lautet der Microsoft-365-Client-SMTP-Hostname?

Microsoft dokumentiert derzeit smtp.office365.com für die authentifizierte Client-Submission und verlangt, den DNS-Namen statt einer festen Dienst-IP-Adresse zu verwenden.

Welchen Port sollte die Client-SMTP-Submission verwenden?

Microsoft empfiehlt TCP-Port 587 und dokumentiert Port 25 für das unterstützte Szenario der Client-Submission; dabei sind STARTTLS und TLS 1.2 oder TLS 1.3 erforderlich.

Unterstützt die Microsoft-365-Client-Submission OAuth?

Ja. Microsoft empfiehlt OAuth und dokumentiert den Scope SMTP.Send sowie SASL XOAUTH2. Mandantenregistrierung, Berechtigungen, Token-Verwahrung und Postfachbindung erfordern dennoch eine sorgfältige Konfiguration.

Was ist der Unterschied zwischen SMTP-Relay und Direct Send?

Connector-Relay authentifiziert ein Mailsystem der Organisation und kann externe Empfänger unterstützen. Direct Send nutzt den MX-Endpunkt des Mandanten ohne diesen Connector und ist für interne Empfänger vorgesehen.

Sollte SMTP AUTH für jedes Postfach aktiviert sein?

Nein. Microsoft empfiehlt, es organisationsweit zu deaktivieren und nur für Postfächer zu aktivieren, die es noch benötigen, und moderne Authentifizierung sowie unterstützte Alternativen zu bevorzugen.

Bedeutet die Annahme durch Office-365-SMTP Zustellung in den Posteingang?

Nein. Annahme ist ein eng begrenztes Transportergebnis. Spätere Zustellung, Nichtzustellung, Filterung beim Empfänger, Ablage in einem Postfachordner und Engagement von Personen bleiben getrennte Nachweise.

Kann eine Anwendung Port 465 für die Microsoft-Client-Submission verwenden?

Laut aktuellem Microsoft-Leitfaden unterstützt ein Gerät, das standardmäßig Port 465 verwendet, die für diese Microsoft-365-Route erforderlichen TLS-Versionen der Client-Submission nicht.

Wo sollte ich eine Microsoft-365-SMTP-Konfiguration verifizieren?

Verwenden Sie aktuelle Microsoft-Learn-Dokumentation und testen Sie den gewählten Weg in Ihrem Mandanten, bevor Sie sich für Produktiv-E-Mails darauf verlassen.

Quellen

Weiterlernen

Einen SMTP-Relay-Dienst bewertenBewerten Sie SMTP-Relay-Dienste nach Submission-Sicherheit, Authentifizierung, Warteschlangen, Wiederholungsverhalten, Limits, Zustell-Events, Sperrlisten, Isolation und Eignung für die Migration.Leitfaden zur Bewertung des Google-SMTP-Relay-DienstesBewerten Sie das SMTP-Relay von Google Workspace nach Autorisierungsmodell, TLS, Absenderidentität, Kontingenten, Fehlerbehandlung, Authentifizierung, Beobachtbarkeit und Migrationsrisiko.SMTP-Protokoll: Wie E-Mails aus Anwendungen übertragen werdenErfahren Sie, wie SMTP-Submission, Relay, Envelopes, Antwortcodes, TLS, Wiederholungsversuche und Nachrichteninhalte den E-Mail-Workflow einer Anwendung prägen.SMTP-Ports 25, 465 und 587: PraxisleitfadenWählen Sie den passenden SMTP-Port nach Rolle und TLS-Modus und diagnostizieren Sie Fehler bei Verbindung, Handshake, Authentifizierung und Nachrichtenannahme.Einen Dienst für E-Mail-Zustellbarkeit bewertenBewerten Sie Dienste für E-Mail-Zustellbarkeit nach Umfang, Nachweisen, Authentifizierung, Feedback-Loops, Sperrlisten, Datenschutz, Portabilität und betrieblicher Eignung.