Load testing is typically a traffic consumption problem, i.e. determining how much traffic your server can process. Your brief description seems to describe the opposite problem: determining how much traffic your application can generate.
How you proceed may depend on your goals and your budget. The easiest test would be to measure how long it takes for your application to send 25000 emails to a single address. I assume you asked the question because you already ruled that out.
If your budget is limited, you might break the problem into two parts: (1) measuring how many queued emails Amazon SES can process, and (2) measuring how many email requests you can send to Amazon SES.
Amazon probably makes claims about how quickly they can send emails. You can trust their claims, or you can measure that for yourself. Either way, your testing approach should reflect that you do not need to test Amazon SES's performance every time you change your application.
Depending on how you structure your application, you might choose to decompose the part (2) further. For example, the process that decides that an email needs to be sent might write that information to a queue, and a separate process might read the queue and send the request to Amazon SES. You might benefit by measuring the performance of those processes separately. Moreover, if it is possible that the queue-reading process is non-linear (e.g. because it sorts the queue entries first), or has problems scaling (e.g. because it reads the entire queue into memory), you might also want to measure how quickly the queue-reading process can compose an email, and then separately measure how quickly the queue-reading process can send emails. The latter measurement might lead to decisions about whether to use an API that can queue multiple emails to Amazon SES simultaneously.