jeffbee isn't offering any explanation, maybe because it's obvious to them they don't think they need to, or something like that... so I'll volunteer one.

If you send an email, your client would talk to your local MTA (i.e. the SMTP server you own or are authorised to relay mail through, e.g. ISP). The local MTA usally just accepts the email to insert it into a queue for attempting delivery. When your MTA processes the queue, and talks to another and gets 5xx or 4xx response, your MTA will generate a "bounce" (non-delivery report) email that lands in your inbox with the details of the response it received.

So jeffbee is correct that when the local MTA gets a 5xx or 4xx response code in the SMTP session with target MTA, that /the response code is not a bounce/. Microsoft responding with 5xx or 4xx in the SMTP session, they are not bouncing the email. They are refusing to accept delivery.

For Microsoft to "bounce every email" from the original parent commenter, it would have accept each email first, and then use the return path address of each email accepted to send a bounce email asynchronously, i.e. the bounce is not part of the original session.

If a MTA talks to another MTA who accepts a message for delivery, they can then bounce the email at any later point via the address specified in the return path header. Why? Maybe incoming email is queued and scanned, because it would take too long to determine if it passes secondary rules when it's initially being accepted.

Given how this works, you could take an email inbox you received a year ago, or five... and send an email with whatever content to the return path address, and you have "bounced" the original email.