IP/subnet blocked should not cause soft bounce (hotmail, live, outlook)

[Alpha1]

Affected version

2.3.8

There are several situations where soft bounces is received for perfectly valid email addresses.
This happens quite often with email providers like Microsoft which has its own sender reputation system. (hotmail, live, outlook, custom domains, etc) Microsoft hosts about 25% of all email so this issue has high impact. Especially for big boards.

Here are some of the situations which often occur:

• IP rate limited. This happens when you send out a lot of email or trip internal email reputation standards.
  

  554 4.4.7 Message expired: unable to deliver in 840 minutes.<451 4.7.650 The mail server [xxx.xxx.xxx.xxx] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https:\/\/aka.ms\/postmaster (S843) [DS3PEPF000099D7.namprd04.prod.outlook.com

  
  
• IP subnet blocked. This is purely coincidental and happens when another email sender that has an IP close to your IP is limited.
  

  \"bounceType\":\"Transient\",\"bounceSubType\":\"General\",\"bouncedRecipients\":[{\"emailAddress\":\"xxx@hotmail.com\",\"action\":\"failed\",\"status\":\"5.7.1\",\"diagnosticCode\":\"smtp; 550 5.7.1 Unfortunately, messages from [xx.xxx.xx.xxx] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http:\/\/mail.live.com\/mail\/troubleshooting.aspx#errors.

XenForo will keep sending to such addresses until multiple soft bounces will set the user state for these valid addresses to Bounced. This is unwanted behavior. Currently the only way to counter this is to keep raising the number of required bounces, but that damages sender reputation. Low sender reputation leads to rate limiting or blocking, spiraling this issue further. This disrupts the process of bounce processing.

If bounce messages come in indicating the above, this should not cause a soft bounce because the email addresses are perfectly valid.
The issue is that the email provider will temporarily not accept your email and wants you to 'snooze' your email sending or contact them to resolve it.

The solution could be to snooze sending to the email provider for X weeks and cause an error in the error log.

 

[smallwheels]

Microsoft hosts about 25% of all email

Hu? Where did you get this number from? Seems very high - I highly doubt that it is accurate.

 

[Alpha1]

I think you are correct. MS has about 13% while gmail leads with 17%.

Usage Statistics and Market Share of Email Server Providers, January 2026

What are the most popular email server providers

w3techs.com

 

[smallwheels]

XenForo will keep sending to such addresses until multiple soft bounces will set the user state for these valid addresses to Bounced. This is unwanted behavior. Currently the only way to counter this is to keep raising the number of required bounces, but that damages sender reputation. Low sender reputation leads to rate limiting or blocking, spiraling this issue further. This disrupts the process of bounce processing.

If bounce messages come in indicating the above, this should not cause a soft bounce because the email addresses are perfectly valid.
The issue is that the email provider will temporarily not accept your email and wants you to 'snooze' your email sending or contact them to resolve it.

What is the behavior that the rfcs recommend?

This happens quite often with email providers like Microsoft which has its own sender reputation system. (hotmail, live, outlook, custom domains, etc)

Possibly rather this might be the issue. Microsoft and some other tech giants are quite famous for many years for ignoring rfcs if it is for their advantage and do neither care for standards nor for disadvantages others (including their own customers) may have through their behavior.

Are there best practices described how other mail systems or their admins deal with the situation?

PS: My hoster (a small company with a very good reputation since decades) has a warning in his customer portal since early december last year which reads:

Currently there may be delays for eMails sent to hotmail-, live- or Outlook-addresses. Domains that are hosted via M365 are typically not affected. We are in contact with Microsoft about the issue and the process of problem solving has started already.

 

[Alpha1]

What is the behavior that the rfcs recommend?

Thank you for posting to Microsoft Community. We are glad to assist you!

According to your description, when your IP address is temporarily rate limited due to reputation issues (error codes S775 or S843), it's crucial to take immediate action to avoid further complications.

Here are some steps you can follow:

1. Reduce Sending Rate: Continue sending emails but at a significantly lower rate. This helps in gradually improving your IP reputation without overwhelming the server.
2. Avoid Sending Large Volumes: If you continue to send large volumes of emails without addressing the reputation issue, your IP could be permanently blocked.

PS: My hoster (a small company with a very good reputation since decades) has a warning in his customer portal since early december last year which reads:

I would not be surprised if its the same issue. Microsoft is really coming down hard on email senders. For example they pretty much banned reputable email providers like Zoho, because their IP reputation is too low. This can be caused not only by high spam rate, but also by large volumes, not following best practices. Something as simple as sending out email that is not recognizable enough or does not look trustworthy enough, or content is not relevant enough, can cause issues.

 

[smallwheels]

I would not be surprised if its the same issue. Microsoft is really coming down hard on email senders. For example they pretty much banned reputable email providers like Zoho, because their IP reputation is too low. This can be caused not only by high spam rate, but also by large volumes, not following best practices. Something as simple as sending out email that is not recognizable enough or does not look trustworthy enough, or content is not relevant enough, can cause issues.

Microsoft does Microsoft things, as usual. Unfortunately one cannot always avoid to be confronted with their parctices... That's why I asked:

What is the behavior that the rfcs recommend?

Here are some of the situations which often occur:

• IP rate limited. This happens when you send out a lot of email or trip internal email reputation standards.
  554 4.4.7 Message expired: unable to deliver in 840 minutes.<451 4.7.650 The mail server [xxx.xxx.xxx.xxx] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https:\/\/aka.ms\/postmaster (S843) [DS3PEPF000099D7.namprd04.prod.outlook.com
• IP subnet blocked. This is purely coincidental and happens when another email sender that has an IP close to your IP is limited.
  \"bounceType\":\"Transient\",\"bounceSubType\":\"General\",\"bouncedRecipients\":[{\"emailAddress\":\"xxx@hotmail.com\",\"action\":\"failed\",\"status\":\"5.7.1\",\"diagnosticCode\":\"smtp; 550 5.7.1 Unfortunately, messages from [xx.xxx.xx.xxx] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http:\/\/mail.live.com\/mail\/troubleshooting.aspx#errors.

XenForo will keep sending to such addresses until multiple soft bounces will set the user state for these valid addresses to Bounced.

It's been decades since I ran mail servers professionally and a lot has changed since then but the basics are still in the rfc for smtp:

RFC 5321: Simple Mail Transfer Protocol

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary...

datatracker.ietf.org

It says:

4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary, and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and
sender-SMTP agents) must agree on the interpretation. Each reply
in this category might have a different time value, but the SMTP
client SHOULD try again. A rule of thumb to determine whether a
reply fits into the 4yz or the 5yz category (see below) is that
replies are 4yz if they can be successful if repeated without any
change in command form or in properties of the sender or receiver
(that is, the command is repeated identically and the receiver
does not put up a new implementation).

5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client SHOULD NOT repeat the exact request (in
the same sequence). Even some "permanent" error conditions can be
corrected, so the human user may want to direct the SMTP client to
reinitiate the command sequence by direct action at some point in
the future (e.g., after the spelling has been changed, or the user
has altered the account status).

So basically XF is correct in sending again when getting a 4xx ressponse code and stopping when getting a 5xx response code. Regarding 554:

The SMTP protocol allows a server to formally reject a mail session
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see Section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands". Since an attempt to make an SMTP
connection to such a system is probably in error, a server returning
a 554 response on connection opening SHOULD provide enough
information in the reply text to facilitate debugging of the sending
system.

Basically the two error codes mean:

451 Requested action aborted: error in processing

554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")

regarding retries:

The general model for an SMTP client is one or more processes that
periodically attempt to transmit outgoing mail. In a typical system,
the program that composes a message has some method for requesting
immediate attention for a new piece of outgoing mail, while mail that
cannot be transmitted immediately MUST be queued and periodically
retried by the sender. A mail queue entry will include not only the
message itself but also the envelope information

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.

Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. It MAY
be appropriate to set a shorter maximum number of retries for non-
delivery notifications and equivalent error messages than for
standard messages. The parameters to the retry algorithm MUST be
configurable.

A client SHOULD keep a list of hosts it cannot reach and
corresponding connection timeouts, rather than just retrying queued
mail items.

Experience suggests that failures are typically transient (the target
system or its connection has crashed), favoring a policy of two
connection attempts in the first hour the message is in the queue,
and then backing off to one every two or three hours.

The SMTP client can shorten the queuing delay in cooperation with the
SMTP server. For example, if mail is received from a particular
address, it is likely that mail queued for that host can now be sent.

If all this was fulfilled neither sender nor receiver broke standards. However: Things like stretching the time between retries may be implemented or not. Mail has become a nightmare ages ago for both, sender and receiver due to the amount of spam and other unwanted bulk mail and it is not getting better but worse. So if you haven't done yet I'd strongly recommend setting up things like SPF, DKIM, DMARC etc. as a basis - and still you might run into issues. To avoid getting greylisted (as it seems to have happened) I'd on top of the before recommend to constantly clean out your forum's user base from invalid/outdated mail addresses and if you have a lot of users or emails to be sent to go through the pain to run a properly configured dedicated MTA like exim, postfix etc (which is a world of it's own and one can shot oneself in the foot pretty easily and perfectly with it). So in most cases it is more pragmatic to use a dedicated paid service for mails as those guys do that for a living and hopefully know what they are doing.