Standaard verstuurt 2LRN4 alle mail aan je cursisten vanaf een eigen adres. Dat werkt, maar medewerkers herkennen de afzender niet altijd. Je kunt daarom instellen dat de mail vanaf het adres van jouw organisatie komt, en zelfs dat hij daadwerkelijk vanuit jullie eigen mailomgeving wordt verstuurd. Sinds augustus 2026 kan dat voor elke organisatie; daarvoor was dit voorbehouden aan klanten met een Microsoft-omgeving.

Je vindt de keuze bij Organisaties → jouw organisatie → bewerken, onder het kopje Ondersteuning, bij Verzendroute voor deze organisatie.

De vier routes

Welke past, hangt af van waar jullie mail draait. Zit je op Microsoft 365 of Google Workspace, kies dan de bijbehorende route. Dat geeft de beste bezorging, omdat de mail dan echt uit jullie eigen omgeving komt.

Via 2LRN4 (standaard)

De mail wordt door ons verstuurd. Vul je bij Support e-mail een adres van je eigen organisatie in, dan verschijnt dat als afzender; laat je het leeg, dan gebruiken we het adres van 2LRN4.

Let op bij een eigen adres op deze route. De mail komt dan van jouw adres, maar wordt door onze server verstuurd. Veel organisaties hebben in hun DNS vastgelegd wie namens hun domein mag versturen (SPF, DKIM en DMARC). Staat die instelling streng, dan kan de ontvangende mailserver zulke berichten in de spambox zetten of zelfs weigeren. Twijfel je, overleg dan met je ICT-beheerder, of kies een van de drie routes hieronder, want daarbij speelt dit niet.

Vanuit de eigen Microsoft-mailbox

De mail wordt via Microsoft Graph vanuit een mailbox in jullie eigen Microsoft 365-omgeving verstuurd. Afzender en bezorging kloppen dan vanzelf, omdat de mail gewoon jullie eigen Microsoft-omgeving verlaat.

In het platform heb je drie dingen nodig:

1. Een Entra-koppeling bij deze organisatie. Heb je die nog niet, dan wijst het scherm je naar de plek waar je er een aanmaakt. Zie ook Gebruikers synchroniseren.
2. De app-registratie van die koppeling moet mail mogen versturen. Gebruik je een bestaande koppeling die alleen voor gebruikerssynchronisatie is ingericht, dan heeft die dat recht meestal nog niet; hieronder staat wat je ICT-beheerder toevoegt.
3. Het adres bij Support e-mail moet een bestaande mailbox in die omgeving zijn, met verzendrechten. Een alias of een adres dat alleen op papier bestaat werkt niet.

Wat je ICT-beheerder in Azure regelt, in de app-registratie van de bestaande koppeling:

1. Open de app-registratie en ga naar API-machtigingen.
2. Voeg een machtiging toe via Microsoft Graph → Application permissions en kies Mail.Send. Gebruik uitsluitend application permissions; delegated permissions werken hier niet, omdat het platform zonder ingelogde gebruiker verstuurt.
3. Verleen beheerdersgoedkeuring (admin consent) voor de nieuwe machtiging.
4. Controleer dat het afzenderadres een geldige Exchange Online-mailbox is.
5. Beperk de machtiging tot die ene mailbox. Dit is de belangrijkste stap en hij wordt vaak overgeslagen. Mail.Send geldt standaard voor de héle omgeving: de app-registratie mag dan technisch namens elk adres in jullie tenant versturen, terwijl wij er maar één gebruiken. Met een application access policy in Exchange Online beperk je dat tot de mailbox die je hier invult.

   Je ICT-beheerder doet dat met twee opdrachten in Exchange Online PowerShell. Zet eerst de mailbox in een beveiligingsgroep met e-mailadres, en koppel daar de app-registratie aan:

   New-DistributionGroup -Name "2LRN4 verzendmailbox" -Type Security `
     -PrimarySmtpAddress "2lrn4-verzendmailbox@jouwdomein.nl" `
     -Members "noreply@jouwdomein.nl"
   
   New-ApplicationAccessPolicy `
     -AppId "" `
     -PolicyScopeGroupId "2lrn4-verzendmailbox@jouwdomein.nl" `
     -AccessRight RestrictAccess `
     -Description "2LRN4 mag alleen vanuit de verzendmailbox versturen"

   Controleren of het gelukt is:

   Test-ApplicationAccessPolicy -Identity "noreply@jouwdomein.nl" -AppId ""

   De uitkomst hoort Granted te zijn voor die mailbox, en Denied voor elke andere. Reken op een uur voordat de instelling overal is doorgevoerd.

Werkt het? Onder aan hetzelfde scherm staat de knop Stuur een proefbericht. Die stuurt één bericht naar jouw eigen adres, langs precies dezelfde weg als de mail aan je cursisten. Sla je wijzigingen eerst op, want de test gebruikt de opgeslagen instellingen. Boven de knop staat de uitslag van de laatste controle, die wij elke ochtend automatisch uitvoeren.

Krijg je de melding dat de eigen route niet werkte en het bericht via 2LRN4 is verstuurd, dan is het proefbericht wél aangekomen maar klopt de instelling nog niet. De reden staat er dan bij.

Bekende foutmeldingen bij deze route en wat eraan te doen is:

Vanuit de eigen Google-mailbox

De mail wordt via de Gmail API vanuit een mailbox in jullie Google Workspace verstuurd.

Wat je nodig hebt:

1. Een serviceaccount in Google Cloud, met een JSON-sleutel.
2. Domeinbrede delegatie voor dat serviceaccount in de Google-beheerconsole, met uitsluitend de scope https://www.googleapis.com/auth/gmail.send.
3. Het adres bij Support e-mail moet een bestaande mailbox in die Workspace zijn.

De JSON-sleutel plak je in het veld Serviceaccountsleutel (JSON). Die wordt versleuteld bewaard en na het opslaan niet meer getoond; je ziet alleen van welk serviceaccount hij is. Wil je hem later weghalen, dan kan dat met het vinkje Deze sleutel verwijderen.

Goed om te weten: domeinbrede delegatie geldt voor het hele domein. Het serviceaccount kan daarmee technisch namens elk adres in jullie Workspace versturen, ook al gebruiken wij er maar één. Bespreek dat met je ICT-beheerder voordat je het inricht.

Via de eigen mailserver (SMTP)

Gebruik je geen Microsoft of Google, dan kun je je eigen mailserver opgeven: server, poort, versleuteling, gebruikersnaam en wachtwoord. Het wachtwoord wordt versleuteld bewaard en na het opslaan niet meer getoond; laat je het veld leeg bij een latere wijziging, dan blijft het bestaande wachtwoord staan.

Controleer met je ICT-beheerder of die server namens jullie domein mag versturen, anders kan de mail alsnog geweigerd worden.

Wat er gebeurt als het misgaat

Lukt het versturen via jullie eigen route niet, bijvoorbeeld omdat een wachtwoord is verlopen, een machtiging is ingetrokken of een mailbox is verplaatst, dan gaat het bericht alsnog de deur uit via 2LRN4. Je cursist krijgt zijn wachtwoordreset of uitnodiging dus gewoon; alleen staat er dan ons adres als afzender, met jullie adres als antwoordadres. Dat is bewust: een bericht met jullie domein als afzender vanaf onze server botst met de SPF- en DMARC-instellingen van jullie domein, en zou dan in de spammap belanden.

Tegelijk wordt de organisatie gemarkeerd. Je ziet dat terug op het scherm met de verzendroute, en wij zien het in een dagelijkse controle die per organisatie vaststelt of er nog verstuurd kan worden. Bij een blijvend probleem nemen wij contact op.

Veelgestelde vragen

Verandert er iets voor onze cursisten?

Alleen de afzender. Inhoud, opmaak en het moment van versturen blijven hetzelfde.

Wij gebruikten de oude instelling "Enable azure mailing". Moeten we iets doen?

Nee. Organisaties die via Microsoft verstuurden zijn automatisch overgezet naar de route Vanuit de eigen Microsoft-mailbox; alles blijft werken zoals het deed.

Kunnen we terug naar de standaardroute?

Ja, altijd. Zet de keuze terug op Via 2LRN4; de mail gaat dan weer vanaf ons adres. Opgeslagen inloggegevens blijven bewaard tot je ze zelf verwijdert, zodat je later kunt terugschakelen.

Geldt dit ook voor phishingsimulaties?

Nee. Die worden via een aparte omgeving verstuurd en hebben hun eigen afzenderinstellingen.

En het supportformulier in het platform?

Dat volgt dezelfde route als de rest van je mail.