Simple answer - you don't.
Outgoing queues are dynamically created by the MSMQ queue manager when your application is sending messages. This is MSMQ's built-in store-and-forward mechanism in operation. The messages are stored in the local outgoing queue and then forwarded to the destination queue when the remote MSMQ machine is available. You won't see an outgoing queue when sending to a queue on the same machine - MSMQ just cheats and writes the message straight to the destination.
Normally outgoing queues don't hang around for long - once the message has been delivered and processed at the destination then it has served its purpose. As the cost of creating a network connection is high (in computing terms), MSMQ keeps the queue alive (even if it is empty) for a few minutes just in case you are going to send another message. This saves the queue manager the effort of making the network connection again. This cleanup delay is controlled by the CleanupInterval registry value - 5 minutes for clients and 2 minutes for servers.
You may see outgoing queues remain for a lot longer if you are using transactional messages. This is because a copy of the message is hidden in the queue waiting for the transaction to commit or abort. During this time, the copy can be resent as part of the retry mechanism. Should the transaction abort then the message will be moved to the transactional dead letter queue.
Looking at the underlying mechanism:
Here is Computer Management during step 6:
The outgoing queue above contains no visible messages but the columns below show 10 messages unprocessed:
Additionally, performance monitor shows 10 real messages still taking up space:
Here is the outgoing queue on the destination sending acknowledgements back to the original machine:
Note - all this only happens when you send messages with dead lettering (or negative source journaling) enabled. If you don't request this then MSMQ won't bother to keep copies of the messages after delivery - there would be no point as they would never be moved to the transactional dead letter queue.
The use of negative source journaling is a best practice - properly implemented, it takes away some of the mystery when things go wrong and messages seem to get lost.