He doesn't need that much iron for sending. He can do all of that with a regular cheap VPS.
He needs fast drives (SSD) for getting emails out of the queue rather than storage needed for a lot of POP/IMAP mailboxes. He's trying to pitch fast balls, not catch and hold them. Just make sure the the queues use XFS instead of EXT4, and if possible, placed on another controller. Email is more I/O bound than anything else.
iRedMail? NO. NO and NO! If I see another server with that crap installed, I'm going to hurt somebody. Virus scans on every outbound email and people are wondering why sending is slow?
Better to use Postfix's tcp tables and a perl script than iptables to rotate IPs. But, for so small an amount of email sends, he can do it all with one IP.
WARM YOU IP(s) FIRST!!! Don't expect to blast 50k emails on day one. Follow Sendgrid's IP Warmup Schedule (
https://sendgrid.com/docs/API_Reference/Web_API_v3/IP_Management/ip_warmup_schedule.html)
Use custom transports for problem destinations (I'm looking at you AOL & Yahoo). Learn about the following:
- transport_maps
- transport$_destination_concurrency_failed_cohort_limit
- transport$_destination_concurrency_limit
- transport$_destination_concurrency_negative_feedback
- transport$_destination_concurrency_positive_feedback
- transport$_initial_destination_concurrency
- maximal_backoff_time
- minimal_backoff_time
- queue_run_delay
If you can't wait and build your IP reputation and must use a SMTP service (Mandrill, ElasticEmail, etc.), relay your emails through your local mail server to the SMTP service to take advantage of pipelining and multiple connections (check with the provider first to find out the max connection and max recipients per connection limit).
Do not, under any circumstances, use this machine for list hygiene. Pay someone who specializes in it and then import the cleaned list.
Stop using tuning scripts for MySQL/MariaDB. It's bad practice.
We wish even more fervently that people wouldn’t write “tuning scripts” that codify these dangerous practices and teach them to thousands of people. This leads to our second suggestion of what not to do: don’t use tuning scripts! There are several very popular ones that you can find on the Internet. It’s probably best to ignore them.
We also suggest that you avoid the word “tuning,” which we’ve used liberally in the past few paragraphs. We favor “configuration” or “optimization” instead (as long as that’s what you’re actually doing; see Chapter 3). The word “tuning” conjures up images of an undisciplined novice who tweaks the server and sees what happens. We suggested in the previous section that this practice is best left to those who are researching server internals.
“Tuning” your server can be a stunning waste of time.
Join the Postfix Users list or at least search the archives. More often than not, any problem that may arise may already have been solved.