If you have enabled bounces on any of your transports, you need to choose a "bounce" transport in order for bounces to be delivered correctly. In many cases a "MX lookup" transport will be the correct option for them to be delivered correctly, however there might be some circumstances where you need to use another transport.
For all of your inbound mails that are to be delivered to a backend mail server should have a transport with lookup-mx set as bounce transport in order for Halon to use the correct MX/A record for the sender's domain.
If you receive a message from email@example.com to firstname.lastname@example.org which should be delivered on your inbound transport (eg. to 10.0.0.3), if that fails you need send a bounce back gmail.com, this cannot be done using the same transport (since it points to your local mail server) so you need to choose a default bounce transport which can send mail to external domains, preferable a lookup-mx or smart host transport.
If you only have one local mail server that sends out mail via a outbound transport you can choose to set its transport as bounce transport and then they will be delivered directly to the mail server instead of going through the inbound listener via lookup-mx.
In a reverse example as above, if you fail to deliver messages outbound you need to be able to send messages back to your local users. Hence the bounce transport should point to a transport being able to send messages to email@example.com (in some cases a lookup-mx transport may also work).
Scripted DSN handling
You can use the “dsn” option for Bounce() and Queue() in the pre and post-delivery scripts to modify the DSN settings. You can use these functions to eg. change properties of the DSN and also DKIM sign bounces.