I agree with @FrankHileman's comment on terminology of messages as having state as being confusing and a rather non-standard usage of the concept of messages.
Messages, almost by definition, are immutable and pass between two or more of some kind of (mutable) entity, such as actors.
It would be the actors that follow state machines, given messages, in order to determine what to do next. Each actor might have their own (different) state machine. The number of actors has to do with your domain.
While sometimes we might be able to model all the states of all of the actors in one model there is no requirement to do so, and it would likely be simpler to have independent state machines associated with different actors.
I would recommend associating with each actor only the states and state machine that each in turn needs, rather than having a global StateMachine object.
Generally speaking it is better to distribute responsibilities among the responsible parties (i.e. the actors) rather than collect one aspect or cross cutting concern of all responsibilities (e.g. the states/state machine) into one global place/entity. This tends to reduce coupling by way of supporting Single Responsibility Principle (SRP); we want domain entities to have one domain responsibility.
Whereas centralization tends to increase coupling, making it harder to make independent modifications, independence being key goal in support of long-term maintenance.
That's not to say that centralization of cross cutting concerns doesn't have some advantages, but it comes at cost of maintenance and sometimes also increases other complexities by introducing an additional implementation-oriented, rather than domain-oriented, entity.
Introducing a separate entity having centralized responsibility for a functional concern that cross cuts several actors supports SRP in some very indirect sense; however, we would be speaking of SRP regarding a lower-level responsibility, an internal implementation responsibility, rather than a domain-level responsibility. I would consider that weaker design with stronger coupling.