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?

  1. Go to postmaster.google.com.
  2. On the bottom-right, click the + button.
  3. In the box that pops up, enter your authentication domain.
  4. Next, prove that you own the domain by adding a DNS TXT or a DNS CNAME record.

We recommend adding a CNAME record, rather than TXT records for the purposes of authentication.
Our authentication looks like this:

$ dig dcnsiyncmude.wordtothewise.com
;; ANSWER SECTION:
dcnsiyncmude.wordtothewise.com. 8639 IN CNAME gv-pre4dkkoexiumf.dv.googlehosted.com.
;; AUTHORITY SECTION:
dv.googlehosted.com. 59 IN SOA ns4.google.com. dns-admin.google.com. 99514096 900 900 1800 60

What data is there?
Google provides a number of different dashboards, which they describe in detail on the FAQ page.

  • Spam Rate
  • Domain & IP Reputation
  • Feedback Loop
  • Authentication
  • Encryption
  • Delivery Errors

For most senders the Spam Rate, and Domain & IP Reputation dashboards are going to be the most useful. Authentication and Encryption will be useful for troubleshooting. Delivery Errors is useful, but duplicates information already in sending log files.
Spam Rate
This lets users see how many of their recipients who received the email in their inbox hit the “this is spam” button. This not only gives you an idea of complaints, it can also tell you how much of your mail is making it to the inbox.
Domain & IP Reputation
This shows the reputation of domains and IPs. Google ranks them as Bad, Low, Medium and High. There is a limit to the number of IPs that will be shared and so ESPs with large numbers of IPs may discover that limit. Google will always provide the full list of Bad and Low IPs, so if an IP is not listed, it has either a Medium or High reputation.
Feedback Loop
This information only shows up for senders who have an active FBL with Google.
Conclusion
Overall, I think the Google Postmaster tools will be extremely useful for senders and ESPs who want to understand what’s happening at Gmail. There are some limitations of the current set. One of the big ones is you’re stuck with Google’s reporting, and there’s no way to download the data through an API. Another issue is that it’s all based on DKIM, and if Provider A uses Provider B as a white label ESP for Customers X, Y and Z, will both Provider A and Provider B have to sign with their shared DKIM keys in order to monitor their customers? Triple DKIM keys aren’t impossible, but there is a processing cost for signing mail.
 
 
 

Related Posts

Gmail having issues

As of 7/22/15, 1:17 PM, Google reports the issue is resolved.
 
Over on the mailop list multiple people are reporting delivery problems to Gmail.
The Google status page confirms this:

Read More

Google Apps – where's my abuse@

Most ISP feedback loops require you to demonstrate that you’re really responsible for your domain before they’ll start forwarding reports to you. The usual way that works is pretty similar to a closed-loop opt-in signup for a mailing list – the ISP sends an email with a link in it to the abuse@ and postmaster@ aliases for your domain, and you need to click the link in one or both of the emails to continue with the feedback loop signup process.
That’s mostly there to protect you, by making sure that someone else can’t get feedback loop messages for your domain. And it’s not too difficult to do, as you should already have an abuse@ and postmaster@ alias set up, and have someone reading the abuse@ alias.
But maybe you’re using Google Apps to host your corporate email, and that’s the domain you need to use for your feedback loops. So you go to create abuse and postmaster users, but it won’t let you – you just get the error Username is reserved for email list only. Uhm, what?
Google want to police use of domains hosted on their service, so they automatically set up abuse and postmaster aliases for your domain, and any mail sent to them is handled by Google support staff. You may well be happy with Google snooping on your abuse role account, but you really need to be able to read the mail sent to it yourself too.
So what to do? Well, the way Google set things up they actually create invisible mailing lists for the two role accounts, and subscribe Google Support to the lists. In older versions of Google Apps you could make those mailing lists visible through the user interface by trying to create a new mailing list with the same name, then simply add yourself to the mailing list and be able to read your abuse@ email.
But Google broke that functionality in the latest version of the Google Apps control panel, when they renamed email lists to “groups”. If you try and create a new group with the email address abuse@ your domain you’ll get the error Email already exists in this domain, and no way to make that list visible.
So, what to do?
Well, there’s a workaround for now. If you go to Domain Settings you can select the “Current Version” of the control panel, rather than the “Next Generation” version. That gives you the old version of the control panel, where all this worked. Then you can go to User Accounts, create a new email list delivering to abuse@ and add one of your users to the mailing list. You can then set the control panel back to “Next Generation” and have access to the mailing lists via Service Settings → Email → Email Addresses.
Hopefully Google will fix this bug, but until they do here’s the step-by-step workaround:

Read More

Gmail shows authentication data to the recipient

Yesterday Gmail rolled out some changes to their interface. One of the changes is that they are now showing end users authentication results in the user screen.
It’s really the next step in email authentication, showing the results to the end user.
So how does Google do this? Google is checking both SPF and DKIM. If mail is authenticated and the authentication matches the from address then they display the email as:
mail from steve to me
If we click on “details” for that message, we find more specific information.
full details of message showing signing domain and spf domainIn this case the mail went through our outgoing mailserver to gmail.
Mailed-by indicates that the message passed SPF and that the IP address is a valid source of mail from wordtothewise.com.
Signed-by shows the domain in the DKIM d=. In this case, we signed with the subdomain dt.wordtothewise.com. That’s what happens when you sign using the domain in the From address (or a subdomain of it).
For a lot of bulk senders, though, their mail is signed using their ESP’s domain instead.  In that case Gmail shows who signed the mail as well as the from address.

And when we click on “details” for that message we see:
3rd party signature detailsThis is an email from a sender using Madmimi as an ESP. Madmimi is handling both the SPF authentication and the DKIM authentication.
As an aside, this particular  sender has a high enough reputation that Gmail is offering me an unsubscribe option in their interface.
Gmail is distinguishing between first party and third party signatures in authentication. If the mail is authenticated, but the authentication appears to be handled by a separate entity, then Gmail is alerting recipients to that fact.
What does this mean for bulk senders?
For senders that are signing with a domain that matches their From: domain, there is no change. Recipients will not see any mention of your ESP in the headers.
However, if you are using an ESP that is signing your mail with a domain they own, then your recipients will see that information displayed in the email interface. If you don’t want this to be displayed by Gmail, then you will need to move to first party signing. Talk to your ESP about this. If they’re unsure of how to manage it, you can point them to DKIM Core for an Email Service Provider.
Gmail blogpost about the changes
Gmail help page about authentication results

Read More