Whatever can decrypt can get hold of the plaintext. For encrypted email that includes "the server" or not, depending on the setup, which is not clear in the question.
With what we can imagine of the setup, for sure the plaintext is available not only to the user, but also on the screen, and in the computer connected to that. The plaintext is thus vulnerable to whoever can see the screen, tap its cable, penetrate the user's computer, or decide the programs it runs in the first place. That minimal chain of trust needs not extend to "the server" (as in say an IMAP server on which the emails are stored at rest), but it can extend to that, and sometime does. The question does not allow to tell, in particular because it does not specify what "the frontend of the email service" is.
The conceptually simplest and (thus) safest way to practice email decryption is that it is carried on the recipient's own trusted computer, which is the only machine using the user's private key. In this case "the server" can not see the decrypted email. In the basic form of that, encrypted email really is a an attachment, extracted and deciphered by a local program (e.g. GnuPG), and displayed. That can be integrated in the email client program (e.g. Thunderbird, or Outlook-the-user-side-program), perhaps thru a plugin. And that can be integrated in the email syntax so that the encrypted email does not appear as an attachment. Each step away from simplicity comes with potentially decreased security; that's one of the lessons of efail (archive; main site is currently down, because security is hard to conciliate with functionality).
Setups in which the server can intercept the decrypted email include anything where the user interface is a standard web browser. Adding a plugin handling the decryption locally with a local private key, perhaps a Smart Card or Trusted Platform Module can be a step in the right direction; but that might also be mere security theater if the software orchestrating the flow of information comes from the server: the server can still send a modified software that will give access to the email. In practice, whatever can decide how decryption is performed can get hold of the plaintext (with few exceptions not found in common practice: like there is a data diode in place to prevent the decrypted plaintext to flow back to the server).
When the user is using a web browser or a dedicated program of unknown origin and closed design or/and source, it is in practice next to impossible to tell if "the server" can get the decrypted email, thus the rational action is to consider that possible.