How to know which Lambda sent a message to the Dead Letter Queue?

I'm using a SNS Topic as a Dead Letter Queue to handle errors thrown by multiple Lambdas. In the error messages, there are the following attributes :

RequestID,
ErrorCode,
ErrorMessage,

However, I can't easily find which Lambda threw the error, since nothing related to it appear in the message (eg: ARN, function name...)

Although it's possible to look up the request ID on CloudWatch, or to create multiple topics, there should be a much easier way to find which Lambda threw the error. Below is the structure of the received message:

{
    "Records": [
        {
            "EventSource": "aws:sns",
            "EventVersion": "1.0",
            "EventSubscriptionArn": "",
            "Sns": {
                "Type": "Notification",
                "MessageId": "",
                "TopicArn": "",
                "Subject": null,
                "Message": "",
                "Timestamp": "",
                "SignatureVersion": "",
                "Signature": "",
                "SigningCertUrl": "",
                "UnsubscribeUrl": "",
                "MessageAttributes": {
                    "RequestID": {
                        "Type": "String",
                        "Value": ""
                    },
                    "ErrorCode": {
                        "Type": "String",
                        "Value": "200"
                    },
                    "ErrorMessage": {
                        "Type": "String",
                        "Value": "test"
                    }
                }
            }
        }
    ]
}

Is there any way to add information, such as the ARN, on the Lambda which triggered this error message?

Solution

I ended up configuring:

One unique SNS topic for every lambda DLQ.
A lambda listening to the above topic and storing the request ID in S3
A trail on CloudTrail logging every lambda invoke
A lambda matching the failed request ID in S3 and the cloudtrail logs. The latter provide the name of the failed lambda.

This infrastructure might seem a bit complicated but it's working very well. It allows to only add one unique onError: ... line of code in every lambda configuration file.