Most correct way to do this nowadays is to create an account on the proper mail service which is fully configured to serve example.com. (Of course, this could be your own server, this doesn't matter.) Then, on your null host, you only configure mail server as a smart host, with SASL authentication.
While it is perfectly possible to set up Postfix like this (there are plenty of manuals out there, including Postfix's own), I think Postfix is overkill for such use. Consider using nullmailer, which is suited exactly for systems which don't do anything with mail except originate some system notifications.
If that is not possible, set up DNS like this:
example.com MX record points to its proper mail service. It has nothing to do with subdomains.nullhost.example.com. MX 10 ., i.e. point to nowhere. This is explicit indication that you don't intend to receive any mail for [email protected]. This is not requred if you protect null host's smtpd service from outside connections (firewall tcp/25, listen on localhost:25 only, etc.); however, explicit is always better than implicit.- this null host is going to send mail which sets
example.com as sender domain, so its mail must obey DMARC settings for that domain. Otherwise correctly behaving receivers will drop its mail.
This last point, DMARC, could complicate things considerably. If it is set securely, which means the record looks like _dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; ...", you'll need to set up SPF and DKIM signing on the null host. SPF is easy, just add "a:nullhost.example.com" into SPF TXT record. DKIM is challenging, you'll need to create additional DKIM key pair, choose a selector (nullhost probably will do), install it's public pair into DNS as nullhost._domainkey.example.com. TXT "... key data ...". Then configure singning with corresponding private key directly on the null host (and use the chosen selector), I'd employ opendkim for that. Did I mentioned using smart host is preferred method?
And, your questions.
- You are not the server (you said you this system shouldn't receive any mail). So you don't need any TLS Server certificate. You may set up things using TLS Client certificate, so when you connect to your smart host or to other servers via TLS you'll be able to present it. But why would you want to do that?
- The "apex" record
@ MX, a.k.a. example.com. MX, must be directed to example.com's mail exchanger (the system which receives mail for [email protected]). It has nothing to do with mail for any subdomain. Each subdomain is mail domain on its own.
- How you set up address rewriting is up to you. The only thing outside world sees is the final result. So why bother doing it in two steps?
