This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(310.4, 57.99999999999999%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKK%3C/text%3E%3C/svg%3E)
I was full of hope when I saw Azure Email Communication Service. But when I read more, https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/sdk-features, I am not sure if I believe what I read.
Azure Email Communication Service does not have the time-tested simple SMTP interface, where virtually every application framework already has the well tested libraries to connect. A Microsoft private mail API has to be used. Am I understanding it correctly?
It would mean that I can't simply move my Node app from AWS to Azure and start running it straightaway by just updating the SMTP server and credentials.
Does Azure offer a standard SMTP server somewhere among its suite of services?
PS: There are good reasons why the SMTP server should be from the same cloud provider of an application. There will be no extra external traffic charges, and cloud providers usually offer free or generous STMP service for applications hosted in the same network. And if my organization's email is already on Microsoft 365, there is no need set up additional SPF/DKIM just for an application. And I don't have to maintain a separate financial relationship with another provider in addition to the one for the application.
The two below answers are correct. Sendgrid is going to be the route you take if you need email in Azure.
I work primarily on Azure App Services so I cannot fully comment on why there are no formal Azure SMTP offerings, but I typically hear that the risk of hosting an SMTP service and it being used for SPAM was considered to be too high vs any sort of reward. So, we have partnered with 3rd party offerings like SendGrid who do a great job in the SMTP space already.
Many Azure customers are using SendGrid so the risks you lay out do not seem to be true. Let me know if you have any further questions after reading through the two below answers.
Sendgrid is not suitable for me because to send 101 emails will cost me $15, if the 101 mails are sent in a day. I have a very low email requirement, typically no mails on any given day except when there is an event registration, whence at most I need to send 1000 mails spread over the duration of registration period which is typically many weeks.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 60%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJM%3C/text%3E%3C/svg%3E)
It looks like it is available now. https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-smtp-overview
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(288, 12%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGH%3C/text%3E%3C/svg%3E)
As of my last knowledge, Microsoft Azure does not offer a standard SMTP server as part of its suite of services. Azure primarily provides infrastructure and platform services for cloud applications, and while it offers a wide range of services, including Azure Functions, Azure Logic Apps, and Azure SendGrid, these are not equivalent to a standard SMTP server.
Azure SendGrid is an email delivery service that can be used to send transactional and marketing emails from your applications, but it's not a traditional SMTP server. It provides APIs and SMTP relay capabilities for sending emails, but it's a separate service that you would need to integrate with your applications.
The Azure Email Communication Service you mentioned appears to be a service for sending emails via the Azure Communication Services SDK, which may not offer the standard SMTP interface you are looking for. You would indeed need to use Microsoft's private mail API for this purpose.
You are correct in noting that using a cloud provider's SMTP service can have advantages, such as avoiding external traffic charges, leveraging existing SPF/DKIM settings if your organization is already using Microsoft 365, and simplifying billing and integration if you're already using Azure for other services.
However, if you specifically require a standard SMTP server interface, you may need to explore third-party email services or set up your own SMTP server infrastructure within Azure Virtual Machines or other suitable Azure services.
I think I will take up Azure Sendgrid. I have only a few mails to send on a normal day, but sometimes when there is an organized event (once a year), I may have 120 mails a day.
I am not sure what the following means for the Free 100/day plan:
$0.00/month
Includes: overage per email sent: 3,100
Plus: overage per email sent: $0.00133 per email
What does overage mean? What happens when I hit 100 mails a day? Does the service just freeze up, or does it continue to run but charges on a per mail basis? I don't mind paying for those after 100 a day.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 50%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJN%3C/text%3E%3C/svg%3E)
Hi,
The service will continue to run once you have sent out 100 mails. However you will be billed $0.00133 per email sent beyond the 100 mails sent daily.
Azure Sendgrid still does not have a traditional SMTP interface? Code is needed to be written to use the service?
@Jonathan Neerup-Andersen I have the same thinking about overage. However, there is another small print that says:
.
I don't know what to make of it.
It does not no. However it is possible to generate an API key. It works like a username and password where the username is "apikey" and the password is a long string. However not all devices and systems support this. Some printers for example will not allow passwords that long.
So commonly it is just used as a proxy service. You could set up a windows server with IIS SMTP configured. But instead of sending mails from that server, you use Sendgrid to send.
That way you can decide what kind of authentication you want and even do no authentication on port 25 (which is not recommended) and the mails would be sent through Sendgrid and wont get blocked if everything is configured correctly.
As Gerhard mentioned there is no proper Azure SMTP service. However Azure Sendgrid is a good solution to accomplish SMTP from the cloud. Although you might not want to use the API setup from Sendgrid,
you could set up an SMTP relay to send mails through SendGrid. A solution could be to set up a server running Windows SMTP and then use that as a proxy for SendGrid. They have a guide for this here: https://docs.sendgrid.com/for-developers/sending-email/iis75
The advantages of using such a service is primarily DKIM/DMARC/SPF where you add extra security and you do not risk getting your mail server blocked.
Sendgrid works just great and if using the Azure Saas version the billing would be going through your Azure Subscription.
@John Moura Interesting. To get the credentials needs something like a PhD in Microsoft Entra with a sub-specialization in Permissions. I don't see how the 200-character user id and 80-character password is more secure as anyone presenting these will still be able to send mail. Because nobody can remember them, they are bound to be stored in a config file somewhere.