Some other methods...
1. Using IP routing rulesI think you could do this using 'local networks' without reconfiguring dns or creating any new domains.
* On each SME, use "nslookup -type=mx <the domain hosted on the other sme>" to get the IP address(es) that your SME will be attempting to deliver the mail to
* Use the 'local networks' tab in server-manager to route traffic for the resulting IP (or IPs) to the VPN (or LAN?) IP of the other SME server.
2. Using custom templates for qmail "smtproutes"You can tell qmail to deliver email for each domain to the other server. You'll find (a little) more info in this old forum post:
https://forums.contribs.org/index.php?topic=24643.0"smtproutes" is one of the files that is affected if you create a domain and set "DelegateMailServer" for the domain, but you could create a custom fragment with the routing info you want:
mkdir -p /etc/e-smith/templates-custom/var/qmail/control/smtproutes/
cd /etc/e-smith/templates-custom/var/qmail/control/smtproutes/
echo 'OtherDomain:OtherMailServerVPNIPAddress' >> 30CustomSMTPROUTES
signal-event email-update
(replace "OtherDomain" and "OtherMailServerVPNIPAddress" on each system with the appropriate values for the other system; revert changes by deleting the "30CustomSMTPROUTES" file and re-running signal-event email-update)
3. Using the "smarthost" setting on each systemSet each system to use the *other* system (by VPN or LAN IP) as its email smarthost.
Pro: all traffic between hosts goes over the VPN
Con: all email to outside users goes over the VPN first, then goes "out" to the rest of the ethernet...