OleksiiD
>>>
A bit about the environment:
- Exchange Online (no on-prem Exchange servers)
- Company's domain - DOMAIN.COM
- Some emails are routed to 3rd party server hosted in Azure. Let's assume the server FQDN is SERVER-A.centralus.cloudapp.azure.com
- After processing the email SERVER-A returns it to EO (a dedicated connector was created with IP authentication).
- The envelope sender address P1 (MAIL FROM) can be empty.
Questions
- Does it mean that after November 1st we must switch to the certificate authentication in the inbound connector?
- How does EO validate the cert? What the cert requirements are?
- Can the cert be self-signed? OR is MUST be issued by the trusted root CA?
- Should the cert contain sending server FQDN in CN or subject alternative names SAN ("SERVER-A.centralus.cloudapp.azure.com" in our case)? If so, should server FQDN be added to the accepted domains? if not, how does EO know that the server is allowed to send emails belonging to DOMAIN.COM?
- Should the cert be issued to DOMAIN.COM?
- Should the cert contain both DOMAIN.COM and server FQDN?
- Any other checks?
Answer:
1. Yes. That's the whole blog is about.
2.
- 1 - No. Have to be CA signed
- 2/3 - The cert must be tenant specific (each tenant has their own cert), and has to be CA signed, and either in Subject Alternative Name (SAN) or Issuer contains a tenant specific domain -tenantid.domain.com, you are fine.
- 4 - no, only tenantid.domain.com be part of the cert.
- 5 - in addition, the tenantid.domain.com must be an accepted domain of the tenant
3. Please check the following document (they are also included in the blog, BTW) for guidance and best practice.
Scenario Integrate Microsoft 365 or Office 365 with an email add-on service | Microsoft Learn
Inbound connector: FAQ | Microsoft Learn