Dead letter queues: patterns for handling failed messages gracefully

Our dead letter queues (DLQs) have become something of an unmanaged graveyard. We have services that send failed messages to DLQs, which is great in theory for preventing message loss. In practice, we often find tens or hundreds of thousands of unprocessed messages accumulating in these DLQs, and nobody actually looks at them until a critical downstream system breaks. It's a disaster waiting to happen. We need a more robust strategy for handling failed messages gracefully. Beyond just having a DLQ, what patterns have you found effective? We're considering implementing exponential backoff with a maximum retry count before a message goes to the DLQ, classifying failures (transient vs. permanent) to inform retry logic, and building dedicated monitoring dashboards for DLQ message counts. Another idea is a 'bulk replay' mechanism for fixed issues. How do you ensure that messages in your DLQ are actually processed, analyzed, and eventually replayed or permanently discarded in a way that provides value rather than just accumulating cruft?