Microsoft 365 · Anwendungsversand
Eine Website, Fachanwendung oder ein Gerät benötigt keinen beliebigen SMTP-Zugang, sondern einen Versandweg, der zu Empfängerkreis, Volumen, technischer Fähigkeit und Schutzbedarf passt. Microsoft Graph, authentifizierte SMTP-Übermittlung, SMTP-Relay, Direct Send, High Volume Email und Azure Communication Services erfüllen unterschiedliche Aufgaben. Eine sichere Integration legt deshalb zuerst Absenderidentität, externe oder interne Empfänger, Fehlerbehandlung und verantwortlichen Betrieb fest.
Die Kurzantwort: Empfängerkreis und technische Fähigkeit entscheiden über den Versandweg
Eine moderne Anwendung mit OAuth-Unterstützung wird anders angebunden als ein älterer Scanner. Interne Alarmmeldungen benötigen keinen externen Massenversanddienst; Rechnungen an Kunden dürfen umgekehrt nicht über einen nur intern zulässigen Weg laufen.
| Ausgangslage | Geeigneter Ansatz | Wesentliche Grenze |
|---|---|---|
| Eigene Anwendung mit moderner API-Anbindung | Microsoft Graph sendMail | OAuth-Berechtigungen und Postfachzugriff müssen begrenzt werden |
| Gerät oder Anwendung unterstützt SMTP mit OAuth | Authentifizierte SMTP-Übermittlung | SMTP AUTH und Authentifizierung müssen für den vorgesehenen Weg zulässig sein |
| Feste öffentliche IP oder Zertifikat, Versand auch extern | Microsoft-365-SMTP-Relay über Connector | Port 25, kontrollierte Quellidentität und Connectorbetrieb erforderlich |
| Einfaches Gerät sendet ausschließlich an eigene Postfächer | Direct Send an den Microsoft-365-MX | Keine Zustellung an externe Empfänger |
| Sehr viele interne Benachrichtigungen | High Volume Email | Nur interne Empfänger; Dienstvoraussetzungen und Grenzen prüfen |
| Hoher externer Transaktions- oder Massenversand | Azure Communication Services Email oder spezialisierter Versanddienst | Eigene Domainkonfiguration, Kosten, Reputation und Anwendungsintegration |
Sechs Entscheidungen vor jeder Konfiguration
- Welche Anwendung oder welches konkrete Gerät sendet?
- Gehen Nachrichten nur intern oder auch an externe Empfänger?
- Welche sichtbare Absender- und Antwortadresse wird verwendet?
- Unterstützt das System OAuth, API, aktuelles TLS und zuverlässige Fehlerbehandlung?
- Welches normales, maximales und kurzfristiges Versandvolumen ist zu erwarten?
- Wer überwacht Fehler, erneuert Zugangsdaten und verantwortet den Inhalt?
1. Die Anforderung wird als vollständiger Nachrichtenprozess beschrieben
„Der Scanner soll mailen“ beschreibt noch keine betriebsfähige Integration. Benötigt werden Auslöser, Inhalt, Empfänger, Rücklaufweg und Reaktion auf Fehler.
Transaktionsmail, Benachrichtigung und Massenversand werden getrennt
Eine Rechnung oder Terminbestätigung gehört zu einem konkreten Geschäftsvorgang und muss eindeutig diesem Vorgang zugeordnet werden. Eine interne Systemwarnung richtet sich an einen begrenzten Empfängerkreis. Ein Newsletter erreicht dagegen viele externe Personen und benötigt Listenpflege, Einwilligungs- beziehungsweise Berechtigungsgrundlage sowie eine wirksame Abmeldung.
Diese Nachrichtentypen werden nicht ungeprüft über dasselbe Postfach und dieselbe Infrastruktur versendet. Störungen, Beschwerden oder Volumenspitzen eines Newsletters sollen geschäftskritische Transaktionsmails nicht beeinträchtigen. Eine getrennte Subdomain oder ein spezialisierter Versanddienst kann diese Verantwortung klarer abbilden.
Interne und externe Empfänger sind eine technische Systemgrenze
Direct Send und High Volume Email sind für interne Ziele vorgesehen. Eine Konfiguration kann daher bei einer Adresse der eigenen Microsoft-365-Organisation funktionieren und bei einem Kundenpostfach erwartungsgemäß scheitern. Der Testplan enthält von Anfang an beide Empfängerarten, sofern die Anwendung extern senden soll.
Auch scheinbar interne Adressen können über Kontakte, Weiterleitungen oder eine andere Organisation geführt werden. Maßgeblich ist der tatsächliche Zustellweg, nicht die vertraute Schreibweise der Domain. Koexistenz mit einem lokalen Mailserver oder vorgeschalteten Gateway wird als eigene Architektur dokumentiert.
Volumen wird als Normalwert, Spitze und Fehlerfall erfasst
Ein Gerät versendet vielleicht zehn Scans am Tag, eine Warenwirtschaft mehrere hundert Belege und ein Monitoring bei einem Fehler plötzlich tausende identische Warnungen. Deshalb werden durchschnittliche Menge, erwartbare Spitze, maximale Empfängerzahl pro Nachricht und Verhalten bei einem Rückstau getrennt festgelegt.
Microsoft-365-Dienste besitzen Empfänger-, Nachrichten- und Durchsatzgrenzen, die dem Schutz des Dienstes dienen und sich ändern können. Sie sind keine zugesicherte Kapazität für beliebige Massenanwendungen. Hoher externer Versand wird auf einer dafür vorgesehenen Plattform geplant.
Fehler und Antworten benötigen einen betreuten Rückkanal
Die sichtbare Absenderadresse, Envelope-From-Adresse und Reply-To-Adresse können verschiedene Aufgaben erfüllen. Unzustellbarkeitsberichte müssen von einem System oder einer Person ausgewertet werden. Antworten von Kunden dürfen nicht in einem unbeobachteten Postfach enden.
Eine Adresse wie noreply@ verhindert technisch keine Antwort und vermittelt keine Zuständigkeit. Für Rechnungen, Terminbestätigungen oder Supportvorgänge wird ein erreichbarer Rückkanal festgelegt. Automatische Antworten und eingehende Bounces werden so verarbeitet, dass keine Mail-Schleifen entstehen.
2. Jeder Microsoft-Versandweg besitzt einen klaren Einsatzbereich
Die technisch einfachste Verbindung ist nicht automatisch die sicherste oder dauerhaft tragfähigste. Neue Integrationen werden auf moderne Authentifizierung und begrenzte Rechte ausgerichtet.
Microsoft Graph passt zu Anwendungen mit moderner Identitätsintegration
Eine Anwendung kann über Microsoft Graph Nachrichten aus einem Benutzer- oder Funktionspostfach senden. Sie authentifiziert sich über Microsoft Entra ID und erhält delegierte Rechte im Benutzerkontext oder Anwendungsrechte für einen Hintergrunddienst. Der API-Aufruf sendMail übergibt Nachricht, Empfänger und Anhänge an Microsoft 365.
Eine erfolgreiche API-Antwort bestätigt die Annahme des Auftrags, nicht die endgültige Zustellung beim Empfänger. Die Anwendung protokolliert daher Korrelationsdaten und verarbeitet fachliche Rückmeldungen. Bei Anwendungsrechten wird der Zugriff auf die tatsächlich benötigten Postfächer begrenzt, statt organisationsweiten Versand aus jedem Postfach zu erlauben.
Authentifizierte SMTP-Übermittlung bleibt an SMTP AUTH und moderne Anmeldung gebunden
Geräte und Anwendungen können über den Microsoft-365-SMTP-Endpunkt senden, wenn sie die erforderliche TLS-Version und eine unterstützte Authentifizierung beherrschen. SMTP AUTH kann organisationsweit oder am betreffenden Postfach deaktiviert sein. Es wird nur für das dafür vorgesehene Konto und den dokumentierten Zweck aktiviert.
Eine neue Integration wird nicht auf dauerhaft gespeicherter Benutzername-Kennwort-Basisauthentifizierung aufgebaut. Microsoft hat deren Abschaffung für SMTP AUTH angekündigt und verweist für aktuelle Meilensteine auf die laufend aktualisierten Hinweise. Unterstützt das System OAuth nicht, wird ein anderer Versandweg oder eine vorgelagerte, kontrollierte Komponente gewählt.
SMTP-Relay verwendet einen Connector und eine nachweisbare Quelle
Beim Microsoft-365-SMTP-Relay nimmt Exchange Online Nachrichten über den tenantbezogenen MX-Endpunkt an und erkennt die berechtigte Quelle anhand einer festen öffentlichen IP-Adresse oder eines passenden Zertifikats. Ein Inbound-Connector bildet diese Vertrauensbeziehung ab. Der Weg kann interne und externe Empfänger erreichen.
Er setzt Port 25, eine kontrollierte Ausgangsinfrastruktur und eine stabile Identität voraus. Dynamische Privatkundenanschlüsse oder wechselnde Cloud-IP-Adressen eignen sich nicht für eine IP-basierte Freigabe. Der Connector wird eng auf die vorgesehene Quelle begrenzt und darf kein allgemein nutzbares offenes Relay erzeugen.
Direct Send ist eine einfache Lösung für ausschließlich interne Empfänger
Ein Gerät sendet per SMTP an den MX-Endpunkt der eigenen Microsoft-365-Domain. Es benötigt dafür keine Anmeldung an einem Benutzerpostfach, kann aber keine externen Empfänger über Microsoft 365 beliefern. Der Absender verwendet eine Adresse einer akzeptierten Domain, und der Netzwerkweg zu Port 25 muss funktionieren.
Direct Send passt beispielsweise zu einem Scanner, der ausschließlich an interne Mitarbeiterpostfächer sendet. Sobald Kunden, private Adressen oder externe Partner erreicht werden sollen, ist es der falsche Weg. Eine erfolgreiche interne Testmail darf daher nicht als Freigabe für externe Zustellung interpretiert werden.
High Volume Email adressiert große interne Nachrichtenmengen
Microsoft beschreibt High Volume Email für Anwendungen und Geräte, die viele interne Nachrichten versenden. HVE-Konten dürfen nicht für externe Zustellung verwendet werden. Voraussetzungen, Verfügbarkeit und aktuelle Dienstgrenzen werden im eigenen Mandanten geprüft, bevor dieser Weg geplant wird.
Für umfangreiche externe Transaktions-, Benachrichtigungs- oder Marketingmails nennt Microsoft Azure Communication Services Email als Anwendungsplattform. Alternativ kann ein spezialisierter Versanddienst eingesetzt werden. Beide Varianten benötigen eine verifizierte Domain, passende Authentifizierung, Fehlerverarbeitung und laufende Reputationspflege.
Ausschlussfragen für die Vorauswahl
- Externe Empfänger erforderlich? Direct Send und HVE scheiden aus.
- Keine feste öffentliche IP und kein Zertifikat? IP- oder zertifikatbasiertes SMTP-Relay ist nicht ohne Weiteres möglich.
- Keine moderne SMTP-Authentifizierung? Neue SMTP-AUTH-Integration nicht mit einem gespeicherten Benutzerkennwort planen.
- Hoher externer Durchsatz? Benutzerpostfach und normale Microsoft-365-Übermittlung sind keine Massenmailplattform.
- Anwendung kann OAuth und API? Graph und begrenzte Anwendungsrechte bevorzugt prüfen.
- Nur wenige interne Gerätemails? Direct Send kann die einfachste passende Lösung sein.
3. Versandidentität und Berechtigungen werden auf die tatsächliche Aufgabe begrenzt
Ein technischer Versandweg darf nicht unbemerkt Zugriff auf sämtliche Postfächer oder die Identität eines Mitarbeiters erhalten.
Personenkonten werden nicht als gemeinsame Systemidentität verwendet
Ein Scanner oder eine Warenwirtschaft meldet sich nicht mit dem Kennwort einer realen Person an. Bei Austritt, Kennwortwechsel oder Mehrfaktoranmeldung würde der Versand unkontrolliert ausfallen; zugleich ließen sich Benutzer- und Systemaktivität schwer unterscheiden.
Stattdessen erhält der Prozess eine dokumentierte technische Identität, ein festgelegtes Absenderpostfach oder eine API-Anwendung. Eigentümer, Zweck, Berechtigungen und Erneuerungsfrist werden im Betriebsverzeichnis geführt. Die sichtbare Adresse beschreibt den Geschäftsprozess verständlich.
Graph-Anwendungsrechte erhalten einen Postfachumfang
Die Graph-Berechtigung Mail.Send als Anwendungsrecht kann ohne Benutzerinteraktion arbeiten. Eine organisationsweite unbeschränkte Freigabe wäre für viele Integrationen weiter als nötig. Exchange Online unterstützt Application RBAC, um einer Anwendung Rollen in Verbindung mit einem Ressourcenumfang zuzuweisen.
Dabei wird beachtet, dass Berechtigungen aus Microsoft Entra ID und Exchange Application RBAC unabhängig wirken und sich addieren können. Eine alte organisationsweite Entra-Berechtigung wird entfernt, wenn ausschließlich die begrenzte Exchange-Zuweisung gelten soll. Der Zugriff wird anschließend für erlaubte und ausdrücklich nicht erlaubte Postfächer getestet.
Geheimnisse und Zertifikate besitzen Ablage, Ablauf und Wechselverfahren
Client Secrets, Zertifikate und SAS-ähnliche Zugangsdaten werden nicht im Quellcode, in öffentlich lesbaren Konfigurationsdateien oder Tickets gespeichert. Sie liegen in einem geeigneten Secretspeicher und sind nur für den ausführenden Dienst sowie zuständige Administratoren erreichbar.
Vor Ablauf wird ein zweites gültiges Geheimnis oder Zertifikat bereitgestellt, die Anwendung umgestellt und die alte Berechtigung erst nach erfolgreichem Test entfernt. Der Prozess vermeidet einen ungeplanten Versandstopp und begrenzt gleichzeitig die Gültigkeit kompromittierter Daten.
Connectoren vertrauen einer Infrastruktur und nicht beliebigen internen Geräten
Mehrere Geräte können über einen kontrollierten internen Relayhost senden, der Warteschlange, Protokollierung, TLS und Weiterleitung zu Microsoft 365 übernimmt. Microsoft 365 vertraut dann der festen öffentlichen IP oder dem Zertifikat dieses Relayhosts. Die einzelnen Geräte erhalten keinen direkten organisationsweiten Relayzugang.
Der interne Relayhost begrenzt erlaubte Quellnetze, Absenderdomains und Empfänger. Er ist kein offenes Relay und besitzt eigene Überwachung. Diese Architektur kann ältere Geräte kapseln, erzeugt aber eine zusätzliche Betriebskomponente, deren Verfügbarkeit und Aktualisierung verantwortlich geplant werden müssen.
4. DNS und Nachrichtengestaltung machen den Versandweg für Empfänger nachvollziehbar
Technische Annahme und vertrauenswürdige Zustellung sind verschiedene Qualitätsstufen. Die gewählte Absenderdomain wird passend authentifiziert und der Nachrichtentyp eindeutig gestaltet.
SPF erfasst den tatsächlichen Envelope-From-Weg
SPF prüft, ob die sendende IP für die Domain der SMTP-Rücklaufadresse autorisiert ist. Bei Microsoft 365, SMTP-Relay und spezialisierten Diensten können unterschiedliche Domains und Mechanismen beteiligt sein. Die Richtlinie wird nicht anhand des sichtbaren From-Felds geraten, sondern aus dem realen Header einer Testnachricht abgeleitet.
Pro Domain existiert eine konsolidierte SPF-Richtlinie. Nicht mehr verwendete Plattformen werden entfernt, und die Zahl DNS-auslösender Mechanismen bleibt innerhalb der Spezifikation. Eine zu breite Autorisierung erhöht das Risiko und garantiert trotzdem keine DMARC-Ausrichtung.
DKIM und DMARC verbinden den Dienst mit der sichtbaren Absenderdomain
Microsoft 365 und geeignete Versandplattformen signieren Nachrichten mit DKIM. Für DMARC muss die Signaturdomain oder die SPF-geprüfte Domain zur sichtbaren Absenderdomain ausgerichtet sein. Kundenspezifische DKIM-CNAMEs und Return-Path-Domains werden aus dem richtigen Anbieterprojekt übernommen und anschließend mit einer realen Nachricht geprüft.
DMARC-Aggregatberichte zeigen später, ob der neue Versandweg bei verschiedenen Empfängern ausgerichtet bestanden hat. Eine strenge Richtlinie wird nicht gelockert, um eine einzelne falsch integrierte Anwendung zu kaschieren; stattdessen erhält die Anwendung eine korrekte Identität.
From, Reply-To und Rückläufer erfüllen nachvollziehbare Rollen
Eine Rechnung zeigt eine zum Unternehmen und Vorgang passende Absenderadresse. Antworten erreichen die zuständige Stelle. Technische Rückläufer können an eine getrennte Adresse oder Plattform gehen, müssen dort aber ausgewertet werden. Der sichtbare Anzeigename täuscht weder eine Person noch eine fremde Organisation vor.
Links verwenden kontrollierte Domains und nachvollziehbare Ziele. Automatische Nachrichten enthalten einen klaren Anlass, eine Vorgangsreferenz und eine Kontaktmöglichkeit. Marketinginhalte, Tracking und umfangreiche Kampagnen werden nicht unbemerkt in operative Belegmails eingebaut.
Nachweis der Absenderidentität
- Sichtbare From-, Reply-To- und Envelope-From-Adresse sind dokumentiert.
- SPF besteht für die tatsächlich verwendete Rücklaufdomain.
- DKIM besteht mit dem vorgesehenen Selektor und einer kontrollierten Domain.
- DMARC besteht über mindestens einen ausgerichteten Mechanismus.
- Rückläufer und Antworten erreichen eine betreute Verarbeitung.
- Die Versandquelle erscheint im DMARC- und Anwendungsverzeichnis des Unternehmens.
5. Zuverlässiger Versand benötigt Warteschlange, Wiederholungen und nachvollziehbare Protokolle
Ein Versandaufruf kann scheitern, zeitweise verzögert sein oder erfolgreich angenommen werden, ohne den endgültigen Zielordner zu beweisen. Die Anwendung muss diese Zustände unterscheiden.
Temporäre und endgültige Fehler lösen unterschiedliche Reaktionen aus
SMTP-Antworten der 4xx-Klasse und zeitweilige API-Fehler werden nach einem begrenzten Wiederholungsplan erneut versucht. 5xx-Ablehnungen, ungültige Empfänger oder fehlende Berechtigungen benötigen dagegen eine Korrektur. Endlose sofortige Wiederholungen verschärfen Störungen und können Duplikate erzeugen.
Die Warteschlange besitzt maximale Dauer, abgestufte Intervalle und einen klaren Fehlerzustand. Geschäftskritische Vorgänge werden nicht als „erledigt“ markiert, solange nur der Versandauftrag lokal erzeugt wurde. Der Fachprozess zeigt, ob die Nachricht angenommen, endgültig abgelehnt oder zur Prüfung zurückgestellt ist.
Eine fachliche Nachrichten-ID verhindert unkontrollierte Duplikate
Rechnung, Termin oder Alarm erhalten eine eindeutige Vorgangskennung. Die Anwendung protokolliert, welche Versandanforderung zu welchem Versuch und welcher Message-ID gehört. Nach einem Timeout wird nicht blind eine neue unabhängige Nachricht erzeugt, wenn der erste Auftrag möglicherweise bereits angenommen wurde.
Bei wiederholbaren API-Aufrufen wird ein anwendungseigenes Idempotenzverfahren geplant. Wo der verwendete Dienst keine echte Idempotenz garantiert, prüft die Anwendung ihren eigenen Status und kennzeichnet Wiederholungen nachvollziehbar.
Protokolle enthalten technische Belege, aber keine unnötigen Nachrichtendaten
Erfasst werden Zeit, Anwendung, Absender, Empfängerzahl, Vorgangskennung, verwendeter Weg, Antwortcode, Korrelations- oder Message-ID und endgültiger Status. Vollständige Nachrichtentexte, Anhänge und Zugangsdaten gehören nicht pauschal in Diagnoseprotokolle.
Zugriff, Aufbewahrungsdauer und Löschung der Protokolle folgen dem betrieblichen Bedarf. Warnungen werden an eine betreute Stelle gesendet und so zusammengefasst, dass ein fehlerhafter Prozess nicht selbst tausende Alarmmails erzeugt.
Änderungen an Gerät, Anwendung und Microsoft 365 bleiben synchron
Firmwareupdates, neue TLS-Anforderungen, Zertifikatswechsel oder Microsoft-Dienständerungen können einen bestehenden Weg beeinflussen. Verantwortliche prüfen Ankündigungen des Herstellers und des Versanddienstes. Vor einer Abschaltung alter Verfahren steht ein getesteter Ersatz bereit.
Das Betriebsblatt nennt Endpunkt, Port, Authentifizierungsart, Absender, Empfängerkreis, verantwortliche Anwendungsversion und Ablaufdaten. Es enthält keine geheimen Werte, verweist aber auf deren geschützte Ablage.
6. Die Abnahme prüft Funktion, Grenzen und Fehlerverhalten des vollständigen Wegs
Eine einzelne angekommene Testmail belegt nur einen Teil der Integration. Der Testplan umfasst erlaubte und bewusst nicht erlaubte Fälle.
Positive Tests bilden reale Geschäftsvorgänge ab
Ein Scanner sendet eine mehrseitige Datei, die Warenwirtschaft eine Rechnung mit richtigem Betreff und die Website eine Anfrage mit Umlauten sowie einer realistischen Antwortadresse. Interne und externe Empfänger werden entsprechend dem freigegebenen Umfang geprüft. Anhänge, Zeichenkodierung und Absenderanzeige müssen beim Ziel korrekt erscheinen.
Originalheader belegen Transportweg, SPF, DKIM und DMARC. Antworten und Unzustellbarkeitsberichte erreichen die vorgesehenen Stellen. Bei Microsoft 365 wird der Nachrichtenweg zusätzlich über die Ablaufverfolgung kontrolliert.
Negative Tests bestätigen die Begrenzung der Rechte
Direct Send darf keine externe Adresse beliefern. Eine Graph-Anwendung darf nicht aus einem Postfach außerhalb ihres Ressourcenumfangs senden. Ein Relay akzeptiert keine Verbindung von einer fremden IP oder mit einem unzulässigen Absender. Diese abgewiesenen Fälle sind ein wesentlicher Sicherheitsnachweis.
Auch abgelaufene oder entzogene Zugangsdaten werden in einer kontrollierten Testumgebung erkannt. Die Anwendung darf Fehler nicht als Erfolg verbuchen oder Geheimnisse im Protokoll ausgeben.
Last- und Störungstests prüfen das Verhalten unter realistischen Grenzen
Die freigegebene Spitzenlast wird ohne künstlichen Massenversand an fremde Empfänger erprobt. Temporäre Drosselung oder Nichterreichbarkeit erzeugt kontrollierte Wiederholungen, keine Nachrichtenschleife. Ein voller interner Puffer löst eine sichtbare Störung aus, bevor Geschäftsvorgänge unbemerkt verloren gehen.
Nach Wiederherstellung werden Warteschlange und Duplikatverhalten geprüft. Die Anwendung verarbeitet den Rückstau in einem angemessenen Tempo und überlastet den Dienst nicht durch gleichzeitige Sofortwiederholungen.
Abnahmeprotokoll des Anwendungsversands
- Freigegebener Versandweg, Absender und interner beziehungsweise externer Empfängerkreis
- Bestandene reale Nachrichten mit korrekten Inhalten, Anhängen und Antworten
- Bestandene SPF-, DKIM- und DMARC-Prüfung am unabhängigen Empfänger
- Nachgewiesene Sperre unzulässiger Postfächer, Quellen und Empfängerwege
- Kontrollierte Behandlung temporärer und endgültiger Fehler ohne Duplikatschleife
- Dokumentierte Verantwortung für Monitoring, Zugangsdatenwechsel und Dienständerungen
Häufige Fragen zum E-Mail-Versand von Anwendungen und Geräten
Kann ein Scanner ohne Microsoft-365-Lizenz E-Mails senden?
Für ausschließlich interne Empfänger kann Direct Send ohne Anmeldung an einem lizenzierten Postfach passen. Für SMTP-Relay ist ebenfalls nicht automatisch ein Benutzerpostfach nötig, der Connector benötigt jedoch eine kontrollierte Quellidentität. Die konkrete Gerätefähigkeit und der Empfängerkreis entscheiden.
Warum funktioniert Direct Send intern, aber nicht an Kunden?
Direct Send ist nach Microsofts Vorgabe für Empfänger in der eigenen Microsoft-365-Organisation bestimmt und kann nicht über Microsoft 365 an externe Ziele relayen. Für externe Empfänger wird ein anderer, dafür zugelassener Versandweg benötigt.
Ist SMTP AUTH mit Benutzername und Kennwort noch eine gute neue Lösung?
Nein. Microsoft hat die Abschaffung der Basisauthentifizierung für SMTP AUTH angekündigt. Neue Integrationen werden mit OAuth, Microsoft Graph, einem korrekt begrenzten SMTP-Relay oder einer passenden Versandplattform geplant. Aktuelle Fristen werden unmittelbar in Microsofts Ankündigungen geprüft.
Kann eine Graph-Anwendung aus jedem Postfach senden?
Ein unbeschränkt gewährtes Mail.Send-Anwendungsrecht kann sehr weit reichen. Exchange Application RBAC ermöglicht eine Begrenzung auf definierte Postfächer. Zusätzlich müssen alte, organisationsweite Entra-Berechtigungen entfernt werden, wenn sie den begrenzten Umfang sonst überlagern.
Welcher Weg passt zu vielen externen Transaktionsmails?
Dafür wird eine Anwendungsplattform wie Azure Communication Services Email oder ein spezialisierter Transaktionsmaildienst geprüft. Normale Benutzerpostfächer und High Volume Email sind nicht als beliebige externe Massenversandlösung vorgesehen.
Technische Quellen
Microsoft 365 in Frankfurt
Eine Anwendung oder ein Gerät soll zuverlässig E-Mails senden?
fra.digital wählt den passenden Versandweg, begrenzt Identitäten und Berechtigungen und prüft den vollständigen Nachrichtenprozess einschließlich Fehlerfällen und Absenderauthentifizierung.
