From the view of database architect, sending emails is a business functionality and need to be hosted in a separate server as separate application! The application needs to read sqlserver!
This seems like an interesting idea to me. If things get worse or if the performance-impact of sending newsletters (Steve said there is a little bit of slowdown at the beginning of the sending-process) is not accepted you can set up a replication of the newsletter-data to another server with SSDs. This one does not have to be clustered or as secure as any other server because it will only be there for the data-gathering so it will be easier to get the budget for it. So you would get the workload away from the productive system, disk as well as bandwidth. The response to these emails like bounce code and so on could be written directly back into the live system so it is not necessary to take too much care if this server runs all the time as long as it is up for the newsletters (a little bit before to synchronize the subscription) and the subscription does not time out.
If the application runs on a standalone-server without any other applications you may even set up an SQL Server there as a subscriber to reduce the high bandwidth-usage if this seems to get worse and may have a big impact on the site in the future.
Maybe this would be a relatively cheap solution to possible problems without too much reengineering of the applications and only with a short downtime if any at all (Locks while creating the snapshot for the replication if you start with a snapshot).
Another benefit could be that if the bottleneck is the SQL Server and not network or mailserver that with this architecture the sending could be splittet up more than one server. But maybe you don't want to put that much workload on the mailserver as well as the network.