An Azure communication platform for deploying applications across devices and platforms.
You can send emails from the Microsoft ecosystem in two main ways depending on what you are building. If you are sending transactional or application-generated emails from a cloud service, Azure is typically used through Azure Communication Services Email or through a partner like SendGrid. If you want to send emails directly from a mailbox such as Outlook or Microsoft 365, you normally use Microsoft Graph API or SMTP with OAuth authentication. The choice depends on whether you need application-level messaging at scale or mailbox-level sending that appears in a user’s Outlook “Sent” folder.
Using Azure Communication Services Email is the “native Azure” approach for automated notifications, backend systems, and scalable services. You create an Email Communication resource in Azure, verify a domain or use a managed domain, obtain a connection string, and send through SDKs or REST APIs. The application authenticates with a connection string or Entra ID, constructs the email payload, and submits it to the Azure service which handles delivery infrastructure. This approach is best when your application runs in Azure and you do not want to manage SMTP servers.
from
connection_string
client
message
},
}
}
poller
result
print
You can also use Azure with SendGrid if you want advanced marketing features or an SMTP relay model. Azure Marketplace allows provisioning SendGrid, after which you send via SMTP or API using a SendGrid API key. This is common when migrating from traditional SMTP infrastructure but still wanting Azure billing and deployment integration.
import
from
sg
message
)
response
print
Sending through Outlook or Microsoft 365 is usually done with Microsoft Graph API when you want the message to originate from a real mailbox and follow tenant security policies. The process involves registering an application in Microsoft Entra ID, granting Mail.Send permissions, obtaining an OAuth access token, and calling the Graph sendMail endpoint. This method is recommended over basic SMTP authentication because Microsoft is deprecating legacy auth and enforcing modern authentication.
POST https://graph.microsoft.com/v1.0/users/******@domain.com/sendMail
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
{
"message": {
"subject": "Graph API Email",
"body": {
"contentType": "Text",
"content": "Hello from Microsoft Graph"
},
"toRecipients": [
{
"emailAddress": {
"address": "recipient@example.com"
}
}
]
}
}
If you specifically need SMTP through Outlook or Microsoft 365, you configure the SMTP server smtp.office365.com with TLS on port 587 and authenticate using OAuth2 tokens instead of passwords. This is useful for legacy applications that cannot move to REST APIs yet but still need secure authentication tied to an Outlook mailbox.
import
from
smtp_server
port
msg
msg
msg
msg
with
In practice, Azure Communication Services or SendGrid is better for automated notifications, system alerts, and high-volume transactional emails, while Microsoft Graph or Outlook SMTP is better when emails should be tied to a user mailbox, internal corporate workflows, or compliance logging in Microsoft 365.
More at https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-overview
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin