For those trying to relay SMTP with an application in Azure to Office, base guidance and options can be found in the Microsoft article “How to set up a multifunction device or application to send email using Microsoft 365 or Office 365”. In the article, three distinct distinct options are provided for Office 365 relay, noted in the table below:
| Features | SMTP Client Submission | Direct Send | SMTP Relay |
| Send to recipients in your domain(s) | Yes | Yes | Yes |
| Relay to internet via Microsoft 365 or Office 365 | Yes | No, direct delivery only. | Yes |
| Bypasses antispam | Yes, if the mail is destined for one of your Microsoft 365 or Office 365 mailboxes. | No. Suspicious emails might be filtered. We recommend a custom Sender Policy Framework (SPF) record. | No. Suspicious emails might be filtered. We recommend a custom SPF record.. |
| Supports mail sent from applications hosted by a third party | Yes | Yes. We recommend updating your SPF record to allow the third party to send as your domain. | No |
| Saves to Sent Items folder | Yes | No | No |
| Requirements | |||
| Open network port | Port 587 or Port 25 | Port 25 | Port 25 |
| Device or application server must support TLS | Required | Optional | Optional |
| Requires authentication | Microsoft 365 or Office 365 username and password required. | Non | One or more static IP addresses. Your printer or the server running your LOB app must have a static IP address to use for authentication with Microsoft 365 or Office 365. |
Table 1
On paper this should be direct. For example, if option three “the SMTP relay” was selected, one would:
- Allow SMTP in the network security group to Office 365.
- Create a receive connector on Office 365 which would allow relaying from the anticipated IP. Given this scenario and security, a static IP would be recommended.
- And then modify the SPF record to include the IP address.
In the Azure world, there would be one last hurdle: the date of pay-as-you-go subscription. If you signed up for a pay-as-you-go subscription after November 15, 2017, Microsoft restricts the ability to send outbound email. In order to bypass this limitation, a support request will need to be filed with Microsoft. The good news is that once your pay-as-you-go subscription is exempted and the VMs are stopped and restarted in the Azure portal, all VMs in that subscription are exempted going forward. It should be noted, this only applies only to the subscription requested and only to VM traffic that is routed directly to the internet.
There is a distinction between restarting the machine from the OS perspective and fully stopping the VM (deallocation). The core difference is when a virtual machine is stopped and you also free up hardware and networking resources. Care should be taken if static IP addresses were not assigned, as they will be released. In this scenario, the public IP address would have been reserved to maintain access to the receive connector in Office 365.
What also can be misleading to some customers, is that in the “support + troubleshooting” options of your VM, the “Connection Troubleshoot” option will verify outbound SMTP even if no deallocation has taken place. This could be a scenario where Microsoft support enabled outbound SMTP, the proper NSG rules are in place but without deallocation, outbound mail will not work.
Comments