That said... it looks like after Block 290042 the received timestamp and block timestamp are all equal (somebody working with the API could do a more thorough check). Here's block 290042 which shows the time stamp difference between received and block that would be more natural:
https://blockchain.info/block/0000000000000000def952fd91504f3c2da9ff129d3a0a004a09100db640fd35
So it's possible that field is entirely ignorable for blockchain.info now, which just reduces things to "the miners set the timestamps" and so a later block having an earlier timestamp is 'normal'.
( Even though miners would do well to properly sync up, and also not set timestamp incorrectly on purpose.. you know who you are )
Thanks for clearing that up for me.. I thought after posting it could have been a db error but wasn't sure.. Appreciate the clarification..