Securely Send Database Mail via an Insert Trigger
You are far better off simply inserting into a mail queue table in the trigger and having a separate email process handling the mail - either in SQL Server Agent or an external program.

This gives you the benefit of using the trigger as you desire, relatively low latency as the other job can see the mail once it's committed, scalability of managing the mail load independently etc.

You can wrap the mail queueing into the transaction properly.  Then the queueing app is reliable if the mail server is temporarily unavailable or if you have email address issues.  If mail needs to be resent, it's simply a matter of resetting the sent flag.  You can make expiration on mail, so that mail which couldn't be sent to the SMTP won't be retried after a certain time.  You can quickly route all mail to a test mailbox.  You can do quite interesting things with attachments and other things based on data in the queue without tying up the trigger for extended periods - things like generating reports etc.

So the app offloads the mail responsibility to another component and is free to complete the database transaction and return success to the users, while the mail subsystem gets on with its work ensuring all you want to do with the mail gets done.