I'm aware of modern anti-clickjacking approaches, such as X-Frame-Options header or framekiller scripts. But all these tactics prevent content to be inside iframe. But what if there is a requirement for content to be in iframe, such as Twitter "Follow" button or Facebook "Like" button? How to protect such iframes from clickjacking?
Share buttons will often use an iframe to protect them selves from CSRF. In this context CSRF and ClickJacking have an identical impact which is sometimes called "LikeJacking". You have to choose to be vulnerable to CSRF OR you can use an iframe prevent CSRF but then you expose your self to ClickJacking. It so happens that ClickJacking is the lesser of two evils. FaceBook solves this logic problem with Legal Action. You can make "LikeJacking" and ClickJacking against your against your Terms of Service and sue them like FaceBook.
There maybe a technical solution to this problem. I emailed Google Security on this topic and they said that they where using "Signal Analysis" to determine if behavior was taking place. Which is a pretty gaseous answer to say the least. Being Google they do spider all of the pages that are liked, and they could determine if a clickjacking method, such as an SVG mask was applied to their iframe by the parent page. But this is just speculation.
You might want to check with one of the DNSBLs. Some of them have URLs found in spam email messages. I cant advice which particularly one has the best database, but you can google for online DNSBL check and see the offending websites if they are there. Such check can be done real-time during page execution.
URI DNSBLs A URI DNSBL is a DNSBL that lists the domain names and IP addresses which are found in the "clickable" links contained in the body of spams, but generally not found inside legitimate messages. URI DNSBLs were created when it was determined that much spam made it past spam filters during that short time frame between the first use of a spam-sending IP address and the point where that sending IP address was first listed on major sending-IP-based DNSBLs. In many cases, such elusive spams contain in their links domain names or IP addresses (collectively referred to as a URIs) where that URI was already spotted in previously caught spam and where that URI is not found in non-spam e-mail. Therefore, when a spam filter extracts all URIs from a message and checks them against a URI DNSBL, then the spam can be blocked even if the sending IP for that spam has not yet been listed on any sending IP DNSBL.