In your code, right after the point where e-mails are sent, do a 302 redirect to a confirmation page:
protected void btnSend_Click(object sender, EventArgs e)
{
SendManyEmails();
Response.Redirect("confirmation.aspx");
}
With this kind of code, the POST to the original page will not end up in the browser history.
This common pattern is known as the Post/Redirect/Get pattern.
Bonus info about keeping state when doing Post/Redirect/Get
The main drawback of this pattern is that all state from the handling of the POST request is lost when redirecting the user - thus, commencing a new request context. In ASP.NET this includes members within the Page and all Control objects, as well as everything stored in the ViewState.
If you generate some kind of "status object" - maybe a log of sent mail messages - while handling the POST request, you will need some way to save this object for the following GET request. Some web frameworks has functionality specifically for this: RoR has flash, ASP.NET MVC has TempData. ASP.NET forms has no such concept built in, so you will have to figure something out yourself.
Saving the object to the Session on the POST, reading and deleting it on the following GET would be one way to solve this. You can build an abstraction around this if you use it in several places, or you could search the web for existing implementations of flash/TempData for ASP.NET forms.
