E-Mail-Absender konfigurieren

Auf der Seite E-Mail-Absender legst du fest, wie octoja Alarme, Berichte und Benutzereinladungen versendet.

Voraussetzungen

• Du musst Mitglied einer Administratorgruppe sein.
• Für einen eigenen SMTP-Server oder Microsoft 365 benötigst du die Verbindungs- und Zugangsdaten deines Anbieters.

Schritte

1. Öffne Einstellungen → E-Mail-Absender.
2. Wähle die Versandart:
   • octoja-Standard verwendet den von octoja bereitgestellten Versand.
   • Eigener SMTP-Server verwendet deinen SMTP-Server.
   • Microsoft 365 verwendet Microsoft Graph mit deinen Anwendungsdaten.
3. Trage bei einem eigenen Anbieter die angezeigten Pflichtfelder ein. Dazu gehören Absenderadresse und Verbindungsdaten; der Absendername ist optional.
4. Klicke auf Test-E-Mail senden und bestätige, dass die Nachricht angekommen ist.
5. Klicke auf Änderungen speichern.

Wenn du keinen Absendernamen einträgst, verwendet octoja zuerst den Fenstertitel aus White-Labeling. Ist auch dieser leer, wird der octoja-Standardname verwendet. Ein ausdrücklich eingetragener Absendername hat immer Vorrang.

Microsoft 365 einrichten

Für Microsoft 365 versendet octoja über die Microsoft-Graph-API mit Anwendungsberechtigungen — ohne Benutzerpasswort und ohne SMTP AUTH. Dafür brauchst du eine App-Registrierung in Microsoft Entra; die drei Werte daraus trägst du unter Microsoft-365-App-Registrierung ein. Du benötigst dafür Administratorrechte im Microsoft-365-Mandanten.

1. Melde dich im Microsoft Entra Admin Center an und öffne App-Registrierungen → Neue Registrierung. Vergib einen Namen wie octoja E-Mail-Versand, wähle unter Unterstützte Kontotypen die Option Nur Konten in diesem Organisationsverzeichnis, lass den Umleitungs-URI leer und klicke auf Registrieren.
2. Kopiere aus der Übersicht der App die Anwendungs-ID (Client) und die Verzeichnis-ID (Mandant). Das sind die gleichnamigen Felder in octoja.
3. Öffne Zertifikate und geheime Schlüssel und klicke auf Neuer geheimer Clientschlüssel. Kopiere den Wert sofort — er wird später nicht mehr angezeigt — und trage ihn in octoja unter Client-Secret ein. Notiere das Ablaufdatum: Läuft das Geheimnis ab, schlägt der Versand fehl, bis du in octoja ein neues einträgst.
4. Öffne API-Berechtigungen → Berechtigung hinzufügen → Microsoft Graph → Anwendungsberechtigungen und füge Mail.Send und Mail.ReadWrite hinzu. Mail.ReadWrite braucht octoja für Berichte mit großen Anhängen (zum Beispiel PDF-Berichte ab etwa 2,5 MB), die über einen Nachrichtenentwurf gesendet werden. Ohne diese Berechtigung gelingt die Test-E-Mail, größere Berichte scheitern aber. Klicke anschließend auf Administratorzustimmung erteilen für … (gefolgt vom Namen deines Mandanten) und prüfe, dass der Status beider Berechtigungen als erteilt angezeigt wird. Eine delegierte Berechtigung reicht nicht.
5. Trage in octoja unter Absenderadresse ein vorhandenes Postfach dieses Mandanten ein, zum Beispiel alarme@example.com. Ohne weitere Einschränkung darf die App über jedes Postfach des Mandanten senden; beschränke sie in Exchange Online über eine Anwendungszugriffsrichtlinie auf dieses Postfach.
6. Klicke auf Test-E-Mail senden. Kommt die Nachricht an, klicke auf Änderungen speichern. Scheitert der Test mit Access is denied, sieh dir die FAQ unten an.

FAQ

Welche Quell-IP muss ich für mein SMTP-Relay freigeben?

octoja verbindet sich mit dem eingetragenen SMTP-Host auf dem konfigurierten Port; die Firewall vor dem Mailserver muss diese Verbindung erlauben. Frage den octoja-Support nach den aktuellen ausgehenden Quell-IPs für deine octoja-Instanz und den SMTP-Versand, bevor du den Versand umstellst.

Verwende dafür nicht die IP-Adressen deiner octoja-Webadresse; die ausgehende Quell-IP kann sich ändern. Siehe IP-Adressen und Firewall-Freigaben. Öffne das Relay nicht für beliebige Absender, um einen fehlgeschlagenen Verbindungstest zu umgehen.

Warum meldet der Microsoft-365-Test Access is denied?

Prüfe in der Entra-App-Registrierung, dass Microsoft Graph Mail.Send als Anwendungsberechtigung und nicht als delegierte Berechtigung eingetragen ist und die Administratorzustimmung erteilt wurde. Der Absender muss ein vorhandenes Postfach dieses Mandanten sein, auf das die App gemäß den Exchange-Anwendungszugriffsbeschränkungen zugreifen darf. Kommt die Test-E-Mail an, scheitern aber Berichte mit großen Anhängen, fehlt in der Regel die Anwendungsberechtigung Mail.ReadWrite.

Diese Verbindung nutzt Anwendungszugangsdaten, nicht SMTP AUTH. Deaktiviere keine MFA, erstelle kein App-Passwort und entferne Zugriffsbeschränkungen nicht pauschal. Warte, bis Berechtigungsänderungen wirksam sind, und wiederhole den Test. Scheitert er weiterhin, schicke dem Support die Meldung und den Testzeitpunkt, niemals das Clientgeheimnis.