Simply, your backlog and especially your sprint backlog should only include items that can be completed by your development team. That's development team in the Scrum sense: i.e., anyone and everyone who is part of the Scrum team. That could be actual developers, QA, infrastructure admins, DBAs, etc. The point is that it's these folks who will actually be doing the work and, more importantly, it's these folks who are doing the sprint planning and dailies.
Additionally, your Definition of Done should only include items that the development team is capable of providing. A PBI is done when your development team has completed all the work on it and met the agreed upon Definition of Done. Since the development team alone is responsible for driving the sprint and getting all the PBIs to "Done", there cannot be any external influence in the Definition of Done.
Given those two things, stakeholder testing and approval should not be part of your Definition of Done or part of your sprint. Rather, it would be part of your release planning. One of the most brilliant aspects of Scrum that people seem to just totally miss is that sprints don't have to be followed by releases. The team delivers an increment of done, working software that is potentially releasable, but there is no condition on when or even if it has to be actually released. Where people started messing up in Scrum generally comes in here. They start trying to add all sorts of conditions on whether something is "done" or not for the purposes of the sprint, based on arbitrary conditions on releasing the software.
When there's external forces involved in deciding if a PBI is done or not, you're going to end up missing your sprint targets every single time.
Simply, you don't control stakeholders, and it's impossible to assure that they will review the increment before your sprint is over. As a result, you'll end up with all your PBIs sitting in the "in progress" column when the sprint ends.