I don't have a specific reference for the text location in RFC5321, or any of its referred documents, but I would concur that it's most likely not in RFC5321 proper. However, it's been a generally accepted practice of SMTP for eons now that the PTR record may be expected to match the identity that the inbound SMTP server is providing. If not, the receiving SMTP Server may opt to refuse the receipt of the message under the premise that the inbound connection is coming from a rogue server.
Spam filtering services are not relevant to the conversation because this is not about email coming into your domain, but rather about your mail servers trying to send email to other domains. No doubt, one of the things that AppRiver does is validate the PTR address of all inbound email server connections. What they do with that information regarding flagging the message as possible spam, is something you'd have to inquire about with AppRiver. As regards the forwarding of the message to your server, presumably you have some sort of methodology in place to ensure that only inbound connections from AppRiver are accepted by your mail server. That methodology may be significantly more secure than a DNS PTR record, in which case, you don't care about the DNS PTR record for the mail server(s) relaying mail to you from AppRiver.
The message from DNSStuff.com does not take into account the myriad of third-party service providers that may or may not exist in the email traffic pattern of your domain, it's doing a simple two-party query based on the domain name you provided. It queries DNS for MX records based on the domain name you provided. It does an 'A' record lookup on those MX records to get the IP Address(es) of the SMTP servers identified, and then it does a Reverse DNS lookup on those IP Addresses. In a conventional two-party SMTP connection, it is expected that the MX, A, and PTR records for a given SMTP server are consistent. If you don't have a standard two-party SMTP environment, you'll need to adjust your interpretations accordingly (read: The message does not apply to your third-party environment, so your best reponse is to ignore the message.)