It isn't; an attacker can encrypt any message. You have to add message integrity and authenticity to the plaintext or ciphertext. For this the sender needs to be able to authenticate the messages send. This obviously isn't possible using just the publicly available encryption key.
When we're talking about separate messages (e.g. document protection) then this is usually performed using sign-then-encrypt. Here the sender signs the messages before they are encrypted using their own private key. The receiver then verifies the messages after decryption using the public key of the sender. This public key of the sender of course needs to be trusted for this scheme to work.
As public key encryption isn't very efficient for larger messages, and because the signature (and meta information) generally expands the messages, it is generally required to use hybrid encryption for sign-then-encrypt to work. In that case the encryption scheme could also use a Key Encapsulation Method such as RSA-KEM or (EC)IES.
In principle it is also possible to use a MAC (message authentication code), but that would require a pre-shared secret key, which would destroy the advantages of using public key encryption in the first place.
In transport mode security (e.g. TLS, SSH) the public key cryptography is generally used to establish a secret between the parties before messages are send through the transport channel. In that case the messages are encrypted by a session key and protected using an authentication tag. This tag can be calculated using a MAC (e.g. HMAC) or by using an authenticated mode of encryption (e.g. ChaCha20/Poly1305).
For this to work both sides need to be authenticated as well, otherwise the sender doesn't know who is receiving the data, and the receiver doesn't know who is sending it. So although the messages themselves are protected differently, the key management is similar to protecting separate messages.
