IanMcDonald can you please clarify this scenario and tell me if it is in or out of scope for this change?
Sender address being used by on-premises SMTP relay client which uses Exchange on-premises Receive Connector, which then goes via Send Connector to EOP, then to external. Mailbox hosted in EXO also holds that same address.
I was super excited to hear you say on-premises SMTP relay clients are unaffected, but still I know we have quite a few setups just like I've described. Typically NDR's and replies will go to the cloud-hosted mailbox, even though the messages didn't source from the mailbox, rather from the on-premises SMTP relay client.
Edit/Update 2024-10-28: For anyone who was looking for the answer to this question - I did get the answer via direct reply a few months back but don't see it was directly responded to in here. The answer is - ERRL only applies to messages generated from and send out of EXO-hosted mailboxes. It's not the Sender Address alone that matters, it's where the message generated from. Think of it like this:
1.) Messages going into or out of EXO mailboxes have to live within the EXO Limits (i.e., 10K/day and soon 2K-ext/day)
2.) Messages simply passing through EOP, e.g., SMTP relay traffic from on-premises, going up and out via EOP, have to live within EOP Limits, which are very generous. Here are the ones most relevant to this topic:
- Message size limit - The maximum message size for EOP standalone customers, including attachments, is 150 MB.
- Number of outbound messages sent - The limit for the number of outbound messages sent through EOP is high enough to ensure that normal email communication isn’t treated as spam. If you want to send commercial bulk email messages, rather than sending outbound messages through EOP, we recommend that you either use a third-party email service provider (ESP) or send them through your on-premises email servers.
- Recipient limit - As long as the sending host can split the message into "chunks" of fewer than 500 recipients, no explicit limit is defined. However, each "chunk" is effectively treated as a new message. Too many messages in a short period, messages from a host with a poor reputation, or messages with questionable content could be throttled or blocked.