Google Postmaster bad IP reputation

There are widespread reports this morning (9/11/17) that Google postmaster tools is showing bad IP reputation for IPs starting on 9/9. This issue is affecting just about everyone. Looking through my client’s postmaster pages, I’m seeing red for IP reputation on every client. Even my clients with generally good reputation are seeing bad reputation since 9/9. 

This looks like a reporting or a display error on the part of Google. Many people who are reporting the bad IP reputation are not seeing any significant change in Gmail deliverability.
Looking through client data it appears that domain reputation reporting stopped on 9/8. I am seeing FBL reports for 9/9 and 9/10, for some but not all clients.
My current read on the situation is that something broke internally with the Gmail postmaster reporting. This does not currently appear to be affecting delivery of mail. (If anyone sees differently, drop me an email or tweet me @wise_laura).
I know folks are making sure Google knows. I know that some Gmail folks were directly notified and another Google person is active on Mailop. And we have confirmation that they are aware and are working on fixing it. I will let you know if I hear of a fix timeline.
EDIT: It’s been fixed. Google even fixed the older data. Same client, screenshot from this morning.

 

Related Posts

Google Postmaster Tools

Earlier this month Google announced a new set of tools for senders at their Postmaster Tools site. To get into the site you need to login to Google, but they also have a handy support page that doesn’t require a login for folks who want to see what the page is about.
We did register, but don’t send enough mail to get any data back from Google. However, the nice folks at SendGrid were kind enough to share their experiences with me and show me what the site looked like with real data, when I spoke at their recent customer meeting.
Who can register?
Anyone can register for Google Postmaster tools. All you need is the domain authenticated by DKIM (the d= value) or by SPF (the Return Path value).
Who can see data?
Google is only sharing data with trusted domains and only if a minimum volume is sent from those domains. They don’t describe what a trusted domain is, but I expect the criteria include a domain with some history (no brand new domains) and a reasonable track record (some or all of the mail is good).
For ESPs who want to monitor all the mail they send, every mail needs to be signed with a common d= domain. Individual customers that want their own d= can do so. These customers can register for their own access to just their mail.
ESPs that want to do this need to sign with the common key first, and then with the customer’s more selective key.
How does it work?
Google collects data from DKIM and/or SPF authenticated mail, aggregates it and presents it to a Google user that has authenticated the domain.
How do I authenticate?

Read More

Gmail filtering in a nutshell

Gmail’s approach to filtering; as described by one of the old timers. This person was dealing with network abuse back when I was still slinging DNA around as my job and just reading headers as a hobby.

Read More

From the archives: Taking Permission

From February 2010, Taking Permission.

Permission is always a hot topic in email marketing. Permission is key! the experts tell us. Get permission to send email! the ISPs tell us.
Marketers have responded by setting up processes to “get” permission from recipients before adding them to mailing lists. They point to their privacy polices and signup forms and say “Look! the recipient gave us permission.”
In many cases, though, the permission isn’t given to the sender, permission is taken from the recipient.
Yes, permission is being TAKEN by the sender. At the point of address collection many senders set the default to be the recipient gets mail. These processes take any notion of giving permission out of the equation. The recipient doesn’t have to give permission, permission is assumed.
This isn’t real permission. No process that requires the user to take action to stop themselves from being opted in is real permission. A default state of yes takes the actual opt-in step away from the recipient.
Permission just isn’t about saying “well, we told the user if they gave us an email address we’d send them mail and they gave us an email address anyway.” Permission is about giving the recipients a choice in what they want to receive. All too often senders take permission from recipients instead of asking for permission to be given.
Since that post was originally written, some things have changed.
CASL has come into effect. CASL prevents marketers from taking permission as egregiously as what prompted this post. Under CASL, pre-checked opt-in boxes do not count as explicit permission. The law does have a category of implicit permission, which consists of an active consumer / vendor relationship. This implicit permission is limited in scope and senders have to stop mailing 2 years after the last activity.
The other change is in Gmail filters. Whatever they’re doing these days seems to really pick out mail that doesn’t have great permission. Business models that would work a few years ago are now struggling to get to the inbox at Gmail. Many of these are non-relationship emails – one off confirmations, tickets, receipts. There isn’t much of a relationship between the sender and the recipient, so the filters are biased against the mail.
Permission is still key, but these days I’m not sure even informed permission is enough.

Read More