In the event you don't need unicode data in the body, you could convert it to a VARCHAR(MAX) as one thought.
Alternately, if you select the max length of the body and it is 4000 or under, you could change that from NVARCHAR(MAX) to NVARCHAR(4000) (or lower). Won't be future proof that way mind you.
If possible, combining both of those approaches would save you space.
If you don't need all of the emails, you could remove old ones.
You could use your email client (outlook 365 for example has a pretty quick search) to store emails instead of SQL.
If there are any duplicate email bodies, you could pull the bodies out to a separate table and have an int that links the 2 tables (ie basically have a lookup table for the body).
As a random thought, is the index on the body actually being used? I'd check the execution plan to make sure that index is actually being used appropriately. My thoughts here are that if I was searching an email body, it is very unlikely that I remember exactly the text of the email and am actually doing a LIKE '% something %' search on it isn't going to play well with the index. I would be curious if dropping the index on the body resulted in any performance hit on your queries AND if it helped with the space used.