let's say I want to send an encrypted email thus I sign it with the receiver's public key
Huh? With the standard definition of sign, you sign with a private key; it doesn't make sense to sign with a public key, in part because anyone with access to that public key can do it.
I think you mean 'I encrypt it with the receiver's public key'
If someone tampers with the message in between a. what kind of tempering can be performed
One of the things they can do is pick a message, and encrypt it with the receiver's public key (which, presumably, they have - it's public), and then replace your ciphertext with theirs. Then, when the receiver gets it, it looks just fine, without the message being malformed (because the message was encrypted properly).
Does asymmetric encryption like RSA ensure message integrity without hashing the message with an HMAC?
Any form of public key encryption, in and of itself, cannot provide any guarantee of message integrity; if you need such a guarantee, you need to provide something in addition.
For example at initiation time of the TLS handshake when the client encrypts with the server's public key the symmetric key that's going to be used for the rest of the transaction, does it also uses hashing?
Actually, it doesn't (TLS does do hashing as a part of the KDF, but that's not what you're asking about).
Assuming that TLS doesn't do client authentication (which is optional), the server doesn't get any sort of integrity check; when client Alice selects a premaster secret, encrypts it and sends it to server Bob, Mallet could indeed replace the encrypted premaster secret with his own, and Bob won't know (or case); as far as Bob is concerned, he just set up a secure connection with Mallet. However, Alice won't establish a secure connection with anyone (Bob never heard her encrypted premaster secret, and Mallet can't decrypt it), and so as far as Alice is concerned, the TLS connection failed (which is the secure option in this case).