I assume that the validation logic is the same when the user signs up and if the user wants to change email at a later time. If that is the case you don't want to duplicate the validation logic because it will be prone to drift in different directions. That speaks for separating the validation logic into a separate class to allow reuse.

Since the repository is used both to fetch the confirmation and saving the status I would probably put the validation logic into the repository.

It will have the effect that it can't be bypassed or forgotten when changing an email.

Depending on the complexity of the validation you could put the code directly in the repository or inject a validation class. I would probably go with injecting a class because the validation is a bit complex.

You could look into validation and aggregate roots in the DDD methodology there are some great insights on how to structure validation. There are several approaches.

A link to get you started: https://lostechies.com/jimmybogard/2009/02/15/validation-in-a-ddd-world/

I assume that the validation logic is the same when the user signs up and if the user wants to change email at a later time. If that is the case you don't want to duplicate the validation logic because it will be prone to drift in different directions. That speaks for separating the validation logic into a separate class to allow reuse.

Since the repository is used both to fetch the confirmation and saving the status, I would probably put the validation logic into the repository.

It will have the effect that it can't be bypassed or forgotten when changing an email.

Depending on the complexity of the validation you could put the code directly in the repository or inject a validation class. I would probably go with injecting a class because the validation is a bit complex.

You could look into validation and aggregate roots in the DDD methodology there are some great insights on how to structure validation. There are several approaches.

A link to get you started