The course is part of this learning path
In this course, we look at Exchange Online Connectivity and Mail Routing.
Learning Objectives
- Basic DNS terms that affect mail flow
- Mail flow scenarios
- Sharing and organizational relationships in Exchange Online
Intended Audience
- Those who wish to learn about Exchange Online connectivity and about the different mail routing options that are available in Microsoft 365
Prerequisites
- General Understanding of Messaging Concepts
- Familiarity with Exchange Admin Center
Welcome back. In this lesson, we'll take a look at a few different ways that you can send emails from multifunction devices and apps through Microsoft 365 when all of your mailboxes are in Microsoft 365. Typical use cases for this type of architecture includes scenarios where you might have a scanner that you want to do, scan to email with or where you use a monitoring app that sends out alerts via email. Over the next few minutes, we'll take a look at the different ways that you can use Microsoft 365 to address these types of use cases. So, the first option I want to cover here is where you authenticate a device or app directly with a Microsoft 365 mailbox and you use SMTP AUTH client submission to send email from the device or app via Microsoft 365. Before we get into it, I do just want to point out though that Microsoft recommends using modern authentication when connecting to Microsoft 365.
Since most devices and clients aren't designed to use modern authentication, this option is not compatible with Microsoft security defaults. That being the case, you'll likely need to use basic authentication for SMTP AUTH clients to use this option for sending mail. Now, this option is easy to set up and it supports most usage scenarios in a while. It's best used for situations where you need to send emails from a third party app or service or device to people, both inside and outside your organization. To make this work, you have to configure your device or app to connect directly to Microsoft 365. You use smtp.office35.com as the SMTP of client submission endpoint. It's important to remember that each individual device or app that's going to be sending emails needs to be able to authenticate with Microsoft 365. The emails that are received from the device or app will show the email address of the account that's used to authenticate with Microsoft 365 as the sender of those emails.
The diagram on your screen shows what a typical architecture would look like in this scenario. Now, direct send is a good option if you can't authenticate your printer or application directly with a Microsoft 365 mailbox. Using direct send allows you to send mail directly from a printer or app right to Microsoft 365 when SMTP AUTH is disabled in your environment or when you can't authenticate using a mailbox. That said, you can only use direct send if you only need to send emails to recipients within your own organization who have mailboxes in Microsoft 365. You cannot use direct send to send emails to user mailboxes that reside outside of your organization. Take a look at the diagram on your screen. This is what a direct send architecture looks like. Notice that the app or device uses your organization's Microsoft 365 MX endpoint to send emails to recipients with mailboxes within the organization.
It's important to note that while direct send uses Microsoft 365 to send emails, using it does not require a dedicated Microsoft 365 mailbox nor does direct send require a device or application to have a static IP address. While it is recommended, it's not a hard requirement. The cool thing about direct send is that it doesn't require you to set up a connector in exchange online nor does it require the device to support TLS. Now, with all that said, I should point out that there are some limitations with direct send as well. For example, as I mentioned earlier, you can't use direct send to send email to external recipients. It should also be noted that emails sent via direct send will be subject to anti-spam checks and delivery of those emails might get blocked if your IP addresses are blocked by a spam list somewhere. And then lastly, direct send emails are governed by Microsoft 365 throttling policies which are in place to prevent abuse. Now, I've saved the Microsoft 365 SMTP Relay option for last.
If you need to utilize Microsoft 365's SMTP Relay functionality, you're in for a more difficult implementation than the other options that we've covered. This gets more difficult to implement because it requires you to configure connectors in exchange online. Because of the complexity of configuring SMTP Relay, you really should only use this option in situations where SMTP AUTH is disabled in the environment and you can't use either of the first two options we just talked about, those being SMTP client submission and direct send. Configuring SMTP relay allows you to relay emails through Microsoft 365 via a connector that you configure with either your public IP address or TLS certificate. This connector setup is what makes this option more complex to set up and implement. When you create the connector to implement this option, you need to specify your organization's email server in the 'From' setting of the connector. Microsoft 365 is configured as the two setting.
To lock down relay to only your environment, you can restrict relay to a specific on-prem IP address or to a range of on-prem IP addresses that your devices or applications will use to connect to Microsoft 365. When configuring SMTP relay, Microsoft recommends adding an SPF record that includes your IP address and the Microsoft 365, so that your messages don't get tagged as spam on the receiving end. Now, if your devices or apps allow you to configure a certificate for mail flow, you can configure Microsoft 365 SMTP relay to use a certificate-based connector to relay email instead of using an IP address-based connector. Take a look at the diagram on your screen. This shows how Microsoft 365 SMTP relay works. Notice that the application or device uses a connector for SMTP relay to email recipients within the organization. In this architecture, the Microsoft 365 connector authenticates the device or app using an IP address, provided the app or device uses an email address of your email domain, it can send email.
It's important to note that the email address you use does not necessarily have to be associated with a mailbox, it just needs to match your email domain. Because the Microsoft 365 SMTP relay authenticates the mail sent from your device or app, this option allows you to relay emails to your own mailboxes and to external recipients. If you only have to send emails to internal recipients, you can usually get away with direct send, which is a bit simpler to set up. However, if you need to send to external recipients as well, SMTP relay is often the better option. To read more about sending emails from apps and devices through Microsoft 365, visit the URL that you see on your screen.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.