How to set up a multifunction device or application to send email using Microsoft 365 or Office 365
Article
This article explains how you can send email from devices and business applications when all of your mailboxes are in Microsoft 365 or Office 365. These devices and applications create email messages, but are incapable of sending those messages without help, because they aren't email servers. For example:
Network-connected scanners that send scanned documents as attachments in email messages.
Line-of-business (LOB) applications that need to send email messages. For example, an appointment application that sends email reminders to participants.
The following methods are available to send email from these devices or applications using Microsoft 365 or Office 365:
Client SMTP submission (also known as authenticated SMTP submission or SMTP AUTH): Send authenticated email using the credentials of a cloud mailbox. POP3 or IMAP4 clients use this method to send email.
SMTP relay: Send email as an email server through Microsoft 365 or Office 365. The connection is authenticated using an inbound connector.
Direct Send: Send unauthenticated email as an external email server directly to Microsoft 365 or Office 365.
Here's a comparison of each method and the features they support:
Client SMTP submission
SMTP relay
Direct Send
Features
Send to recipients in your domain or domains
Yes
Yes
Yes
Relay to the internet via Microsoft 365 or Office 365
Yes
Yes
No
Bypass anti-spam
Yes, if the email is destined for one of your Microsoft 365 or Office 365 mailboxes.
No. Suspicious email might be filtered. We recommend an SPF record entry.
No. Suspicious email might be filtered. We recommend an SPF record entry.
Supports mail sent from applications hosted by a third party
Yes
No
Yes. We recommend updating your SPF record to allow the third party to send as your domain.
Saves to Sent Items folder
Yes
No
No
Requirements
Open TCP port
587 or 25
25
25
Device or application server must support TLS
Required
Optional
Optional
Requires authentication
Microsoft 365 or Office 365 username and password required
One or more static IP addresses. Your printer or app host requires a static IP address that's visible to Microsoft 365 or Office 365 for authentication.
None
Here are the limitations of each method:
Limitations
Client SMTP submission
Direct Send
SMTP relay
Throttling limits
10,000 recipients per day. 30 messages per minute.
Standard throttling for anonymous email sent from the internet to Microsoft 365 or Office 365.
The rest of this article describes each method in detail.
Client SMTP submission: Authenticate mail sent from your device or application through a cloud mailbox
Note
Client SMTP submission using Basic authentication in Exchange Online is scheduled for deprecation in September 2025. We strongly recommend using one of the following alternative methods instead:
Client SMTP submission supports the following scenarios:
Send email from a third-party hosted application, service, or device.
Send email to people inside and outside your organization.
The device or application must be able to authenticate with Microsoft 365 or Office 365. The email address of the mailbox appears as the message sender.
Send email to people inside and outside your organization.
Bypass most spam checks for email sent to people in your organization. This bypass can help prevent your company IP addresses from being added to a spam blocklist.
Send email from any location or IP address, including your on-premises network, or a third-party cloud-hosting service like Microsoft Azure.
Requirements for client SMTP submission:
Authentication: We recommend using Modern authentication in the form of OAuth. For more information about OAuth, see Authenticate an IMAP, POP, or SMTP connection using OAuth. If SMTP AUTH is intentionally disabled in the organization or on the designated mailbox, use a different method.
Mailbox: You need a licensed Microsoft 365 or Office 365 mailbox that the device uses to send email from.
Transport Layer Security (TLS): Your device or application must support TLS 1.3 or TLS 1.2. If your device or application doesn't support TLS 1.2 or later, you can't use client SMTP submission with Microsoft 365 or Office 365.
TCP Port: Port 587 (recommended) or port 25 is required and must be unblocked on your network. Some network firewalls or ISPs block port 25 because that port is used by email servers to send messages.
Tip
If your device or application recommends or defaults to TCP port 465, it doesn't support the required versions of TLS for client SMTP submission in Microsoft 365 or Office 365.
DNS: Use the DNS name smtp.office365.com. Don't use an IP address for the Microsoft 365 or Office 365 server.
Limitations of client SMTP submission:
If the device or application needs to send email from an account (mailbox) that's different from the account that's used to authenticate, the sign-in account needs Send As permission in the mailbox. Otherwise, messages are returned in a nondelivery report (also known as an NDR or bounce message):
5.7.60 SMTP; Client does not have permissions to send as this sender.
Basic authentication or anonymous relay through an on-premises email server.
When the device or application needs to send more email than a mailbox allows.
An inbound connector in Microsoft 365 or Office 365 authenticates your device or application using a TLS certificate (recommended) or public IP address. Authentication helps to identify messages as belonging to your organization so they aren't identified as spam or spoofing.
Your device or application can send email using any address (including email addresses that can't receive email), as long as the address in an accepted domain. The email address doesn't need to be associated with a mailbox. For example, if your Microsoft 365 domain is contoso.com, the device or application could send mail using an address like do_not_reply@contoso.com.
You can't use SMTP relay to send email from a third-party hosted service (for example, Microsoft Azure) through Microsoft 365 or Office 365. For more information, see Troubleshoot outbound SMTP connectivity issues in Azure.
Features of SMTP relay:
Doesn't require a licensed Microsoft 365 or Office 365 mailbox to send email.
Higher sending limits than client SMTP submission. Senders aren't subject to the limits of client SMTP submission.
Requirements for SMTP relay:
A certificate or static public IP address: If the device or application can't use a certificate for authentication, use a static IP address that isn't shared with another organization.
Connector: Set up an inbound connector in Microsoft 365 or Office 365 as described in this section.
TCP Port: Port 25 is required. Verify this port isn't blocked on your network or by your ISP.
Limitations of SMTP relay:
Mail can be disrupted if your IP addresses are added to a spam blocklist.
Requires static unshared IP addresses (unless a certificate is used).
The device or application is expected to retry failed connection within a reasonable amount of time. Microsoft recommends using SMTP logs on the device or application to help investigate these types of failures.
Configure a TLS certificate-based connector for SMTP relay
Before you start, you need a certificate where the Subject or Subject Alternate Name (SAN) fields contain an accepted domain in Microsoft 365 or Office 365.
Configure your device or application using the settings described in the following table:
The Subject or SAN fields of the certificate contain a verified accepted domain in Microsoft 365 or Office 365.
Email address
Any email address in the accepted domain.
Tip
The device or application might use different names for the settings, so check their documentation for instructions.
Create a certificate-based inbound connector in Microsoft 365.
If you already have an inbound connector configured to deliver messages from your on-premises organization to Microsoft 365 or Office 365 (for example, a hybrid environment), you probably don't need to create a dedicated connector for SMTP relay.
Existing hybrid customers who used the Hybrid Configuration Wizard to configure their connectors should check their existing connector to ensure that it uses *.contoso.com instead of mail.contoso.com or hostname.contoso.com. This domain verification is because mail.contoso.com and hostname.contoso.com might not be registered domains in Microsoft 365.
To create a certificate-based connector, do the following steps:
When you're finished on the Connector name page, select Next.
On the Authenticating sent email page, verify By verifying that the subject name on the certificate that the sending server uses to authenticate with Office 365 matches the domain entered in the text box below (recommended) is selected.
In the box, enter an accepted domain in Microsoft 365 or Office 365 that matches the Subject or SAN fields in the certificate used by your server, device, or application.
For example, contoso.com in an accepted domain in your Microsoft 365 organization, and contoso.com is included in the Subject or SAN field in the certificate that's used on the device or application.
Tip
If multiple hosts are identified in certificate (one in the Subject field and one or more in the SAN field), we recommend using the value *.contoso.com in this box.
When you're finished on the Authenticating sent email page, select Next.
On the Review connector page, verify the configuration of the connector. Use the links on the page or select Back to make changes.
When you're finished on the Review connector page, select Create connector.
To test the configuration, send a test email from your device or application, and confirm the recipient receives it.
Configure an IP address-based connector for SMTP relay
If you can't configure a certificate-based connector, configure an IP address-based connector to relay email through Microsoft 365 or Office 365.
Before you start, get the public IP address used by the device or application. This IP address is visible to Microsoft 365 or Office 365 as the source of email from the device or application.
Note
Dynamic IP addresses aren't supported or allowed.
Don't share the IP address with anyone outside of your organization (the IP address is used for authentication on the connector).
Configure your device or application using the settings described in the following table:
Any email address in the verified accepted domain in Microsoft 365 or Office 365. The email address doesn't need a mailbox.
Create an IP address-based inbound connector in Microsoft 365.
If you already have an inbound connector configured to deliver messages from your on-premises organization to Microsoft 365 or Office 365 (for example, a hybrid environment), you probably don't need to create a dedicated connector for SMTP relay.
When you're finished on the Connector name page, select Next.
On the Authenticating sent email page, select By verifying that the IP address of the sending server matches one of the following IP addresses which belong exclusively to your organization.
In the box, enter the public IP address of the device or application.
When you're finished on the Authenticating sent email page, select Next.
On the Review connector page, verify the configuration of the connector. Use the links on the page or select Back to make changes.
When you're finished on the Review connector page, select Create connector.
To test the configuration, send a test email from your device or application, and confirm the recipient receives it.
Direct Send: Send mail directly from your device or application to Microsoft 365 or Office 365
Note
Most customers don't need to use Direct Send. We're working on an option to disable Direct Send by default to protect customers.
If your device or application can act as an email server, no Microsoft 365 or Office 365 settings are required. For more information, see your device or application instructions.
We recommend Direct Send only for advanced customers willing to take on the responsibilities of email server admins. You need to be familiar with setting up and following best practices for sending email over the internet. When correctly configured and managed, Direct Send is a secure and viable option. But customers run the risk of misconfiguration that disrupts mail flow or threatens the security of their communication.
Choose Direct Send only when your legacy device or application doesn't support any of the previously described methods.
The application or device needs to send email using address in an accepted domain in Microsoft 365 or Office 365. In addition to SPF, You need to configure DKIM and DMARC correctly for the domain. Misconfiguration can lead to security gaps.
Doesn't require a licensed cloud mailbox, but you need to use an address associated with an accepted domain in Microsoft 365 or Office 365.
Limitations of Direct Send:
Can't deliver email to external recipients (for example, recipients with Yahoo! or Gmail addresses).
Messages are just like anonymous email from the internet (all scanning and protections applies).
Email might be disrupted if the IP address is on a spam blocklist.
Microsoft 365 and Office 365 use throttling policies to protect the performance of the service.
Set up Direct Send
Configure your device or application using the settings described in the following table:
Any email address in an accepted domain in Microsoft 365 or Office 365. The email address doesn't need to have a mailbox.
Tip
The device or application might use different names for the settings, so check their documentation for instructions.
Run diagnostic to help set up devices or applications that send email using Microsoft 365 or Office 365
Tip
This feature requires a Microsoft 365 administrator account.
If you need help with setting up devices or applications to send email using Microsoft 365 or Office 365, you can run an automated diagnostic using the following button:
A flyout opens in the Microsoft 365 admin center. Select the appropriate option (for example, new setup or troubleshooting existing setup).
Use your own email server to send email from multifunction devices and applications
If you happen to have an on-premises email server, you should seriously consider using it for SMTP relay instead of Microsoft 365 or Office 365. A local email server that you physically control is easier to configure for SMTP relay.
Appendix: Find the MX record for the chosen accepted domain in Microsoft 365 or Office 365
SMTP relay and Direct Send require the Points to address or value value from the MX record for the accepted domain in Microsoft 365 or Office 365 that contains the email address you plan on using to send email from the device or application. This value uses the syntax <YourCustomDomain>-com.mail.protection.outlook.com (for example, contoso-com.mail.protection.outlook.com).
To find this value for your domain, do the following steps:
On the Domains page, verify the Status value of the domain you plan on using is Healthy. If the domain isn't verified, email could be lost, and you can't use message trace to track the lost messages.
Select the domain by clicking anywhere in the row other than the check box next to the first column.
On the domain details page that opens, select the DNS records tab. The MX record for the domain is listed in the Microsoft Exchange section.
Select the MX entry by clicking anywhere in the row other than the check box next to the first column.
In the MX record flyout that opens, copy the Points to address or value. For example, contoso-com.mail.protection.outlook.com.
This module examines how clients connect to Microsoft 365. It also provides instruction on how to configure name resolution and Outlook clients, and how to troubleshoot client connectivity.
Plan and execute an endpoint deployment strategy, using essential elements of modern management, co-management approaches, and Microsoft Intune integration.
Add a connector.
