There is no afaik defaut behaviour for your case. You could create a plugin or you could rely on client logic which are the purpose of my answer.
It is important to know that RabbitMQ queue declare/bind is an idempotent operation
Declare queue, create if needed.This method creates or checks a queue.
When creating a new queue the client can specify various properties
that control the durability of the queue and its contents, and the
level of sharing for the queue.
hypothesis 1 : queues cannot be deleted or queues can be deleted but clients will know it, the queue set can fit in memory
Each client maintains a set of queues. Before sending a message, the client checks if the set contains the queue. If not it declares and binds the queue and put the queue into the set.
At bootstrap, the queues set can be initialized with the existing queues using for example the HTTP API (eg. a java client)
How to do it depends on your RabbitMQ client. For example using spring-amqp, you can extend and override RabbitTemplate#doSend
hypothesis 2: queues can be deleted and clients will not know
As suggested by GeekChick you can register a ReturnListener
. All message must be send with the mandatory flag
hypothesis 3: I don't mind the cost of declare/bind queue*
You always, prior of sending a message, declare and bind the queue. AFAIK the cost, once created, should be more or less equals to the network footprint + map lookup.