There is nothing inherently problematic about starting new threads when a service is hosted in IIS, but consider this:
How important is it that the email is sent?
When you start a background thread, there is no guarantee that the process doesn't crash before the operation completes. In worst cases, the machine may simply crash due to external reasons (loss of power, Blue Screen of Death, etc.) and there's really nothing you can do to prevent that. In such cases (and perhaps less severe cases as well), the thread may never complete its operation, meaning that the email is never sent.
If you can live with that, sending the email from a new thread is fine.
If, one the other hand, you must guarantee that the email will always be sent, you will need to hand off that operation to a transactional queue of some sort (either MSMQ, a database table or some other transactional mechanism).
In that case, you then need another robust background process (a Windows Service comes to mind) that pulls messages off the queue and sends the emails. This architecture guarantees that the emails will eventually be sent, even if the server suddenly reboots. However, it is a much more complex setup, so I think you should only implement it if the requirements state that emails must be sent.