I'm often involved in deployments with large-scale mail out requirements. You're right - email does indeed slow down the app considerably, which is why we never send an email directly from the application itself.
We also rarely use multi-threading in large-scale apps - there just aren't enough threads to go round.
We always opt for one of two options, both scale well:
Message Queue, such as MSMQ. Write out the email to a message queue and then have one or more 'servers' pick up the outbound mail. Can add servers infinitely. Enterprise-scalability.
Database. Write your email out to a database and then move on. Write a separate app or service which picks up the email and processes. Again, can scale really well but usually not quite as well as a message queue.
Both approaches also have one very useful benefit: Transactions. You can wrap both options in a TransactionScope meaning that, should anything else go wrong in the process, you can rollback before the email actually gets sent.
Only 100% committed transactions end up getting translated in to outbound email.
There's nothing worse that sending a customer an email along the lines "Thanks, your order has been dispatched" and then finding out later in the processing pipeline that infact you're out of stock!
Hope this helps.