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

Below are some examples of scenarios that are affected by this change, but there could be more:

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

Note: When running this cmdlet, the StartDate and EndDate should not be the same.

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 in the above section Possible scenarios that are affected by this change, 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 (in Subject name or SAN) must be an accepted domain of your organization. In addition, you must update your Inbound connector of OnPremises type to use the unique certificate domain, via property TlsSenderCertificateName. 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 Kamyab Jawan Loan 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.

[Saras870]

Hi @Carolyn_Liu @The_Exchange_Team 

I have a query related to using unique certificate domain configuration during SMTP relay.

Our scenario is similar to this: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail...

I have created a wild card certificate in the email server with CN=*.emailservice.com

In the Exchange online account i have created an accepted  domain as myorg.emailservice.com and created inbound connector with this domain.

But during email relay, email delivery fails with this error: "550 5.7.64 TenantAttribution; Relay Access Denied".

Is this a valid configuration? could you tell  what is wrong here?

[Carolyn_Liu]

@Saras870 

>

I have a query related to using unique certificate domain configuration during SMTP relay.

Our scenario is similar to this: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail...

I have created a wild card certificate in the email server with CN=*.emailservice.com

In the Exchange online account i have created an accepted  domain as myorg.emailservice.com and created inbound connector with this domain.

But during email relay, email delivery fails with this error: "550 5.7.64 TenantAttribution; Relay Access Denied".

Is this a valid configuration? could you tell  what is wrong here?

Answer:

The match in EXO is from the cert domain on the connection with your organization's config. In this case *.email.service.com will not match myorg.emailservice.com. So instead you have two options:

1. Use the cert domain myorg.emailservice.com and keep everything else already setup (accepted domain and connector). and this is recommended. You should always use a specific domain, if possible, to avoid ambiguity.

or

2. Add emaiservice.com as accepted domain, and change the connector name to be *.emailservice.com. But if you do this, you have to make sure no other cert has the root domain of emailservice.com, for example, you may use internet.emailservice.com as the cert to send email to other organizations in the world which they might be hosted in M365. If the latter is true, then #2 definitely is not a viable option.

[Saras870]

hi @Carolyn_Liu , thank you for the reply.

"Use the cert domain myorg.emailservice.com and keep everything else already setup (accepted domain and connector). and this is recommended. You should always use a specific domain, if possible, to avoid ambiguity."

-If my understanding is correct, can we mention the domain name myorg.emailservice.com as Subject alternative name of the certificate? Would that work?

2. 2nd option is not viable as the service would relay to other exchange tenants as well. In this case can we mention each of the tenant's unique domain name in the SAN like below:?

Example certificate-

 CN = emailservice.com

Subject Alternative Name:
DNS:myorg1.emailservice.com, DNS:myorg2.emailservice.com, .....

[LundfeJE]

@Carolyn_Liu -

I have been following this article since it was originally posted, and am confused about the fix for this scenario - 

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.

All I see is the ability to report on it, which doesn't seem to work -

> Start-HistoricalSearch -EndDate "01/01/2024" -StartDate "01/17/2024" -ReportTitle "Report all emails using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress ######

Write-ErrorMessage : |Microsoft.Exchange.Management.Tasks.ValidationException|Invalid notification address or notification address not in accepted domains.

Either way, in most Hybrid environments shouldn't the bulk of NDR's be sent from O365, if the domains are authoratative in the tenant where the recipients exist, and if a NDR needs to be sent, it would go to the originator which would be an accepted domain, and so technically not relaying?

[Carolyn_Liu]

@LundfeJE 

This notification is NOT A FIX on email relay per se, it is that O365/M365 is removing the capability to relay emails where the only "valid" email address is in the header sender - we will start reject such email after we finish the deployment.   The "valid" means the email address must be with your accepted domain.

The report is for you to identify such emails so you can make necessary changes on your end. The report returned error because the notification address is not in your accepted domain.  We cannot support that due to security concern.

As for NDRs, in this case, such emails will NOT be accepted by O365, hence NDRs will NOT be generated by O365. Your on-premises servers will receive a rejection error, and needed NDR will be generated there.  Please read the entire notification carefully in its entirety (since there are several updates since its original publication.)    

[Saras870]

@Carolyn_Liu can you please respond to my comment on Dec 11 please : https://techcommunity.microsoft.com/t5/exchange-team-blog/updated-requirements-for-smtp-relay-throug...

[Carolyn_Liu]

@Saras870 

1. Yes, you can

2. This will work, but is not recommended. Besides the SAN has length limitation, I believe. 

[jdubtx]

@Carolyn_Liu, I would like to co-sign owainwtb's November replies asking that Feedback be considered for this entire Change Event: it was too grossly non-specific, per Tenant, when the change would occur.  I am seeing that our Tenant began receiving the change over a week and a half (certain hosts, relaying in different ways to existing Connectors) and NO Messaging Portal alert that our Tenant was getting the change (contrary to the above post's re-assurance).  

This was not good Change Control, I am +1000 validating owainwtb's earlier statement and complaints.  

I get that MS must get this done, and we are seeing massive changes in standard re-config in how Azure / Google / etc are accepting email replying -- and that is GREAT, we support it.  We just need to come up with a better way to notify individual Tenants when Action-Items reach severe criticality.  "Somewhere in late November through end of Q1 2024" -- and missing direct-to-tenant Messaging (again, I got no warning, I had to track NDRs and Email Delay headers, after-the-fact!) -- is just not an adequate Notification to allow for Tenants'  IT / MSPs /etc to prepare Change Control timelines.  

Please forward that feedback to whoever needs to hear it.  We appreciate MS Engineering, but PLEASE....please do better. 

[Carolyn_Liu]

@jdubtx You can email or IM me the tenant you have encountered the change. We have notified to impacted tenants via Message Center post before each ring deployment. We would like to see why your tenant is missed. 

Again, I want to strengthen it that this is not a per tenant feature enablement, this is a change on the underline infrastructure. We collect the tenants that might be impacted in each ring and notify them, but relay mails do have different behavior on daily basis, so want to make sure that is the case. 

Question to you: Have you run report before to see if your tenant would be impacted or not?  I am trying to understand, what would be the difference (action item on your end) if you get notified that the change is coming? 

[jdubtx]

Yes we ran the report and saw that we might be impacted, and immediately set about changing our Inbound Connectors to use TLS Certificate-based authentication.  We did this in January, but nevertheless it appears that Microsoft still began changes that impacted our Tenant (thank you for the explanation that the changes relate more to Infra, than per Tenant directly, that helps!).   Our Email usage profile, of 1000s of emails with attachments per day, have resulted in it impacting us in a MAJOR way due to our Metadata scrubber suddenly being unable (despite being cleared for TLS Cert authentication-based Relay) to reliably Relay any mail as it has done for years.   

I have searched, searched, and searched for a notifications in Message Center -- there is no post from MS to us about any changes to our Ring of Infrastructure.   Yet we can clearly see that we have been directly-affected by these changes.  It is demonstrable that our Connectors will NOT function if we identify our servers by IP, anymore, we have to have TLD Certificate Identification enabled.  

I will DM you our Tenant GUID, and tickets we have had opened (which have been non-responsive from 365 Support) on this issue we have experienced for about 2 weeks.  It appears to be waning, or reducing, and I see less queueing in our Metadata scrubber on-prem system (which was the main service impacted by this). 

UPDATE: I did not respond to your last question.   If it is genuinely a curiosity, I will explain and walk you through what MS could have done better in terms of notification, and what I would have done differently.   First -- MS needs to more aggressively tie Rings of infra, scheduled for update, to groups of Tenants who have EXO services on that Infra.   Simple.  And they probably already do this, but not for Comms reasons, apparently.  

Obviously this is many Tenants, in some cases, and in other cases -- maybe fewer Tenants (a Venn diagram, of sorts); however, MS by saying they would notify Tenants who have Email configs that might be affected (and then not doing that notification) creates a RISK that could have been mitigated.   It is now obvious we were impacted by MS Infra updates, along with any other Tenants adjacent to us on that same Infra.

Lastly, I would have slated our Metadata scrubbing solution, which at the time of changes did not yet support TLS Certificate Authentication, to no longer route its mail back into our Tenant on its own Connector.  I would have instead routed all Metadata cleaning activity back to Tenant through our on-prem Exchange infra.  That would have avoided this entire mess.  So, I absolutely would have done things differently if MS gave us some kind of individual notice of time of impact!

Microsoft owns its Infrastructure, we are merely Tenants of it, so Microsoft can do whatever the hell it wants without a lot of regard for impact.  It has done so here.  And it should do better.

I support the reasons behind these changes, Spam reduction (and Google, Yahoo, etc are all doing the same) -- but this is MICROSOFT, and Tenant Action Items shouldn't only be relegated to a few Techcommunity posts -- these Infra upgrades have been disruptive enough, to certain Tenants with specific setups (Metadata cleaners, for one) that it should have been mailings and any/all other comms methodologies.  Smoke signals, of items never appearing in our Message Portal, don't count.

PS I DM'ed your requested info.  I hope you find something helpful to at least confirm, on your end, the changes are done and will no longer affect our Tenant.  Good luck, and thanks for the assist.

[Igbins81]

@jdubtx 

Please can you guide with this setup if yours works correctly. We have all application currently using on-premise exchange server for smtp relay and we need to have the start using office 365 smtp relay. I setup the connector and doing some test but no sure what I am doing wrong. Please I need help with this.

Followed this steps and getting error below Configure a TLS certificate-based connector to relay email through Microsoft 365 or Office 365 First, configure your device or application by entering the settings as described in the following table: Expand table |Device or application setting|Value| | -------- | -------- | |Server/smart host|Your MX endpoint, for example, yourdomain- com.mail.protection.outlook.com| |Server/smart host|Your MX endpoint, for example, yourdomain- com.mail.protection.outlook.com| |Port|Port 25| |TLS/StartTLS|Must be enabled and only TLS 1.2 is supported| |TLS Certificate CN (Common Name) or SAN (Subject Alternative Name)|The certificate which has CN or SAN that contains a domain name you've registered with your Office 365 organization.| |Email address|This can be any email address.|

If you already have a connector that's 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 Microsoft 365 or Office 365 SMTP relay. To create or change a certificate-based connector, perform the following steps: Sign in to Exchange admin center. For more information, see Exchange admin center in Exchange Online. On the left navigation pane, select mail flow, select Connectors, and then do the following: If there are no connectors, select + Add a connector. 

 If a connector already exists, select the connector, and then select the edit icon. On the Select your mail flow scenario page, select the Your organization's email server radio button under Connection from. Once you choose Your organization's email server from the Connection from drop-down, Office 365 is automatically chosen from the Connection to drop-down. Enter the connector name and other information, and then select Next. On the Authenticating sent email page, select the first option to use the subject name on the certificate of the sending server to authenticate with Office 365. The domain name in the option should match the CN or SAN in the certificate used by your server, device, or application. Note This domain must be the one that belongs to your organization, that is, this domain should be the one you've registered with Microsoft 365. For more information, see Add a domain to Microsoft 365. For example, Contoso.com belongs to your organization, and it's part of the CN or SAN in the certificate that your service, device, or application uses to communicate with Microsoft 365. If there are multiple domains in the certificate (such as mail1.contoso.com, mail2.contoso.com, and so on), we recommend that the domain in the connector UI be *.contoso.com. 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 may not be registered domains in Microsoft 365.

Error The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (2024-01-30T20:48:11). Exception Message: Cannot send mails to mail server. (Mailbox unavailable. The server response was: 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the message's recipient domain. The connector had either the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set

[Carolyn_Liu]

@jdubtx,

Have you found the MessageCenter post yet? I have confirmed that the (deployment) communication did deliver to your tenant.

[JavierGarces]

Are the new requirements already being applied to all tenants? How can I know if they are being applied to my tenant?

[Robert Grayson]

We got a message in Message Center April 1st. Message ID : MC764454 ,  "We will begin this rollout in late March 2024 and complete by mid-April 2024."

I can only assume at this point the change has been completed? There isn't any further status information. But if anyone from Microsoft can confirm?