Release Communication to Business Users

The Scrum Guide doesn't mention release communication, although it's a common activity for software products to provide some kind of release notes to users and customers.

Without specific information about the organization, I would make two suggestions:

• Creating documentation about a particular release is not a release-time activity. I would consider including necessary revisions to release notes as part of the Definition of Done. I would also consider how you manage any kind of user guides, manuals, or help documentation as well. Even if the team doesn't create or update this kind of documentation directly, ensuring that the information is ready for whoever does is an ongoing activity as increments are created.
• The Product Owner, as the representative of stakeholder needs, is in the best position to ensure that any kind of information provided to stakeholders is consumable by those stakeholders. They may delegate this work to others, but they remain accountable for maximizing value. If release notes help stakeholders better take advantage of delivered value, then it falls into their accountabilities.

Completely agree with @Thomas on this one.  I do not in any way see this as a job that the Scrum Master would do.  It doesn't enable better understanding and use of the Scrum framework so why would a Scrum Master do this?  Unless of course Scrum Master doesn't equate to a Project Manager at your organization.  But according to the Scrum framework, this is better suited for the Product Manager.  

But even outside of the Scrum framework, wouldn't it make more sense for the individual that is responsible for representing the stakeholders to be the one that shares this info?  Then any feedback that is provided would be to that individual instead of someone else.

The Scrum Guide says:

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint."

The empiricism being referred to involves far more than "release communication". So, how effectively are stakeholders involved in reviewing work each Sprint?

It sounds like the common case of mixing the Scrum Master accountabilities with Developers or the Product Owner. 

Scrum doesn't prevent the SM to be also a Developer or Product Owner (or helping the Product Owner). However, the Scrum Master needs to make sure that everyone understands the accountabilities, where are the boundaries, what is the reasoning behind them, and what are the implications of mixing them.

This will help the scrum team to make the right decisions when self-managing and the broader organization to understand the Scrum Team's decisions.