Large table size, affecting usage
Try rebuilding all indexes on your table to see if you can reclaim free space due to fragmentation.  If you can move to SQL Server 2016 SP1, you could take advantage of compression.
Are you sure the actual query is taking 2 minutes or is it SSMS that is taking 2 minutes to display the results.  The grid in SSMS is notoriously slow.  Before running your query, run SET STATISTICS TIME ON.  Run your query and look in messages for:

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.


That would be the actual amount of execution time for the query.
select convert(datetime,'18/11/2016',103) returns midnight as far as time, so unless those emails were sent at exactly midnight, you won't get a match.  If you want to see emails for that date, use 

SELECT id FROM tblEmailsSent
 WHERE  convert(date,[sent],103) = convert(date,'18/11/2016',103)



Posting the xml for the "actual" execution plan "might" provide us with additional information. I wouldn't think the order desc would be causing any real problem - add SET IO STATISTICS ON before you run the query to see how much logical vs physical I/O you're doing.

One thing to do as an experiment would be to change the select to just retrieve ID only - how long does that run.  Add the next column - how long does that run and so on.  Perhaps your LOB reads are really where the slow down is - if that's the case, I'm not sure what you'd be able to do about that.  Starting with a 'minimum number of columns and adding additional columns on each subsequent run may provide some insight as to what is bogging down your query.

Also, check out this Q &amp; A that has some excellent discussion of LOB data - - LOB_DATA, slow table scans, and some I/O questions