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.

Was du brauchst:

Ein Dienstkonto in Google Cloud, mit einem JSON-Schlüssel.
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.

Den JSON-Schlüssel fügst du in das Feld Dienstkontoschlüssel (JSON) ein. Er 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 löschen.

Gut zu wissen: Die domainweite Delegierung gilt für die gesamte Domain. Das Dienstkonto kann damit technisch im Namen jeder Adresse in eurem Workspace verschicken, auch wenn wir nur eine davon nutzen. Besprich das mit deinem IT-Administrator, bevor du es einrichtest.

Ü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.