"SMTP submit rejected by 452 4.5.3 Too many recipients" on Exchange, while obviously not the case

We are using Exchange Online to send emails, and for past couple of weeks, we have started noticing some errors in our applications that send emails :

When logging the recipients, there are just a couple, nothing extravagant.. Maybe there's a problem, but definitely not something related to the number of recipients.

Any idea what could be wrong and to investigate this ?

With more logs and a bit of help from Miscrofot support, we figured it out and learned a few things on JavaMail in the process.

1. enable low level SMTP debug logs. In most java applications, it will be something like

  mail:
    default-encoding: UTF-8
    host: ${MAIL_HOST}
    port: ${MAIL_PORT}
    properties:
      mail:
        transport:
          protocol: smtp
        debug: true
        smtp:
          debug: true
          auth: false
          starttls: true

when running the application, we got something like that (careful it's likely to be output on standardOut, and not in your regular applicative log file):

DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "BINARYMIME", arg ""
DEBUG SMTP: Found extension "CHUNKING", arg ""
DEBUG SMTP: Found extension "SMTPUTF8", arg ""
DEBUG SMTP: use8bit false
MAIL FROM:<test.user@testabc.com>
250 2.1.0 Sender OK
RCPT TO:<test.user@my-domain.com>
250 2.1.5 Recipient OK
RCPT TO:<kyc_val@my-domain.com>
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [XXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]
RCPT TO:<test.user@testabc.com>
452 4.5.3 Too many recipients ATTR49 [XXXXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]
DEBUG SMTP: Valid Unsent Addresses
DEBUG SMTP:   test.user@my-domain.com
DEBUG SMTP:   test.user@testabc.com
DEBUG SMTP: Invalid Addresses
DEBUG SMTP:   kyc_val@my-domain.com
DEBUG SMTP: Sending failed because of invalid destination addresses
RSET
250 2.0.0 Resetting
DEBUG SMTP: MessagingException while sending, THROW: 
javax.mail.SendFailedException: Invalid Addresses;
  nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [XXXXXXXXXXXXXXXXX.prod.protection.outlook.com 2023-03-15T09:46
:28.930Z 08DB25286CBA473D]
;
  nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 452 4.5.3 Too many recipients ATTR49 [XXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]

We have 2 issues here :

• the mail gateway accepts only sender from the configured domain - which is normal, to avoid open-relay issues, with spammers using your email server. Here, for our tests, we didn't pay attention and used a random sender instead of an address from my-domain.com (ie our domain)

• since the gateway manages our domain, it is aware of which addresses exist or not on our domain. and indeed kyc_val@my-domain.com is a test value that actually doesn't exist in Exchange :

    DEBUG SMTP: Invalid Addresses
    DEBUG SMTP:   kyc_val@my-domain.com

The gateway is configured to tell the SMTP client that some addresses we're sending to don't exist. that's Directory-Based Edge Blocking, explained here.

We discovered there's actually a javamail client parameter to force the emails to be sent nonetheless : setting mail.smtp.sendpartial property to true will send emails to the existing recipients and throw an exception in the code so that we're aware the email could not be sent to some recipients and we handle that case accordingly.

see in https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html

> If set to true, and a message has some valid and some invalid
> addresses, send the message anyway, reporting the partial failure with
> a SendFailedException. If set to false (the default), the message is
> not sent to any of the recipients if there is an invalid recipient
> address.

Conclusion : the initial message we got in the exception is clearly misleading (I would call that a bug). I have no idea why it states "Too many recipients" while it's obviously not the case, but with proper debug logs and configuration on the client side, we were able to understand what was wrong and fix it.