Incorrect. A bounce is a delivery status notification generated by a mailer after it has already accepted a message for delivery. A 5xx permanent error is a refusal to accept the message in the first place.
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.
That's fair with regards to your statement, but "doubled112" assigned the agency to Microsoft, saying that "Microsoft bounces" their traffic, which is demonstrably not what is happening.
It is what's happening, as I've described. A 5xx is a bounce.
You don't agree with my terminology, but we're not disagreeing on what's happening. In this case, as per my dictionary, 'rejected' and 'bounced' are synonyms. If this was me, and my MTA hitting this Microsoft server, my MTA/server would see the bounce(5xx), then my MTA/server would generate a bounce message(email) which I'd receive in my inbox.
The bounce message is a result of the bounce. The action/cause is the bounce/reject 5xx.
How can you have a bounce message, without a bounce happening?
Again, you don't agree with this terminology, and that's fine. But I'm not pulling this out of a random hat, it's 30+ year old terminology that I've used with endless people locally and online. That doesn't mean your view is wrong, we may just be running into local variances in lingo.
There are all sorts of edge cases in our compute discourse. I ran into a company where they didn't use initialisms to discuss daemons/protocols, but treated them as acronyms. Of course, they didn't really discuss such things often. So when discussing smtp, they'd pronounce it 'sim-tee'. Of course, sntpd, smtpd, snmpd, and others are all pronunced 'sim-tee', which makes for a fun meeting. Think of it as 'I am groot' taken too far. For prudence, I kept enforcing initialisms, which of course resolved this.
Anyhow! Point is, well.. not really sure except info.
Wait, that is probably from the local mailer, and otherwise the sender may never know about the rejected messages.