The timestamps on blocks are set by the miners - as long as they stay within a 2 hour threshold (I think it was 2 hours), the network doesn't worry about it. The received time depends on when the node (in this case, one of blockchain's nodes) gets it. However, if blockchain.info has apparently bad data on that timestamp, it will default to the timestamp in the block (you'll notice they're equal for both blocks you linked to).
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/0000000000000000def952fd91504f3c2da9ff129d3a0a004a09100db640fd35So 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
)
