E-Mails von der eigenen Adresse versenden Anleitung

Standardmäßig verschickt 2LRN4 alle E-Mails an deine Teilnehmer von einer eigenen Adresse. Das funktioniert, aber die Mitarbeiter erkennen den Absender nicht immer. Du kannst deshalb einstellen, dass die E-Mail von der Adresse deiner Organisation kommt und sogar tatsächlich aus eurer eigenen Mailumgebung verschickt wird. Seit August 2026 ist das für jede Organisation möglich; davor war es Kunden mit einer Microsoft-Umgebung vorbehalten.

Die Auswahl findest du bei Organisationen → deine Organisation → bearbeiten, unter der Überschrift Support, bei Versandweg für diese Organisation.

Die vier Versandwege

Versandweg	Wer verschickt	Was du dafür brauchst
Über 2LRN4 (Standard)	2LRN4	nichts
Aus dem eigenen Microsoft-Postfach	euer Microsoft 365	eine Entra-Verbindung mit Versandrechten
Aus dem eigenen Google-Postfach	euer Google Workspace	ein Dienstkonto mit domainweiter Delegierung
Über den eigenen Mailserver der Organisation (SMTP)	euer Mailserver	Server, Port und Zugangsdaten

Welcher passt, hängt davon ab, wo eure Mail läuft. Seid ihr auf Microsoft 365 oder Google Workspace, dann wähle den zugehörigen Versandweg. Das ergibt die beste Zustellung, weil die Mail dann wirklich aus eurer eigenen Umgebung kommt.

Über 2LRN4 (Standard)

Die Mail wird von uns verschickt. Trägst du bei Support-E-Mail eine Adresse deiner eigenen Organisation ein, erscheint diese als Absender; lässt du das Feld leer, verwenden wir die Adresse von 2LRN4.

Achtung bei einer eigenen Adresse auf diesem Weg. Die Mail kommt dann von deiner Adresse, wird aber von unserem Server verschickt. Viele Organisationen haben in ihrem DNS festgelegt, wer im Namen ihrer Domain versenden darf (SPF, DKIM und DMARC). Ist diese Einstellung streng, kann der empfangende Mailserver solche Nachrichten in den Spamordner legen oder sogar ablehnen. Bist du unsicher, sprich mit deinem IT-Administrator oder wähle einen der drei Wege weiter unten, denn dort spielt das keine Rolle.

Aus dem eigenen Microsoft-Postfach

Die Mail wird über Microsoft Graph aus einem Postfach in eurer eigenen Microsoft 365-Umgebung verschickt. Absender und Zustellung stimmen dann von selbst, weil die Mail einfach eure eigene Microsoft-Umgebung verlässt.

In der Plattform brauchst du drei Dinge:

Eine Entra-Verbindung bei dieser Organisation. Hast du noch keine, verweist dich der Bildschirm auf die Stelle, an der du eine anlegst. Siehe auch Benutzer synchronisieren.
Die App-Registrierung dieser Verbindung muss Mail versenden dürfen. Nutzt du eine bestehende Verbindung, die nur für die Benutzersynchronisation eingerichtet ist, hat sie dieses Recht meist noch nicht; unten steht, was dein IT-Administrator hinzufügt.
Die Adresse bei Support-E-Mail muss ein bestehendes Postfach in dieser Umgebung sein, mit Versandrechten. Ein Alias oder eine Adresse, die nur auf dem Papier existiert, funktioniert nicht.

Was dein IT-Administrator in Azure regelt, in der App-Registrierung der bestehenden Verbindung:

Öffne die App-Registrierung und gehe zu API-Berechtigungen.
Füge über Microsoft Graph → Application permissions eine Berechtigung hinzu und wähle Mail.Send. Verwende ausschließlich application permissions; delegated permissions funktionieren hier nicht, weil die Plattform ohne angemeldeten Benutzer verschickt.
Erteile die Administratorzustimmung (admin consent) für die neue Berechtigung.
Prüfe, ob die Absenderadresse ein gültiges Exchange Online-Postfach ist.
Beschränke die Berechtigung auf dieses eine Postfach. Das ist der wichtigste Schritt, und er wird oft übersprungen. Mail.Send gilt standardmäßig für die gesamte Umgebung: Die App-Registrierung darf dann technisch im Namen jeder Adresse in eurem Tenant verschicken, während wir nur eine davon nutzen. Mit einer application access policy (Anwendungszugriffsrichtlinie) in Exchange Online beschränkst du das auf das Postfach, das du hier einträgst.
Dein IT-Administrator macht das mit zwei Befehlen in der Exchange Online PowerShell. Lege das Postfach zuerst in eine Sicherheitsgruppe mit E-Mail-Adresse und verknüpfe die App-Registrierung damit:
```
New-DistributionGroup -Name "2LRN4 Versandpostfach" -Type Security `
  -PrimarySmtpAddress "2lrn4-versandpostfach@deinedomain.de" `
  -Members "noreply@deinedomain.de"

New-ApplicationAccessPolicy `
  -AppId "" `
  -PolicyScopeGroupId "2lrn4-versandpostfach@deinedomain.de" `
  -AccessRight RestrictAccess `
  -Description "2LRN4 darf nur aus dem Versandpostfach verschicken"
```
Prüfen, ob es geklappt hat:
```
Test-ApplicationAccessPolicy -Identity "noreply@deinedomain.de" -AppId ""
```
Das Ergebnis sollte für dieses Postfach Granted lauten und für jedes andere Denied. Rechne mit einer Stunde, bis die Einstellung überall übernommen ist.

Funktioniert es? Unten auf demselben Bildschirm steht die Schaltfläche Testnachricht senden. Sie schickt eine einzige Nachricht an deine eigene Adresse, auf genau demselben Weg wie die Mail an deine Teilnehmer. Speichere deine Änderungen zuerst, denn der Test nutzt die gespeicherten Einstellungen. Über der Schaltfläche steht das Ergebnis der letzten Prüfung, die wir jeden Morgen automatisch durchführen.

Bekommst du die Meldung, dass der eigene Weg nicht funktioniert hat und die Nachricht über 2LRN4 verschickt wurde, dann ist die Testnachricht zwar angekommen, aber die Einstellung stimmt noch nicht. Der Grund steht dann dabei.

Bekannte Fehlermeldungen auf diesem Weg und was dagegen zu tun ist:

Meldung	Ursache und Lösung
Insufficient privileges to send mail	Die Berechtigung `Mail.Send` fehlt; füge sie als application permission hinzu.
Mailbox not found	Die Absenderadresse existiert nicht als Postfach; verwende eine echte Adresse, keinen Alias.
Unauthorized / Access denied	Die Administratorzustimmung ist noch nicht erteilt.
Mail kommt nicht an	Prüfe mit deinem IT-Administrator die SPF-, DKIM- und DMARC-Einstellungen eurer Domain.

Aus dem eigenen Google-Postfach

Die Mail wird über die Gmail API aus einem Postfach in eurem Google Workspace verschickt. Absender und Zustellung stimmen dann von selbst, weil die Mail einfach eure eigene Google-Umgebung verlässt.

In der Plattform brauchst du drei Dinge:

Ein Dienstkonto in Google Cloud, mit einem JSON-Schlüssel. Weiter unten steht, wie dein Google-Administrator es anlegt.
Domainweite Delegierung für dieses Dienstkonto in der Google-Admin-Konsole, ausschließlich mit dem Scope https://www.googleapis.com/auth/gmail.send.
Die Adresse bei Support-E-Mail muss ein bestehendes Postfach in diesem Workspace sein. Das ist das Postfach, aus dem die Plattform verschickt; eine Gruppe oder ein Alias funktioniert nicht.

Was dein Google-Administrator einrichtet, in zwei Teilen: zuerst das Dienstkonto in Google Cloud, danach die Berechtigung in der Google-Admin-Konsole.

Teil 1: das Dienstkonto (Google Cloud Console)

Gehe zu console.cloud.google.com und wähle oder erstelle ein Projekt für eure Organisation, zum Beispiel "2LRN4 mail".
Aktiviere die Gmail API: gehe zu APIs und Dienste → Bibliothek, suche "Gmail API" und wähle Aktivieren. Ohne diesen Schritt lehnt Google jede Anfrage ab.
Lege das Dienstkonto an: IAM und Verwaltung → Dienstkonten → Dienstkonto erstellen. Gib ihm einen erkennbaren Namen, zum Beispiel "2lrn4-mail". Rollen sind nicht nötig; diesen Schritt kannst du überspringen.
Erstelle einen Schlüssel: öffne das Dienstkonto, gehe auf den Reiter Schlüssel und wähle Schlüssel hinzufügen → Neuen Schlüssel erstellen → JSON. Eine JSON-Datei wird heruntergeladen. Bewahre sie sicher auf, denn sie ist faktisch das Passwort dieses Kontos.
Notiere die Client-ID des Dienstkontos. Sie steht auf der Detailseite unter "Eindeutige ID" und ist eine Zahl mit etwa 21 Ziffern. Du brauchst sie in Teil 2.

Teil 2: Berechtigung, im Namen des Postfachs zu senden (Google-Admin-Konsole)

Gehe zu admin.google.com, wähle Sicherheit → Zugriffs- und Datenkontrolle → API-Steuerung und ganz unten Domainweite Delegierung verwalten.
Wähle Neu hinzufügen. Trage bei Client-ID die Zahl aus Teil 1, Schritt 5 ein und bei OAuth-Bereiche genau diesen einen Scope: https://www.googleapis.com/auth/gmail.send. Weitere Scopes sind nicht nötig, und du solltest sie auch nicht vergeben.
Wähle Autorisieren. Rechne mit einigen Minuten bis zu einer Stunde, bis die Einstellung überall wirksam ist.

Warum nur der Sende-Scope? Die domainweite Delegierung gilt für die gesamte Domain: Das Dienstkonto kann damit technisch im Namen jeder Adresse in eurem Workspace verschicken, auch wenn die Plattform nur eine davon nutzt. Mit ausschließlich gmail.send kann es zumindest nichts lesen oder verwalten. Wenn du es strenger willst, kannst du die Gmail API in der Admin-Konsole je Organisationseinheit einschränken; besprich das mit deinem IT-Administrator.

In der Plattform

Wähle den Versandweg Aus dem eigenen Google-Postfach der Organisation. Öffne die heruntergeladene JSON-Datei in einem einfachen Texteditor (keine Textverarbeitung) und füge den vollständigen Inhalt, von der ersten { bis zur letzten }, in das Feld Dienstkontoschlüssel (JSON) ein. Trage bei Support-E-Mail das Postfach ein, aus dem verschickt wird, und speichere.

Der Schlüssel wird verschlüsselt gespeichert und nach dem Speichern nicht mehr angezeigt; du siehst nur, zu welchem Dienstkonto er gehört. Willst du ihn später entfernen, geht das über das Kästchen Diesen Schlüssel entfernen; wähle dann zuerst einen anderen Versandweg, denn solange der Google-Weg gewählt ist, bleibt der Schlüssel erforderlich.

Bekannte Fehlermeldungen auf diesem Weg und was dagegen zu tun ist (die Begründungszeile selbst erscheint auf Niederländisch):

Meldung	Ursache und Lösung
Das sieht nicht wie ein Google-Dienstkontoschlüssel aus: client_email und private_key sind erforderlich	Der eingefügte Text ist nicht die vollständige JSON-Datei. Öffne die Datei in einem Texteditor und füge alles ein, von der ersten `{` bis zur letzten `}`.
Geen Google-token … unauthorized_client	Die domainweite Delegierung fehlt, steht auf einer anderen Client-ID, oder der Scope `gmail.send` ist nicht enthalten. Gehe Teil 2 noch einmal durch. Gerade erst eingerichtet? Dann warte kurz, es kann bis zu einer Stunde dauern.
Gmail weigerde het bericht … (HTTP 403)	Meist ist die Gmail API im Cloud-Projekt nicht aktiviert (Teil 1, Schritt 2), oder die Support-Adresse ist kein echtes Postfach in diesem Workspace.
Gmail weigerde het bericht … (HTTP 400)	Die Support-Adresse existiert nicht, oder sie ist eine Gruppe oder ein Alias. Verwende ein echtes Postfach.
Kon de JWT niet ondertekenen; is de private key geldig?	Der Schlüssel ist beschädigt, zum Beispiel weil eine Textverarbeitung Anführungszeichen oder Zeilenumbrüche verändert hat. Erstelle in Google Cloud einen neuen JSON-Schlüssel und füge ihn erneut ein.
Mail kommt nicht an	Prüfe mit deinem IT-Administrator die SPF-, DKIM- und DMARC-Einstellungen eurer Domain. Bei Google Workspace sind sie normalerweise bereits korrekt.

Über den eigenen Mailserver (SMTP)

Nutzt ihr weder Microsoft noch Google, kannst du euren eigenen Mailserver angeben: Server, Port, Verschlüsselung, Benutzername und Passwort. Das Passwort wird verschlüsselt gespeichert und nach dem Speichern nicht mehr angezeigt; lässt du das Feld bei einer späteren Änderung leer, bleibt das bestehende Passwort erhalten.

Prüfe mit deinem IT-Administrator, ob dieser Server im Namen eurer Domain versenden darf, sonst kann die Mail trotzdem abgelehnt werden.

Was passiert, wenn es schiefgeht

Klappt das Versenden über euren eigenen Weg nicht, zum Beispiel weil ein Passwort abgelaufen ist, eine Berechtigung entzogen wurde oder ein Postfach verschoben wurde, dann wird die Nachricht trotzdem verschickt, und zwar über 2LRN4. Dein Teilnehmer bekommt seine Passwortzurücksetzung oder seine Einladung also ganz normal; nur steht dann unsere Adresse als Absender darin, mit eurer Adresse als Antwortadresse. Das ist Absicht: Eine Nachricht mit eurer Domain als Absender, die von unserem Server kommt, kollidiert mit den SPF- und DMARC-Einstellungen eurer Domain und würde dann im Spamordner landen.

Gleichzeitig wird die Organisation markiert. Du siehst das auf dem Bildschirm mit dem Versandweg wieder, und wir sehen es in einer täglichen Prüfung, die pro Organisation feststellt, ob noch verschickt werden kann. Bei einem anhaltenden Problem melden wir uns bei dir.

Häufig gestellte Fragen

Ändert sich etwas für unsere Teilnehmer?

Nur der Absender. Inhalt, Gestaltung und der Zeitpunkt des Versands bleiben gleich.

Wir haben die alte Einstellung „Enable azure mailing“ genutzt. Müssen wir etwas tun?

Nein. Organisationen, die über Microsoft verschickt haben, wurden automatisch auf den Weg Aus dem eigenen Microsoft-Postfach umgestellt; alles funktioniert weiter wie bisher.

Können wir zum Standardweg zurück?

Ja, jederzeit. Stelle die Auswahl zurück auf Über 2LRN4; die Mail geht dann wieder von unserer Adresse aus. Gespeicherte Zugangsdaten bleiben erhalten, bis du sie selbst löschst, damit du später zurückwechseln kannst.

Gilt das auch für Phishing-Simulationen?

Nein. Die werden über eine separate Umgebung verschickt und haben eigene Absendereinstellungen.

Und das Supportformular in der Plattform?

Das folgt demselben Weg wie deine übrige Mail.