DKIM Helps and Hurts Google, YouTube and SalesForce

Share with your network!
Google has been using DKIM to improve trust in mail it sends from several of its properties for some time now. Mail from Google staffers (google.com and googlers.com), from YouTube (youtube.com), from Google Groups (googlegroups.com) and from Gmail users (gmail.com) is always signed by DKIM using those respective domains as the signer. This means we can be suspicious of mail from those sources that isn't signed by Google. (There's a protocol called ADSP that would let Google make this statement explicitly, but we can also infer it from what we know from our contacts there.) This sort of tactic has worked to filter out some recent fake YouTube spam that claims to be from YouTube but isn't signed. Unfortunately, Google's infrastructure has grown so big and fast that there are a few Google properties that aren't signed by DKIM yet. There are also some Google applications whose email components are outsourced to other companies, like SalesForce, who in turn send mail claiming to come from Google that, of course, isn't signed. And in some cases, mail that goes between two Google services and is then forwarded to other addresses goes out unsigned. This means it's impossible to apply these implicit DKIM rules across the board to keep these scams at bay before they can get started: If we turn them on for everything, some legitimate mail will be bounced, or some mail that deserves preferential treatment won't get it. We know about these limitations of DKIM already. And we know it's a challenge for any large organization to ensure that any new email policy (or any kind of policy, really) is applied across its entire infrastructure when parts of it operate independently. In the end, though, it means the full benefits of DKIM can't be realized when the roll-out is only partial. Google has told us they're aware of these issues and they're working to tighten it all up. This is important to remember for all sites, whether deploying DKIM as a signer or as a verifier. When we wrote the DKIM RFCs, we included a lot of discussion about these topics, and experience since then has shown that this was time well-spent.