How can you test a backup / secondary MX server?

Question

I'm wanting to set up a secondary MX server using Postfix but I am wondering what is the best way to test this prior to putting into production (by adding its MX entry)?

One possible way is to test it with an entirely different domain name, ie buy a domain like "fake-test-domain.com" and set it up its DNS zone with ONLY this backup MX server.

Any easier way I can just force a mail server to send a message to this server before it's listed in DNS?

I don't think I can use the hosts file on the sending system because that wouldn't emulate an MX record, right?

Solution 1

Just use a telnet session to test email delivery. As an example,

# telnet host.domain 25
Trying host.domain...
Connected to host.domain.
Escape character is '^]'.
220  ESMTP
HELO example.com
250
MAIL FROM:<[email protected]>
250 ok
RCPT TO:<[email protected]>
250 ok
DATA

To: [email protected]
From: [email protected]
Subject: a test message

Test message body.
.
250 ok

Solution 2

When telnet is not enough, or too tedious, I use SWAKS

eg:

 cat email-content.txt | 
 swaks --body - --helo localhost.localhomain --server mail.example.com:25 \
  --auth-user fred --auth-password flintst1 -tls \
  --h-Subject Pebbles  --to [email protected]
  --from '[email protected]'

Comments

[Halfgaar]

You can just enable the secondary MX. As long as it has a lower prio in the MX records, no delivery will be done to it, and you can test as @EEAA mentioned. BTW: beware that fallback mailservers are spam traps. And if you don't set up recipient verification, you get a lot of bounce messages to whatever from-address spammers use. You may want to set up a manual or automatic system that control iptables rules for access to port 25. Most sending servers have three days deferral time, so it's easy to manually open the fallback MX port 25 only when it is necessary.

[thomasrutter]

@Halfgaar if the secondary MX server is misconfigured it could lead to loss of mail in the unlikely event that a sender is unable to connect to the primary MX server for any reason (including a connectivity problem at their end). At least if it hasn't been added to the DNS yet then a transient issue with the primary won't cause loss of mail - a sender will just queue the mail and try again later.

[thomasrutter]

@joeqwerty I'm actually thinking of migrating a mail server to another machine which will involve setting up the old server to relay to the new server during the DNS propagation (even with low TTL values, some resolvers will cache for 30 minutes or more). Since I'll need to put in the effort to get this relaying working correctly anyway, I thought I may as well create a backup MX server configuration. And it'll be a learning experience. This was just to give a bit of background about why.

[Spence]

+1 - Anybody who administers an SMTP server but can't run the protocol "by hand" in TELNET has no business administering an SMTP server.

[thomasrutter]

@EvanAnderson This is a good general principle until it comes to testing STARTTLS or any AUTH other than PLAIN. But yes in this case you're absolutely right.

[MadHatter]

@thomasrutter I routinely test STARTTLS by hand, using openssl s_client -starttls smtp -connect .... But I agree about non-PLAIN authentication methods being problematic.