Two teams say a feature is done and mean different things. One means the code is written. The other means it is written, reviewed, tested, documented, merged, deployed to production and monitored for a day. The gap between those is a great deal of work, and when it is invisible the project is late by exactly that gap, discovered at the end. The definition of done makes the gap explicit: a single list, agreed by the team and applied to every item, of what must be true for work to count. It is the artefact that turns done from an adjective into a checklist, and it is the reason a team's velocity means anything at all.
What a real definition contains
Code reviewed by someone who did not write it. Automated tests written and passing. Integrated with the main line, not sitting on a branch. Documentation updated where a user or an operator would need it. Security and accessibility checks passed. Deployed to the environment closest to production that the team controls, and ideally to production itself. Each line is a step that would otherwise happen later, unplanned, and each line the team cannot yet include is a named gap in its ability to release.
The definition applies to everything and is different from acceptance criteria, which apply to one item and say whether that item does what was asked. A story can meet its criteria perfectly and fail the definition, because the tests were not written or the documentation was not updated, and it is then not done, whatever the review showed. The Scrum guide makes the definition a formal commitment attached to the increment, requires that undone items return to the backlog rather than being presented as finished, and lets the organisation set a minimum that teams may strengthen and may not weaken. The professional assessments test that distinction closely, because it is where teams most often deceive themselves.