Multiple DoD's based on ticket type

The Definition of Done is a commitment associated with the Increment. There must be a DoD which assures that each will be of usable quality. The Increment, after all, is the thing that's actually going to be put into use. There ought to be a clear Product, the value and quality of which can be assured.

That doesn't mean that a DoD has to be an atomic and monolithic construct which is evaluated at the end of an Increment's development. A DoD can be broken down to different levels, bearing in mind that the best way to inspect and adapt is as closely as possible to the time and place of work being carried out.

In other words there can be multiple levels of Done, each of which allows any issues to be identified and dealt with as quickly as possible. For example, the acceptance criteria of User Stories are often thought of as representing Story Done. Any issues can be resolved prior to their integration, and the DoD for the Increment significantly de-risked.

What then is the Increment in your case? Is there a clear Product, the value of which ought to be maximized Sprint by Sprint and its quality assured?

Thanks Ian for your reply. Yes, we are building a clear Product, the value of which ought to be maximized Sprint by Sprint and its quality assured. Our increment is this product with any functionality, bug fix, etc that we can get done. Wouldn't any Scrum Team answer this way?

I understand then that from your experience, if it makes it easier for the team to have separate DoD's that reflect better the different types of work we encounter, it should be like this. Did you ever face a situation like it? If so, did you have any downside with respect to having a single one?

If you have separate Definitions of Done for various items of work, how would they then be integrated into a Product Increment?

You may reasonably have different levels of Done for an Increment, but ultimately the work being undertaken must be integrated so the commitment to Done for that Increment is assured. Integration and integration testing might thus be included as Definition of Done criteria.

Sorry I realise now that I misunderstood your first comment. You were not talking about separate DoD's, you were talking about different levels of Done. So one DoD, not separate ones.

If you have separate Definitions of Done for various items of work, how would they then be integrated into a Product Increment?

Well, we check the DoD of the type of work we want to close and based on this we would take some actions so that it can be considered done. Some things only apply in some cases, that's why multiple DoD's were created.

Does every item you work on product an Increment as defined by the Scrum Guide? 

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

The Definition of Done applies only to the Increment.  If every item you have does not create an Increment, then you should not be applying a Definition of Done to them.  What I see typically is that each item will have some level of Acceptance Criteria provided that will let people know when they have completed that work.  The Acceptance Criteria is usually unique for each item.  Then a single Definition of Done is applied to all items regardless of "type".  This will help identify if an Increment has been created.

It is not unusual for a Definition of Done to have some conditional criteria.  For example a configuration change will not be the same as a new feature.  I have seen the phrase "when applicable" in many a Definition of Done.