Quoting Trent W. Buck (trentbuck@gmail.com):
This *may* be beyond Rohan's current skill level.
To be sure. It was beyond mine when I did it, too. (I was not an IT guy at the time.) Fortunately, nobody told me I lacked the necessary skills, so I just worked through configuration (on a real static IP), and it worked.
* what do you mean I should have a second, offsite, MX?
I very much do not agree, FWIW. Additional MXes are now an actively bad idea, because of collateral damage from the spam problem. Back in the early 2000s, I noticed that spammers preferentially delivered mail to high-numbered MXes even when the low-numbered ones are fully reachable. This isn't ineptitude but rather strategy. It's very common for backup MXes to have looser antispam regimes, so from the spammer's tactical perspective the initial delivery is more likely to be successful. Then, when follows of course is your backup MX attempting to redeliver to your primary MX, and your primary MX either refusing delivery or punishing the delivering MTA, e.g., with teergrubing and similar. So, the spammer has conjured up a scenario where your MXes are DoSing each other over spam redelivery. The best-case (or, I would say, least-bad-case) version of that scenario is where you apply identical antispam policies to both backup and primary MX (i.e., you abandon the old model where friends do backup MX for each other and run both hosts): In that case, your backup MX is still going to be accepting a certain amount of spam, and facing the no-win dilemma about what to do with it: Try to redeliver to the primary MX (aka your MTAs DoSing each other), issue a failure Delivery Status Notification (aka generating backscatter spam), or discarding/spamboxing it. IMO, it's smarter to dispense with the idea of backup MXes and just know that you have about four days to SMTP restore service somewhere in the world before failure DSNs start. (Fortunately, that's not really difficult).