How nack messages are handled is decided by the message broker, in your case RabbitMq. They can either be dropped, sent to a dead letter queue or re-enqueued.
The docs will help you out: https://www.rabbitmq.com/nack.html

In order to use requeuing mechanism you have to use basic.reject or basic.nack in case of bulk. How you set it depends on the client library api you use.

Also refer to: https://www.rabbitmq.com/confirms.html#consumer-nacks-requeue

Sometimes a consumer cannot process a delivery immediately but other instances might be able to. In this case it may be desired to requeue it and let another consumer receive and handle it. basic.reject and basic.nack are two protocol methods that are used for that.

The methods are generally used to negatively acknowledge a delivery. Such deliveries can be discarded by the broker or requeued. This behaviour is controlled by the requeue field. When the field is set to true, the broker will requeue the delivery (or multiple deliveries, as will be explained shortly) with the specified delivery tag.

Well...there's lots to discuss about which configuration to choose when using rabbitmq. I will recommend the following setup (to begin with)

Use fanout model (as described in the docs). This will allow you to:

• Define an exchange (for instance: for all broadcast or public messages)
• Define a queue per service (thus allowing you solution to scale without having a duplication for the same service running simultaneity on several instances)
• Set manual acknowledge (seems more suitable for your use case) or negative acknowledgement (e.g. - when something wrong happen - return message back to broker). This topic is covered here

In short: yes, there is a configuration which suits your needs In depth: you should carefully craft your setup to suit all your needs (including high availability) in order to ensure that your code and deployment will hold as your project progress