The enforcement of the Definition of Done (DoD) is the Product Owner's primary mechanism for ensuring product quality. The DoD defines quality for the project. Ensuring that work that falls short of the DoD is returned to the Product Backlog is the project control for preventing known defects from escaping the Sprint.
NB: Because the team's capacity is finite, the Product Owner controls quality by trading off capacity for explicit backlog items and implicit tasks associated with the DoD.
Manage Quality with "Definition of Done"
In agile frameworks, the way you manage quality is through the "Definition of Done." This is a formal definition of all the quality gates that a potentially-shippable increment must pass through to be considered done at the end of a Sprint. Because Scrum requires that the product always be in a potentially-releasable state at the end of every Sprint, the DoD also includes acceptance tests, regression tests, and other quality criteria to validate that the product itself (and not just the current work increment) meets the defined quality criteria.
Because work is either done or not-done at the end of each Sprint, work that doesn't meet the DoD is considered "not done" and must be returned to the Product Backlog for reprioritization and replanning. Partially-complete Product Backlog Items are never considered done, and are never automatically carried forward. This is a key control for the Scrum framework.
Because Scrum is an iterative framework, the DoD may evolve over time. The Product Owner can fine-tune the quality of the product by working with the rest of the Scrum Team to determine the extent and granularity of the DoD based on lessons learned and information gleaned from the Sprint Retrospectives.
Trade-Offs in Quality
A team with a very complex or time-consuming DoD will need to reduce its capacity forecasts accordingly, as more team capacity is directed to getting work increments to "done." On the other hand, increasing feature development at the expense of an adequate DoD may result in tech debt or an increased defect rate, which can also reduce the velocity of feature development.
NB: Velocity of work is not reduced, as defect management is also work.
In short, the Product Owner and Scrum Team need to find a DoD that is sufficient but not excessive. Too much process overhead, and feature development suffers. Too little, and quality suffers. It's a balancing act, which is why there's no such thing as a universal standard for the Definition of Done.