By default, 2LRN4 sends all mail to your learners from an address of its own. That works, but employees do not always recognise the sender. You can therefore set it up so that the mail comes from your organisation's address, and even so that it is genuinely sent from your own mail environment. Since August 2026 that is possible for every organisation; before then it was reserved for customers with a Microsoft environment.

You will find the choice at Organisations → your organisation → edit, under the heading Support, at Sending route for this organisation.

The four routes

Which one fits depends on where your mail runs. If you are on Microsoft 365 or Google Workspace, choose the matching route. That gives the best delivery, because the mail then really does come out of your own environment.

Via 2LRN4 (default)

The mail is sent by us. If you enter an address of your own organisation at Support email, that appears as the sender; if you leave it empty, we use the 2LRN4 address.

Watch out when using your own address on this route. The mail then comes from your address, but it is sent by our server. Many organisations have recorded in their DNS who may send on behalf of their domain (SPF, DKIM and DMARC). If that setting is strict, the receiving mail server may put such messages in the spam folder or even refuse them. If you are in doubt, talk it over with your IT administrator, or choose one of the three routes below, where this does not come into play.

From your own Microsoft mailbox

The mail is sent via Microsoft Graph from a mailbox in your own Microsoft 365 environment. Sender and delivery are then right by themselves, because the mail simply leaves your own Microsoft environment.

In the platform you need three things:

1. An Entra connection for this organisation. If you do not have one yet, the screen points you to where you create it. See also Synchronising users.
2. The app registration of that connection must be allowed to send mail. If you use an existing connection that was set up for user synchronisation only, it usually does not have that right yet; below is what your IT administrator adds.
3. The address at Support email must be an existing mailbox in that environment, with sending rights. An alias, or an address that exists only on paper, does not work.

What your IT administrator arranges in Azure, in the app registration of the existing connection:

1. Open the app registration and go to API permissions.
2. Add a permission via Microsoft Graph → Application permissions and choose Mail.Send. Use application permissions only; delegated permissions do not work here, because the platform sends without a logged-in user.
3. Grant admin consent for the new permission.
4. Check that the sender address is a valid Exchange Online mailbox.
5. Restrict the permission to that one mailbox. This is the most important step and it is often skipped. By default, Mail.Send applies to the whole environment: technically, the app registration may then send on behalf of every address in your tenant, while we use only one. With an application access policy in Exchange Online you restrict that to the mailbox you enter here.

   Your IT administrator does that with two commands in Exchange Online PowerShell. First put the mailbox in a mail-enabled security group, and link the app registration to it:

   New-DistributionGroup -Name "2LRN4 sending mailbox" -Type Security `
     -PrimarySmtpAddress "2lrn4-sending-mailbox@yourdomain.com" `
     -Members "noreply@yourdomain.com"
   
   New-ApplicationAccessPolicy `
     -AppId "" `
     -PolicyScopeGroupId "2lrn4-sending-mailbox@yourdomain.com" `
     -AccessRight RestrictAccess `
     -Description "2LRN4 may send only from the sending mailbox"

   Checking whether it worked:

   Test-ApplicationAccessPolicy -Identity "noreply@yourdomain.com" -AppId ""

   The outcome should be Granted for that mailbox, and Denied for every other one. Allow an hour before the setting has been applied everywhere.

Does it work? At the bottom of the same screen is the Send a test message button. It sends one message to your own address, along exactly the same path as the mail to your learners. Save your changes first, because the test uses the saved settings. Above the button you see the result of the latest check, which we run automatically every morning.

If you get the message that your own route did not work and that the message was sent via 2LRN4, then the test message did arrive but the setting is not right yet. The reason is then given alongside it.

Known error messages on this route and what to do about them:

From your own Google mailbox

The mail is sent via the Gmail API from a mailbox in your Google Workspace.

What you need:

1. A service account in Google Cloud, with a JSON key.
2. Domain-wide delegation for that service account in the Google admin console, with the scope https://www.googleapis.com/auth/gmail.send and nothing else.
3. The address at Support email must be an existing mailbox in that Workspace.

You paste the JSON key into the Service account key (JSON) field. It is kept encrypted and is no longer shown after saving; you only see which service account it belongs to. If you want to remove it later, you can do so with the Delete this key tick box.

Good to know: domain-wide delegation applies to the whole domain. Technically, the service account can therefore send on behalf of every address in your Workspace, even though we use only one. Discuss that with your IT administrator before you set it up.

Via your own mail server (SMTP)

If you use neither Microsoft nor Google, you can specify your own mail server: server, port, encryption, user name and password. The password is kept encrypted and is no longer shown after saving; if you leave the field empty during a later change, the existing password stays in place.

Check with your IT administrator whether that server is allowed to send on behalf of your domain, otherwise the mail may still be refused.

What happens if it goes wrong

If sending via your own route does not succeed, for example because a password has expired, a permission has been withdrawn or a mailbox has been moved, then the message still goes out via 2LRN4. So your learner does get their password reset or their invitation; the only difference is that our address is then shown as the sender, with your address as the reply address. That is deliberate: a message with your domain as the sender coming from our server clashes with the SPF and DMARC settings of your domain, and would then end up in the spam folder.

At the same time the organisation is flagged. You see that back on the screen with the sending route, and we see it in a daily check that establishes per organisation whether mail can still be sent. If a problem persists, we get in touch.

Frequently asked questions

Does anything change for our learners?

Only the sender. Content, layout and the moment of sending stay the same.

We used the old “Enable azure mailing” setting. Do we need to do anything?

No. Organisations that sent via Microsoft have been moved over automatically to the From your own Microsoft mailbox route; everything keeps working as it did.

Can we go back to the default route?

Yes, at any time. Set the choice back to Via 2LRN4; the mail then goes out from our address again. Saved login details are kept until you delete them yourself, so that you can switch back later.

Does this apply to phishing simulations as well?

No. Those are sent through a separate environment and have their own sender settings.

And the support form in the platform?

That follows the same route as the rest of your mail.