Many organizations that move mailboxes to Office 365, still need to use a SMTP relay to route mails from on-premise applications, scanners (print-to-PDF) or multifunction devices to either internal or external recipients.
Using Exchange Online in Office 365 for mail relay can be accomplished in three ways;
- SMTP client submission
Here you configure the devices or applications to authenticate with an Office 365 mailbox and use Simple Mail Transfer Protocol (SMTP) client submission. In this scenario, the device or application uses an email account to send email to recipients, just like an email client. - Direct Send
Here you configure the devices or applications to send mail directly to recipients in your organization. This scenario does not support external recipients. When you set up your device or application, configure it to point to your mailboxes in Office 365 using your mail exchange (MX) endpoint record. - Office 365 SMTP relay
Here you configure an Exchange Online connector, for your devices or applications to send email to Office 365. Office 365 can then relay email to your organization mailboxes and to external recipients.
For the majority of cases the Office 365 SMTP Relay option proves to be the best and most flexible choice, as the other two options have requirements and limitations that often prove to prevent an optimal utilization. Opting for an Office 365 SMTP Relay has the additional benefits of not requiring a separate licensed Office 365 mailbox to send emails, and this option has higher sending limits than the SMTP client submission scenario.
The post follows up on the previous post regarding the new Simplified Connector Management in Office 365. For guidance on how to create an Exchange Online connector, please refer to this post.
The Office 365 SMTP Relay requires an on-premise SMTP service, which in many cases is the last remaining on-premise Exchange 2010/2013 Server that is already used for managing the on-premise user accounts – this is best practice and highly recommended by Microsoft as the supported practice.
The security of the Office 365 SMTP Relay can be configures using a certificate of a static, unshared public IP address. In this case the security is using a public IP address.
Before proceeding, obtain the public IP address of the on-premise Exchange server, as this is required when configuring the Exchange Online connector.
Exchange Online connector
Log in to your Office 365 tenant, open the Exchange Admin center and click Mail flow, and click Connectors.
Create a new connector, click at the “+” sign.
Select From: Your organization’s email server, and To: Office 365, and click Next
Enter a Name and an optional Description.
Leave the Turn it on and Retain internal Exchange email headers options enabled, and click Next
Now, as specified earlier, in this example, the security is managed using a public IP address. The alternative is to use a certificate
Select the lowest option and click the “+” sign to add the public IP address of the on-premise Exchange server.
Enter one public IP address using CIDR notation, and click OK
If required, add more public IP addresses. When done, click OK
Review the configured settings and click Save
The new connector is saved
Validate the SMTP access using TELNET from the on-premise Exchange server:
XFOR: Telnet to Port 25 to Test SMTP Communication – https://support.microsoft.com/en-us/kb/153119
Exchange Send connector
To complete the Office 365 Relay and route the on-premise SMTP traffic through the Exchange Online Protection (EOP) for external recipients, a new Send Connector needs to be created, on the on-premise Exchange server. For this purpose the on-premise connector must use your MX record as Smart host, so you first needs to retrieve your MX record from the Office 365 admin center:
In the Office 365 Admin Center, select Domains
Select the vanity domain and click Manage DNS
Copy the MX record information and paste it to a Notepad for later.
Now you need to connect to the on-premise Exchange server and open the Exchange Admin Center, where you navigate to Mail Flow -> Send Connectors
Click Add
In the New send connector wizard, specify a name for the send connector and then select Custom for the Type.
Click Next
Choose Route mail through smart hosts, and then click Add.
In the Add smart host window, specify the fully qualified domain name (FQDN) of the Office 365 MX record, you copied earlier, example; Adventureworks-dk.mail.protection.outlook.com
Click Save
Review the smart host settings and click Next
For Smart host authentication, you may select None
Under Address space, click Add
In the Add domain window, make sure SMTP is listed as the Type.
For Fully Qualified Domain Name (FQDN), enter * to specify that this send connector applies to messages sent to any domain.
Click Save
Click Next
For Source server, click Add
In the Select a server window, choose an on-premise Exchange server and click Add.
Click OK
Click Finish
Once finished, the new send connector will appear in the Send connector list, and if required you can open the created Send Connector again to adjust options like maximum message size.
Exchange Receive connector
By default, Exchange 2013 does not allow clients to use the SMTP service for anonymous relay, so we need to configure a Receive Connector for this purpose.
In the Exchange Admin Center navigate to Mail Flow -> Receive Connectors
Click the + icon to create a new receive connector.
Enter a name for the new connector
For Role:
- If the Exchange server is Multi-role, select the Hub Transport role.
- If the Exchange server is CAS-only, select the Frontend Transport role.
Leave the Type set to Custom, and then click Next.
For servers with a single network adapter the default binding will usually be fine.
For the remote network settings, click the “–” icon to remove the default IP address range.
Then click the “+” icon and add at least one IP address of an application server or multi-function device that need access to SMTP Relay.
Click Finish to create the new receive connector.
Next, a few additional settings must be configured for the new receive connector.
Select the connector and click the “pencil” icon to modify
Select the Security option and enabled these settings:
| Authentication | Transport Layer Security (TLS) Externally secured |
| Permission groups | Exchange servers Anonymous |
Click Save to apply the settings.
Receive connector permissions
It is recommended to change some parameters of the receive connector.
Execute the following PowerShell command:
Get-ReceiveConnector -Identity “Anonymous Relay*” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited
Restart the Microsoft Exchange Transport Service on the Exchange server, with this command:
Restart-Service MSExchangeTransport
For the final step, anonymous users (like unauthenticated SMTP connections from applications and multi-function devices) must be granted the ability to send to external recipients. Open the Exchange Management Shell and run the following command – with the relevant name of the local receive connector:
Get-ReceiveConnector “Anonymous Relay*” | Add-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
Public SPF Record
Now that you are done with configuring your Office 365 and on-premise Exchange settings, you need to update your public DNS records for the SMTP zones used by the on-premise applications or multi-function devices. Here you edit the SPF (Sender Policy Framework) TXT record, and include the public IP address of the on-premise Exchange.
The final value string should look for the SPF record should look approximately similar to this, where 123.45.67.89 is your public IP address:
v=spf1 ip4:123.45.67.89 include:spf.protection.outlook.com ~all
If you skip this step, it may cause email to be sent to recipients’ junk mail folders.
References:
How to set up a multi-function device or application to send email using Office 365
XFOR: Telnet to Port 25 to Test SMTP Communication
You must log in to post a comment.