We are using a unique customer identifier as one of the fields in the Feedback-ID header, and that's provided some useful data. What I've noticed with Cloudmark, though, is that sometimes they'll fingerprint a customer based on one of the customer identifiers we put in our headers (X-Inf-App). If I notice in my mail logs that Cloudmark considers all of a customer's mail to be spam, obviously there's a problem worth investigating.
GPT can tell you a similar story with domain reputation, delivery errors and the feedback loop. Their documents indicate that a domain reputation of "Bad" is being rejected at the SMTP layer or filtered to the spam folder almost all of the time. So if every customer has a unique DKIM identifier, then their domain reputation can be tracked separately, so we can make guesses as to inbox placement at Gmail (60% of our average customer's list) at a per-customer level. Similarly, there's a lot more granularity to the delivery error/feedback loop reporting if I do it that way. For example, GPT on our base domain for 2/7 shows a single customer with a spam rate of 0.3%. However, if I drill down into a customer that I set up a separate DKIM subdomain for (not the one reported as having a 0.3% spam rate on the base domain's FBL report), I can see that on 2/7 they had a spam rate of 6.3% when sending to their unengaged recipients on that day. So that's potentially a huge amount of valuable data I gain if I set up every customer individually. Pitfalls would be if I run into a cap on the number of domains I can add (then we'd likely only want to track our highest volume senders), if a certain volume of web scraping gets us into trouble with Google, and any deliverability issues we uncover if we suddenly give Google the ability to track every customer's mailing behavior individually with perfect accuracy. ________________________________ From: Paul Kincaid-Smith <p...@emailgrades.com> Sent: Thursday, February 8, 2018 10:55:28 PM To: David Carriger Cc: mailop@mailop.org Subject: Re: [mailop] Best practices for Google Postmaster Tools? David, the question in my mind is whether it would be worth using a unique DKIM identifier for every single customer of ours to track all of their reputation separately Alternatively, are you using a unique customer identifier as one of the fields of Infusionsoft’s Feedback-ID header? Would that give you the level of visibility you need? Paul Kincaid-Smith EmailGrades On Feb 8, 2018, at 22:13, Paul Kincaid-Smith <p...@emailgrades.com<mailto:p...@emailgrades.com>> wrote: David, I had a conversation with the product manager responsible for Google Postmaster Tools some time ago, and he said that they had deliberately chosen a URL structure for GPT’s UI to make it easier for us to construct a scraper. He encouraged scraping as an alternative to the long-hoped-for API. Good luck with your project. Let us know how it progresses. Paul Kincaid-Smith EmailGrades On Feb 8, 2018, at 21:47, David Carriger <david.carri...@infusionsoft.com<mailto:david.carri...@infusionsoft.com>> wrote: Thanks for the tips. We're currently doing double DKIM right now, the question in my mind is whether it would be worth using a unique DKIM identifier for every single customer of ours to track all of their reputation separately, and I wasn't sure whether GPT scales to thousands of domains in a single account or if they cut you off at some arbitrary number like, say, 500. I will be at M3AAWG this year and was definitely planning on attending the GPT discussions. Just wanted to make sure our GPT account wasn't going to be shutdown if I started scraping the data off of it. ________________________________ From: Benjamin BILLON <bbil...@splio.com<mailto:bbil...@splio.com>> Sent: Thursday, February 8, 2018 9:43:16 PM To: Ryan Harris; mailop@mailop.org<mailto:mailop@mailop.org> Cc: David Carriger Subject: RE: [mailop] Best practices for Google Postmaster Tools? Hey Ryan, I recall that when the errors happened at the end of last year (https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to myself how the heck of a job that would be to clean the mess for people who are scrapping the data. That, and the not-so-huge need of doing it decreased the priority (and increased the innocent hope of the API) on my side. -- Benjamin De : Ryan Harris [mailto:r...@sendgrid.com] Envoyé : vendredi 9 février 2018 12:12 À : Benjamin BILLON <bbil...@splio.com<mailto:bbil...@splio.com>> Cc : David Carriger <david.carri...@infusionsoft.com<mailto:david.carri...@infusionsoft.com>>; mailop@mailop.org<mailto:mailop@mailop.org> Objet : Re: [mailop] Best practices for Google Postmaster Tools? Hello, > 1) Is there an upper limit on how many authenticated domains can be added for > tracking? I have 160+ domains and didn't hit a limit so far Consider also applying dual dkim. It can be helpful to see all of your IPs reputation under a single, or handful of domains. > 2) Does anyone know if an API is planned/in the works for GPT? Yes https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/ https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/ https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/ no ETA, we tried to make some noise to raise priority, and hope to get some news in the coming weeks, but no guarantee Every year it sounds like an API is "just around the quarter." At this point I think it's a story in a backlog that wont see the light of day for a long time. 3) Given the current lack of an API, does Google frown on scraping data from GPT? Some big ESPs do it. They still seem alive today. > We'd like to make more use of it, but the support around it is sparse right > now, and the information I've been able to find on how other ESPs are > implementing the data is also quite limited. You might want to consider joining M3AAWG Scraping is doable and allowed (I assume so long as you don't hammer away at their site), but it's scraping and can be painful at times. How senders are using postmaster.google.com<http://postmaster.google.com> data is a discussion that frequently happens at MAAWG. Ryan _______________________________________________ mailop mailing list mailop@mailop.org<mailto:mailop@mailop.org> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
