Updated Requirements for SMTP Relay through Exchange Online

[The_Exchange_Team]

Update 11/13/2023: We added new information on how to know when this change is released to your organization.

Today, we are announcing an update to our requirements for SMTP relay through Exchange Online. If your organization does not use Inbound Connectors of OnPremises type then this change will not affect you.

Current Requirements

Currently, to relay email through Exchange Online, two conditions must be true:

1. Any of the following is an accepted domain of your organization:
   1. SMTP certificate domain on the SMTP connection; or
   2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain); or
   3. SMTP header sender domain, as shown in email clients (P2 sender domain).
2. The sending host’s IP address or the certificate domain on the SMTP connection matches your tenant’s Inbound Connector of OnPremises type.

New Requirements

On November 1, 2023, we are removing the matching condition for the SMTP P2 sender domain (1c above). After we remove this condition, relaying email through Exchange Online will require the following:

1. Any of the following is an accepted domain of your organization:
   1. SMTP certificate domain on the SMTP connection; or
   2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain).
2. The sending host’s IP address or certificate domain on the SMTP connection matches your organization’s Inbound Connector of OnPremises type.

After November 1, 2023, if either of the above conditions are not met, the relay attempt from your on-premises environment to Exchange Online will be rejected.

This change may affect your organization’s email routing or delivery. Possible scenarios that are affected by this change include, but may not be limited to:

1. Your organization hosts email on-premises, and you need to relay non-delivery reports (NDRs) generated by your on-premises system through Exchange Online. In this scenario, the NDRs often have null as the SMTP envelope sender (P1 sender), but the SMTP header sender domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.
2. Your organization uses an application hosted on-premises to send email and the SMTP envelope sender domain (P1 sender domain) is not an accepted domain in Exchange Online.
3. You use a third-party cloud service to relay messages by creating an Inbound Connector of OnPremises type. For example, when you use a cloud service platform to relay emails through Exchange Online, the SMTP envelope sender domain (P1 sender domain) will be the 3^rd party service’s domain (perhaps for bounce tracking), but the SMTP header domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.

Check if your organization is affected by this change

You can use the newly created extended report type to generate the report for your organization by running Start-HistoricalSearch, it will generate an extended report specific to this scenario, (see Start-HistoricalSearch documentation.) Some examples below. Replace the value of NotifyAddress below with your email admin email address.

Example 1:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report all emails using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com

Example 2:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails using a specific sender domain (non accepted domain) as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -SenderAddress *@MyDomain.com

Please note that senderAddress must be an accepted domain of your organization.

Example 3:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails for a recipient domain using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -RecipientAddress *@mycustomer.com

Please note that RecipientAddress CAN contain any domain that your organization send emails to.

You can use Get-HistoricalSearch to report the status of the extended report job:

Get-HistoricalSearch -JobId xxxx (where the xxxx is the JobID.)
If the job result (ReportStatusDescription) is “Complete – No results found”, that means you organization is not impacted by the scenario.

Actions to Take

To minimize the effects of this change before November 1, 2023:

1. If you need to relay emails from on-premises through Exchange Online, and some of these emails apply to the scenarios indicated above, you must update your Inbound Connector of OnPremises type to use a certificate domain (instead of IP addresses), in addition, you must add the certificate domain as an accepted domain of your organization. To learn more, see Configure a certificate-based connector to relay email messages through Microsoft 365.
2. If you need to use a third-party add-on service to process email messages sent from your organization and then relay through Exchange Online, the third-party service must support a unique certificate for your organization, and the certificate domain must be an accepted domain of your organization. An example is that your organization uses a third-party CRM cloud service to send emails on behalf your organization to mailboxes of your company or other external users. To learn more, see Scenario: Integrate Exchange Online with an email add-on service.

How to know when this change will be available for your organization?

We will be notifying customers via Office 365 Message Center when this change is about to deploy into their respective rings, with a start and expected end time. The title for the message center post will be “Deployment time for Updated Requirements for SMTP Relay through Exchange Online”. If your organization has not received any notification yet, it is either not impacted by this change based on our report, or your organization is not a part of the next batch to get the feature deployed yet.

We will be updating this blog post (as well as posting in the Office 365 Message Center) when the entire deployment is completed, which currently is set to be by 3/31/2024.

Exchange Online Transport Team

[Saras870]

Hi @Carolyn_Liu ,

Is there any way we can know if this change has gone for live for our EXO tenant?(since it is past Nov 1st)

[Carolyn_Liu]

@Robert Grayson @Saras870 @mkcj1984 

We are starting the deployment, but it is by rings, and will take some time for the change to take effect for WW.    We expect it will complete all deployment in early Q1 2024.

[mkcj1984]

How long is it expected to take? Also, can you tell if a specific tenant has the change in place?

[Robert Grayson]

We need to know exactly when the change is done to our tenant. 

If not by a notification by Microsoft, at least a way we can self identify the change is done.

We Exchange admins need to know the state of this change in a timely manner so we can inform the business to test or monitor their changes and ensure emails continue to send. 

[Saras870]

Thanks @Carolyn_Liu 

What will be the error message and code from Exchange when we try to relay an email that does not follow the new requirements?

[owainwtb]

To backup what others have said, we need to know when this gets changed in our tenants.  If there's any reported issue with email relaying from now until early Q1 2024 (and that could mean until February?) how are we to know if it's related to this change or not?  How will Microsoft support know if we raise a call related to a relay error?

I think it's a basic requirement to inform people when a change to their tenant is made, and Microsoft has been poor at doing this on a number of changes like this.

To be clear this criticism isn't aimed at @Carolyn_Liu, who I think has been excellent in this blog, but I think it needs to be fed back to whoever plans and managers these changes.

[Carolyn_Liu]

Unfortunately, this change is at the system level, not at tenant level, therefore it is unable to report at tenant level that the change has been applied. We do plan to inform everyone, when deployment completed, and for sure it won't finish by EOY, and we aim at Q1 2024. 

When the change does get deployed to your org, and from the previous extended report you do see your organization were impacted, then you should see one of the SMTP errors below:

• "550 5.7.64 TenantAttribution; Relay Access Denied."
• "451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35."
• "451 4.4.4 Mail received as unauthenticated, incoming to a recipient domain configured in a hosted tenant which has no mail-enabled subscriptions. ATTR5."
• Email rejected with "452 4.5.3 Different recipient domain on a smart-hosted and non-authenticated email. Sending server should retry this recipient separately next."

in addition, for the 1st error, the client should get an NDR, and for the rest errors mails from your on-premises environment would be queued.   

@Saras870 @owainwtb @Robert Grayson @mkcj1984 

[Carolyn_Liu]

@MRI503Outlook 

>I can understand your point that a connector is not needed in my scenario per Microsoft, but shouldn’t there be some concern about the outcome? Messages meant for one tenant were redirected to another based on a connector and shared Microsoft infrastructure?  What would happen in a scenario where two different tenants both had connectors for the same set of IPs or certificates and they were on shared Microsoft infrastructure as in the scenario we experienced?

Answer: to clarify, this only impacts mails sent from your organization, it won;t affect other people's mail. Basically you created the Inbound connector, and requested this: any mails are sent from my domain(regardless of the recipients), and using this certificate blah, should be attributed to me.

Again, Inbound OnPremises connector should NOT be used for mails coming common 3rd party cloud services, in fact no connector is needed in this scenario. 

We are planning to add restrictions in the future for such behavior. However, there may be other cons associated with it.  

[Saras870]

Thanks @Carolyn_Liu 

I have few more queries:

1)"550 5.7.64 TenantAttribution; Relay Access Denied": This error is seen for external non microsoft recipients.

Will the error for external microsoft recipients be this: "4.4.62 Mail sent to the wrong Office 365 region" 

Can you please confirm?

2)Is there a way to tell in which regions the change has gone live so far? example: US, Europe ?

3)One more query:

If my accepted domain contains mycompany.com and there is an email arriving with P1 header as 1)"test.mycompany.com" and 2) "abc.test.mycompany.com" (I have used ip address based authentication) , will both mails 1) and 2)  get rejected?

[Carolyn_Liu]

@Saras870 

1)"550 5.7.64 TenantAttribution; Relay Access Denied": This error is seen for external non microsoft recipients.

Will the error for external microsoft recipients be this: "4.4.62 Mail sent to the wrong Office 365 region" 

Can you please confirm?

Answer: yes, see my above reply.

2)Is there a way to tell in which regions the change has gone live so far? example: US, Europe ?

Answer: I may notify in this blog, depend on feasibility, check back often. 

3)One more query:

If my accepted domain contains mycompany.com and there is an email arriving with P1 header as 1)"test.mycompany.com" and 2) "abc.test.mycompany.com" (I have used ip address based authentication) , will both mails 1) and 2)  get rejected?

Answer: Yes, subdomains are not considered as accepted domains in sender case.

[owainwtb]

@Carolyn_Liu, Can I respectfully ask that this is feedback as part of the lessons learnt after this work is complete.

It is imperative that changes of this magnitude have a method for informing customers when they are implemented in their environments, this is exactly what Microsoft DID do for last years Basic Authentication change, a message was put in our Message Center informing that the change had been implemented in our tenant.

If this is not possible in this situation due to the way the change is being implemented, then I respectfully suggest that this also needs reviewing as it was possible with Basic Authentication and this was arguably a bigger change, hence showing it can be done.

I really need Microsoft to understand how impactful these types of changes could be and that proper change control practices should be followed, if I make a large change in my organisation I have to produce a full comm's plan that includes informing the exact date(s) when a change will be made so customers are aware, if I don't have this comm's plan then the charge is not approved.

[Saras870]

Thanks @Carolyn_Liu 

"Yes, subdomains are not considered as accepted domains in sender case."

1)Just to re-clarify ,our scenario is there are two connectors configured in EXO tenant(The accepted domains are mycompany.com)

O365 to Your Org(Outbound connector to a email server)

Your org to O365(email server to Exchange Online)

An email is sent from user1@test.mycompany.com to email address removed for privacy reasons

.Will the relay fail?Can you please confirm?

2)I tried to test this scenario by adding a sub domain- test.mycompany.com using POST REST API : https://graph.microsoft.com/v1.0/domains  (but it automatically got added as an accepted domain) and  send an email from user email address removed for privacy reasons  to an external user, the relay was fine.

I would like to understand in what scenarios an email can be sent from a sub domain that is not an accepted domain in Exchange online? (Because if  i add a domain in Microsoft Admin center its automatically added in accepted domains.)

[Carolyn_Liu]

@Saras870 

>I would like to understand in what scenarios an email can be sent from a sub domain that is not an accepted domain in Exchange online? (Because if  i add a domain in Microsoft Admin center its automatically added in accepted domains.)

Answer: You have to either satisfy 1.a or 1.b in the blog.  If your intention is to relay emails from subdomain.mycompany.com, and only mycompany.comis accepted domain but subdomain.mycompany.com is not. then the only way you can relay is satisfy condition 1.a., ie. create Inbound connector (Your Org->Office 365) and uses a cert domain, this cert domain is mycompany.com (or any other accepted domain in your org.)

May I also ask why is it confusing? There must be something does not click, I just don;t know what it is and would like to know.

[Carolyn_Liu]

@owainwtb 

But on a different angle, I am also puzzled why the volume of this ask. We provide tools so our customers know if the change would impact them; we also give instructions as what changes are needed to avoid the impact. So if I am an admin, I would run the report and check the result, if it impacts me, I will make the change, then I run a report again to ensure my change did apply and the problem is fixed. Then I don;t care when Microsoft will make the change and I don't want to wait till Microsoft pull the plug to validate the result, because it would be too late.

Am I missing something?

[Robert Grayson]

@Carolyn_Liu 
If I may provide some feedback to "Am I missing something?"

Within a large organisation you will have Exchange administrators within a team who are the owners of the service within the org, and then additional teams within the org that will utilise the Exchange platform to send email. Just like Microsoft cannot directly influence a customer to make a change, also within the organisations that use Exchange, the Exchange admins do not necessarily have direct influence to make the changes required and are outside our direct control. Teams within an org may ignore or not act in time on the advice of the Exchange administrators. When Microsoft do make the change, we need the knowledge so we can identify if something is the root cause a problem, if that happens to be the Microsoft change, then we can advise accordingly. If it's not, then there are many other reasons why email can fail in an organisation.

We shouldn't have to guess, and service owners shouldn't have to wear the blame from a business for not knowing what is going on because a vendor doesn't inform its customers. It's professional curtesy.

From Microsoft's point of view, by keeping us informed you're protecting the customers who have chosen and have advised to use your product within orgnasation. Look after your customers, listen to service owners. They can potentially adopt other services if the pain is too much.

[owainwtb]

@Carolyn_Liu 

To be frank, yes you are completely missing the point.

Regardless of the tools you are making a Major change in peoples tenants, any change control practices will state that the dates of when a change is implement should be communicated to the affected customer, in this case anyone using M365 with a SMTP relay.  Customers should be notified of the date this change is made in their tenant, regardless of any tools or instructions given - it's change control standard practice.

Also, if your stance is that we give you instructions and tools so don't need to tell you, a few points:

• The instructions have changed over the course of this blog as they weren't detailed enough to begin with, thus relying on people to query what they being/not being told and also to revisit this thread for any update, changes.  If you're saying people should be using this information to mitigate any impact then provide the complete picture and information on day 1, don't drip feed it.
• The report that identifies what email will be impacted was only made available 5 weeks before the start of this change, that is an incredibly short time to identify, investigate and remediate impact for people who could be sending millions of emails a month via relay.  Previous to this I'd done an investigation based on reviewing sending logs and thought we were not impacted only to find by the report that we were, it was like looking for a needle in a haystack without the report and I, and probably others, wasted a lot of time, that having the report made available in timely fashion, would have saved.
• I find the statement "So if I am an admin, I would run the report and check the result, if it impacts me, I will make the change, then I run a report again to ensure my change did apply and the problem is fixed. Then I don;t care when Microsoft will make the change and I don't want to wait till Microsoft pull the plug to validate the result, because it would be too late." incredibly naïve and also dis-respectful, it insinuates that this is a trivial task and that we have plenty of free time to just pickup the work, so if we haven't identified and mitigated all issues in the 5 weeks before the change, when the required report was made available, we haven't done our jobs and any impact is entilely our fault.
• This stance is also contradicted by last years Basic Authentication change where Microsoft did notify people when the change was applied to their tenant.

To reiterate my opinion, this is a Major change with potentially high impact, you should be informing customers when this change is implemented in their tenants, that it could happening between now and the end of Q1 2024 isn't following change control practices.

I'm not expecting this to change for this piece of work but it does need to be feedback that this should be a requirement for future changes.

[OleksiiD]

Hi,

@Carolyn_Liu 

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

1. Does it mean that after November 1st we must switch to the certificate authentication in the inbound connector?
2. How does EO validate the cert? What the cert requirements are?
   1. Can the cert be self-signed? OR is MUST be issued by the trusted root CA?
   2. 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?
   3. Should the cert be issued to DOMAIN.COM?
   4. Should the cert contain both DOMAIN.COM and server FQDN?
   5. Any other checks?

Oleksii,

Thanks.

[Carolyn_Liu]

Tnx everyone for the valuable feedback.

The blog has been updated, we add the last section with regard to notification of the deployment date. Please check it out.  We will try our best to post the accurate timeline.   

[Carolyn_Liu]

@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

1. Does it mean that after November 1st we must switch to the certificate authentication in the inbound connector?
2. How does EO validate the cert? What the cert requirements are?
   1. Can the cert be self-signed? OR is MUST be issued by the trusted root CA?
   2. 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?
   3. Should the cert be issued to DOMAIN.COM?
   4. Should the cert contain both DOMAIN.COM and server FQDN?
   5. 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

[lashly]

When it comes to the updated requirements for SMTP relay through Exchange Online, staying current is key. Regularly check official guidelines and documentation to align your settings with the latest recommendations. This ensures a secure and efficient email relay process. If you have specific queries, don't hesitate to ask for tailored assistance.

[lashly]

Staying current with SMTP relay updates for Exchange Online is crucial. Regularly check Microsoft's documentation for changes. Engaging in forums, like the Ehsaas Program, can provide insights. Adapting swiftly ensures the security and reliability of your email infrastructure. Feel free to ask for further assistance.

[lashly]

For the latest on SMTP relay through Exchange Online, it's essential to stay updated with official documentation or community forums. If you encounter any issues, consider seeking assistance from the community or referring to resources related to the program. Stay informed for optimal email service performance.