Methods of Integrating Multifunction Devices with Microsoft 365 – Part 2.

In the article Methods of Integrating Multifunction Devices with Microsoft 365 – Part 1, we have learnt about Multifunction Devices, components of MFD’s and 3 different ways how MFD’s connects to Microsoft 365. In this part we will focus on the remaining methods of connecting MFD’s to Microsoft 365.

Method 4: High Volume Emails (with Modern Auth).

High Volume Emails (HVE) also supports Modern Auth to send emails. In this method, the MFD uses tokens to authenticate the connection to Microsoft Endpoint and then send the emails.

Concept of using High Volume Emails (Modern Auth).

• We register the organization’s in-house or third party application in Microsoft Entra ID Enterprise Applications.
• Copy the Application ID, Client Secret of the registered application from the Enterprise Applications page.
• The registered application in Microsoft Entra ID needs to be provided (Mail.Send) Delegate permission or Application permission on Exchange Online instance of the tenant.
  • If the Delegate permission are used then we have to use HVE mail user’s credentials in the MFD to request a token.
  • If the Application permission are used then we have to use Application client secret in the MFD to request a token.
• Application will either send HVE mail user’s credentials or the Application Client Secret to Microsoft Entra ID.
• Microsoft Entra ID will authenticate the details sent by the MFD, and after that the application permissions will be checked on Exchange Online instance of the tenant.
• Microsoft Entra ID will send the Token to the MFD.
• The MFD will use the Token to authenticate to Microsoft 365 Endpoint.
• Once the connection to the Microsoft 365 Endpoint will establish, the MFD will send the email.

Method 5: Email Communication Services in Azure.

If an organization wants to send the emails to Internal and External users using SMTP AUTH, then they can use the Email Communication Service resource in Azure to send the emails. Email Communication services resource cannot send the email alone, it needs help from Azure Communication Service (another resource in Azure) and Microsoft Entra Enterprise Application. So these 3 different resources will work together with the Multifunction Device or organization’s inhouse application to send the email to the intended recipients.

Concept of sending email using Email Communication Service.

• Deploy Azure Communication Service instance.
• Deploy Email Communication Service resource.
• Connection between Azure Communication Services Instance and Email Communication Services resource.
• Verify a custom domain in Azure (To increase the authenticity of the email).
• Connect the custom domain to Email Communication Service resource.
• Register an Enterprise Application and create the client secret (Password).
• Connect the Enterprise Application to Azure Communication Services.
• User the credentials in the MFD or the organization inhouse application to send the email.

Below settings should be configured in MFD to send email using Email Communication Service resource.

• Server / smart host: smtp.azurecomm.net
• Port: 587
• TLS / StartTLS: Enabled.
• Username and password to be used in MFD: Enter the Microsoft Entra application credentials from an application with access to the Azure Communication Services Resource.

Follow the article for more details about Setting up Email Communication Services in Azure.

Method 6: Direct Send.

Direct Send method does not requires any password to be used while sending the email using MFD’s. The organization will simply need to use the smart host as the MX record for any accepted domain in the tenant. In the email address section, use any email address of the domain added as an accepted domain in the tenant. Port number 25 should be used, TLS is optional (does not require the MFD to have TLS enabled). It is recommended to use a Static Public IP Address for the MFD, and add the Static Public IP Address in the SPF record.

Below settings should be configured in MFD to use Direct Send method.

• Server/smart host: Organization’s MX record entry. Example, aashu-co-in.mail.protection.outlook.com (IP address of MX record should not be used).
• Port: 25
• TLS/StartTLS: Optional
• Email address: Organization can use any email address present in the accepted domains. This email address doesn’t need to have a dedicated mailbox.
• SPF, DKIM, DMARC should be configured on the domain to increase the email authenticity.

Direct Send method can be used in the below scenarios.

• The organization has disabled the SMTP AUTH protocol.
• The legacy application or Multifunction device does not support passwords. (no option to setup password).
• The legacy application or Multifunction device does not support TLS /StartTLS.
• The organization wants to send the email to only internal users in the organization.
• Organization wants to send higher volume of emails to internal users in the organization.
• The organization does not want to use a Licensed Mailbox to send emails to the internal users.

Direct Send will not work if.

• The IP address of the MFD is blocked by any third party DNS RBL’s.
  • Error: Mailbox unavailable. The server response was: 5.7.1 Service unavailable, Client host [XXX.XXX.XX.XX] blocked using Spamhaus. To request removal from this list see https://www.spamhaus.org/query/ip/XXX.XXX.XX.XX

• Port number 25 is blocked by the ISP.
  • Error: Unable to connect to the remote server.

Key points to remember about Direct Send.

• The emails sent using Direct Send are subjected to AntiSpam checks in EOP, so SPF, DKIM and DMARC should be enabled for the sender domain.
• Make sure the IP address used by the Multifunction Device is not blocked by any third party DNS RBL.
• Make sure that the port number 25 is not blocked by the ISP.
• Direct Send can only send the emails to internal users in the organization.
• Static IP address (for MFD) is recommended.

Method 7: SMTP Relay.

Using the SMTP Relay method, an organization can send the emails to internal and external recipients. In this method, a connector is created from on premises server to Exchange Online either using Static IP Address or the TLS Certificate used by the on premises server. Any emails sent using the connector will be authenticated (this is why there is no need of password in this method). Only the emails sent using the IP Address or the emails encrypted using the TLS Certificate will be considered s authenticated and will be accepted in Microsoft 365.

Below settings should be configured in MFD to send email using SMTP Relay method.

• Server/smart host: Organization MX record entry. Example, aashu-co-in.mail.protection.outlook.com
• Port: 25
• TLS/StartTLS: Must be enabled and only TLS 1.2 is supported.
• TLS Certificate: The certificate with CN or SAN of any accepted domain in Microsoft 365 (If a connector is created using certificate used).
• Email Address: Organization can use any email address present in the accepted domains. This email address doesn’t need to have a dedicated mailbox.

SMTP Relay will not work if.

• The static IP Address used by the organization is blocked by any third party DNS RBL’s.
  • Error: Mailbox unavailable. The server response was: 5.7.1 Service unavailable, Client host [XXX.XXX.XX.XX] blocked using Spamhaus. To request removal from this list see https://www.spamhaus.org/query/ip/XXX.XXX.XX.XX

• Port number 25 is blocked by the ISP.
  • Error:Unable to connect to the remote server.

• The certificate or the static IP address used in the connector is changed.
  • Error: 5.7.XX TenantAttribution; Relay Access Denied or 4.4.XX Mail sent to the wrong Office 365 region.

Key points to remember about SMTP Relay.

• The email address used in SMTP Relay does not requires a mailbox.
• Using SMTP Relay method emails can be sent to internal as well as external users.
• Emails sent using SMTP Relay method are subjected to antispam check in EOP.
• Static IP address or a certificate with SAN / CN of any accepted domain in Microsoft 365 should be used.
• Make sure that the Static IP address should not be blocked by any third party DNS RBL.
• Port number 25 should not be blocked by the ISP.

Comparison of all the options to send the emails.

There are multiple methods using which an organization can send the emails to internal or external emails recipients. Every method has its own advantages and drawbacks, an organization can choose the methods based on the organizations requirement. We should avoid using the methods which are currently using basic authentication and should replace them with methods using modern authentication.