Exchange Online Integration for Email-Outbound from SAP NetWeaver
Sending emails from your SAP backend is a standard feature widely distributed for use cases such as alerting for batch jobs, SAP workflow state changes or invoice distribution. Many customers established the setup using Exchange Server on-premises. With a shift to Microsoft 365 and Exchange Online comes a set of cloud-native approaches impacting that setup.
This article describes the setup for outbound email-communication from NetWeaver-based SAP systems to Exchange Online. That applies to SAP ECC, S/4HANA, SAP RISE managed, and any other NetWeaver based system.
Overview
Existing implementations relied on SMTP Auth and elevated trust relationship because the legacy Exchange Server on-premises could live close to the SAP system itself and was governed by customers themselves. With Exchange Online there's a shift in responsibilities and connectivity paradigm. Microsoft supplies Exchange Online as a Software-as-a-Service offering built to be consumed securely and as effectively as possible from anywhere in the world over the public Internet.
Follow our standard guide to understand the general configuration of a "device" that wants to send email via Microsoft 365.
Important
SMTP Auth was exempted from the Basic Auth feature sunset process for continued support. However, this is a security risk for your estate. See the latest post by our Exchange Online team on the matter.
Setup considerations
Given the sunset-exception of SMTP Auth there are four different options supported by SAP NetWeaver that we want to describe. The first three correlate with the scenarios described in the Exchange Online documentation.
- SMTP Authentication Client Submission
- SMTP Direct Send
- Using Exchange Online SMTP relay connector
- Using SMTP relay server as intermediary to Exchange Online
For brevity we'll refer to the SAP Connect administration tool used for the mail server setup only by its transaction code SCOT.
Option 1: SMTP Authentication Client Submission
Choose this option when you want to send mail to people inside and outside your organization.
Connect SAP applications directly to Microsoft 365 using SMTP Auth endpoint smtp.office365.com in SCOT.
A valid email address will be required to authenticate with Microsoft 365. The email address of the account that's used to authenticate with Microsoft 365 will appear as the sender of messages from the SAP application.
Requirements for SMTP AUTH
- SMTP AUTH: Needs to be enabled for the mailbox being used. SMTP AUTH is disabled for organizations created after January 2020 but can be enabled per-mailbox. For more information, see Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online.
- Authentication: Use Basic Authentication (which is simply a username and password) to send email from SAP application. If SMTP AUTH is intentionally disabled for the organization, you must use Option 2, 3 or 4 below.
- Mailbox: You must have a licensed Microsoft 365 mailbox to send email from.
- Transport Layer Security (TLS): Your SAP Application must be able to use TLS version 1.2 and above.
- Port: Port 587 (recommended) or port 25 is required and must be unblocked on your network. Some network firewalls or Internet Service Providers block ports, especially port 25, because that's the port that email servers use to send mail.
- DNS: Use the DNS name smtp.office365.com. Don't use an IP address for the Microsoft 365 server, as IP Addresses aren't supported.
How to Enable SMTP auth for mailboxes in Exchange Online
There are two ways to enable SMTP AUTH in Exchange online:
- For a single account (per mailbox) that overrides the tenant-wide setting or
- at organization level.
Note
if your authentication policy disables basic authentication for SMTP, clients cannot use the SMTP AUTH protocol even if you enable the settings outlined in this article.
The per-mailbox setting to enable SMTP AUTH is available in the Microsoft 365 Admin Center or via Exchange Online PowerShell.
Open the Microsoft 365 admin center and go to Users -> Active users.
Select the user, follow the wizard, click Mail.
In the Email apps section, click Manage email apps.
Verify the Authenticated SMTP setting (unchecked = disabled, checked = enabled)
Save changes.
This will enable SMTP AUTH for that individual user in Exchange Online that you require for SCOT.
Configure SMTP Auth with SCOT
Ping or telnet smtp.office365.com on port 587 from your SAP application server to make sure ports are open and accessible.
Make sure SAP Internet Communication Manager (ICM) parameter is set in your instance profile. See below an example:
parameter value icm/server-port-1 PROT=SMTP,PORT=25000,TIMEOUT=180,TLS=1 Restart ICM service from SMICM transaction and make sure SMTP service is active.
Activate SAPConnect service in SICF transaction.
Go to SCOT and select SMTP node (double click) as shown below to proceed with configuration:
Add mail host smtp.office365.com with port 587. Check the Exchange Online docs for reference.
Click on the "Settings" button (next to the Security field) to add TLS settings and basic authentication details as mentioned in point 2 if required. Make sure your ICM parameter is set accordingly.
Make sure to use a valid Microsoft 365 email ID and password. In addition to that it needs to be the same user that you've enabled for SMTP Auth at the beginning. This email ID will show up as the sender.
Coming back to the previous screen: Click on "Set" button and check "Internet" under "Supported Address Types". Using the wildcard "*" option will allow you to send emails to all domains without restriction.
Next Step: set default Domain in SCOT.
Schedule Job to send email to the submission queue. From SCOT select "Send Job":
Provide a Job name and variant if appropriate.
Test mail submission using transaction code SBWP and check the status using SOST transaction.
Limitations of SMTP AUTH client submission
- SCOT stores login credentials for only one user, so only one Microsoft 365 mailbox can be configured this way. Sending mail via individual SAP users requires to implement the "Send As permission" offered by Microsoft 365.
- Microsoft 365 imposes some sending limits. See Exchange Online limits - Receiving and sending limits for more information.
Option 2: SMTP Direct Send
Microsoft 365 offers the ability to configure direct send from the SAP application server. This option is limited in that it only permits mail to be routed to addresses in your own Microsoft 365 organization with a valid e-mail address therefore cannot be used for external recipients (e.g., vendors or customers).
Option 3: Using Microsoft 365 SMTP Relay Connector
Only choose this option when:
- Your Microsoft 365 environment has SMTP AUTH disabled.
- SMTP client submission (Option 1) isn't compatible with your business needs or with your SAP Application.
- You can't use direct send (Option 2) because you must send email to external recipients.
SMTP relay lets Microsoft 365 relay emails on your behalf by using a connector that's configured with your public IP address or a TLS certificate. Compared to the other options, the connector setup increases complexity.
Requirements for SMTP Relay
- SAP Parameter: SAP instance parameter configured and SMTP service are activated as explained in option 1, follow steps 2 to 4 from "Configure SMTP Auth with SCOT" section.
- Email Address: Any email address in one of your Microsoft 365 verified domains. This email address doesn't need a mailbox. For example,
noreply@*yourdomain*.com. - Transport Layer Security (TLS): SAP application must be able to use TLS version 1.2 and above.
- Port: port 25 is required and must be unblocked on your network. Some network firewalls or ISPs block ports, especially port 25 due to the risk of misuse for spamming.
- MX record: your Mail Exchanger (MX) endpoint, for e.g., yourdomain.mail.protection.outlook.com. Find more information on the next section.
- Relay Access: A Public IP address or SSL certificate is required to authenticate against the relay connector. To avoid configuring direct access it's recommended to use Source Network Translation (SNAT) as described in this article. Use Source Network Address Translation (SNAT) for outbound connections.
Step-by-step configuration instructions for SMTP relay in Microsoft 365
Obtain the public (static) IP address of the endpoint which will be sending the mail using one of the methods listed in the article above. A dynamic IP address isn't supported or allowed. You can share your static IP address with other devices and users, but don't share the IP address with anyone outside of your company. Make a note of this IP address for later.
Note
Find above information on the Azure portal using the Virtual Machine overview of the SAP application server.
Sign in to the Microsoft 365 Admin Center.
Go to Settings -> Domains, select your domain (for example, contoso.com), and find the Mail Exchanger (MX) record.
The Mail Exchanger (MX) record will have data for Points to address or value that looks similar to
yourdomain.mail.protection.outlook.com.Make a note of the data of Points to address or value for the Mail Exchanger (MX) record, which we refer to as your MX endpoint.
In Microsoft 365, select Admin and then Exchange to go to the new Exchange Admin Center.
New Exchange Admin Center (EAC) portal will open.
In the Exchange Admin Center (EAC), go to Mail flow -> Connectors. The Connectors screen is depicted below. If you are working with the classical EAC follow step 8 as described on our docs.
Click Add a connector
Choose "Your organization's email server".
Click Next. The Connector name screen appears.
Provide a name for the connector and click Next. The Authenticating sent email screen appears.
Choose By verifying that the IP address of the sending server matches one of these IP addresses which belong exclusively to your organization and add the IP address from Step 1 of the Step-by-step configuration instructions for SMTP relay in Microsoft 365 section.
Review and click on Create connector.
Now that you're done with configuring your Microsoft 365 settings, go to your domain registrar's website to update your DNS records. Edit your Sender Policy Framework (SPF) record. Include the IP address that you noted in step 1. The finished string should look similar to this
v=spf1 ip4:10.5.3.2 include:spf.protection.outlook.com \~all, where 10.5.3.2 is your public IP address. Skipping this step may cause emails to be flagged as spam and end up in the recipient's Junk Email folder.
Steps in SAP Application server
- Make sure SAP ICM Parameter and SMTP service is activated as explained in Option 1 (steps 2-4)
- Go to SCOT transaction in SMTP node as shown in previous steps of Option 1.
- Add mail Host as Mail Exchanger (MX) record value noted in Step 4 (i.e. yourdomain.mail.protection.outlook.com).
Mail host: yourdomain.mail.protection.outlook.com
Port: 25
Click "Settings" next to the Security field and make sure TLS is enabled if possible. Also make sure no prior logon data regarding SMTP AUTH is present. Otherwise delete existing records with the corresponding button underneath.
Test the configuration using a test email from your SAP application with transaction SBWP and check the status in SOST transaction.
Option 4: Using SMTP relay server as intermediary to Exchange Online
An intermediate relay server can be an alternative to a direct connection from the SAP application server to Microsoft 365. This server can be based on any mail server that will allow direct authentication and relay services.
The advantage of this solution is that it can be deployed in the hub of a hub-spoke virtual network within your Azure environment or within a DMZ to protect your SAP application hosts from direct access. It also allows for centralized outbound routing to immediately offload all mail traffic to a central relay when sending from multiple application servers.
The configuration steps are the same as for the Microsoft 365 SMTP Relay Connector (Option 3) with the only differences being that the SCOT configuration should reference the mail host that will perform the relay rather than direct to Microsoft 365. Depending on the mail system that is being used for the relay it will also be configured directly to connect to Microsoft 365 using one of the supported methods and a valid user with password. It is recommended to send a test mail from the relay directly to ensure it can communicate successfully with Microsoft 365 before completing the SAP SCOT configuration and testing as normal.
The example architecture shown illustrates multiple SAP application servers with a single mail relay host in the hub. Depending on the volume of mail to be sent it is recommended to follow a detailed sizing guide for the mail vendor to be used as the relay. This may require multiple mail relay hosts which operate with an Azure Load Balancer.