Gmail says your unsubscribe "Needs work"

Google postmaster tools dashboard with a “Needs work” message for Honour unsubscribe

Needs work?

We’ve written about RFC 8058 “one-click” unsubscribe and how it’s part of the requirements for bulk senders wanting to deliver mail to the major consumer mailbox providers.

So you’ve deployed it, you’ve tested it, everything looks fine but Google postmaster tools gives you a scary red error and says “Needs work” for the “Honour unsubscribe” section.

What does that mean? How concerned should you be? How can you get a happy green checkmark and the word “Compliant”?

Let’s look at exactly what the message says:

Needs work - Remove users from mailing lists within 48 hours of receiving unsubscribe requests

That seems a reasonable requirement. And we can see on the dashboard that Google is describing our “One-click unsubscribe” as “Compliant”, so the problem must be with how we’re handling those recipients who unsubscribe rather than anything technical.

And then it says:

Recipients will mark your email as spam or block you permanently if you don’t honour their unsubscribe requests.

Which … yes, they probably will. But it doesn’t sound like Google are seeing behaviour they consider “Bad” which will impact our reputation or deliverabilty at Gmail immediately. It’s more a warning about following good unsubscription practices lest we suffer the consequences.

What does it mean mechanically?

This is Google’s way of saying “We have users who unsubscribed from your email, yet are still receiving email from you.”

Google only have very limited insight in to the subscription relationship between you and the user you’re sending email to. They can see when the user receives mail from you, they can see when the user unsubscribes via RFC 8058 using their in-app unsubscribe functionality. And that’s about it. They can’t see whether a user unsubscribed via your subscription centre, they can’t see when a user subscribed and they can’t see if a user resubscribed after unsubscribing.

That means that they can’t really tell the difference between you ignoring a users unsubscription request and you honouring that request and the user later resubscribing. At least, they can’t tell that immediately or for each individual case. They can recognise the Bad case of you not honoring unsubscribes eventually by looking at your statistics, most directly by seeing that users mark your mail as spam or block you as a sender.

They also may not be able to recognise that a user only unsubscribed from some of your email, while still happy to receive the rest of it.

So this is a warning from Google that they are seeing behaviour from you that might be fine, or might be a sign that you’re doing something wrong that will lead to reputation problems in the future. They don’t know which, so this is a heads-up to you to look at it.

What do I do?

Check that your one-click unsubscription is actually working. Sign up then unsubscribe through the Gmail interface and see that the mail stops. Or use aboutmy.email to check that your one-click headers and infrastructure all work.

Consider whether you’re sending multiple mail streams to a user, where an unsubscription request for one stream won’t suppress email from another stream. For example, if you’re sending newsletters and transactional mail from the same domain it’s perfectly normal for a user to unsusbscribe from the newsletter and to still receive transactional mail - and to be perfectly happy about it, and not report it as spam.

Make sure that every email that a user might conceivably want to unsubscribe from has RFC 8058 one-click unsubscription headers. If you talk to the decisions makers at Large Consumer Mailbox Providers they tend to lean towards putting unsubscription options on everything, even truly transactional mail, and then deciding how best to use that unsubscription signal. If someone clicks unsubscribe on a transactional or account related mail, remove them from your marketing lists and all but the most critical transactional mail, perhaps.

But it’s OK to just ignore the warning - if you’re really sure it’s not a real problem.

It’d be cleaner, though, to help Google recognise that the bulk marketing and the transactional mail are different mail streams such that an unsubscription request would only be expected to apply to the stream it’s in.

How to distinguish the mail streams? One way would be to move them to separate sending domains, with different DKIM “d=” identifiers. But that’s a bit drastic.

Using a different email address in the From: header in different streams may provide enough of a clue for mailbox providers to recognise it. Use a consistent, static local part and domain part for each mail stream.

But this is exactly what the List-ID header was designed for. It lets you explicitly describe a mail stream, and distinguish it from other mail streams you send. It also makes it easier for mailbox providers to offer a good user experience in their unsubscription and subscription management interfaces by listing your mail streams separately and giving them a friendly, human readable name.

A List-ID header contains two things - a human readable description of the mail stream, and a unique identifier that typically looks like a hostname.

List-ID: "Offers and sales from Mr Example" <marketing.example.com>

or

List-ID: "Mr Example's receipts and shipping notices" <transactional.example.com>

The “hostname” bit doesn’t need to be a real hostname, it doesn’t need to resolve in DNS, nor does it need to be the same as any of the real hostnames used in the email. Mechanically it just has to be globally unique, but it’s a best practice for it to end in your domain name. And making it describe what the mail stream is used for is polite.

Would Feedback-ID also be used to distinguish mail streams? Sure, at Google. But List-ID is more widely recognised.

Related Posts

Sendy and one-click unsubscribe

If you’re using sendy and you’ve found that RFC 8058 one click unsubscribe fails – or, worse, seems to work but doesn’t actually unsubscribe the user – you should take a look at James’ workaround.

Read More

How to Unsubscribe

Eventually our subscribers won’t want our email in their inbox any more.

Read More

One-click unsubscribe

The worst thing about the yahoogle requirements has been their use of the term “one-click unsubscribe”. It’s an overloaded term that’s being used here to mean RFC 8058 in-app unsubscription. That’s a completely different thing to what one-click unsubscription has been used to mean for decades, often in the context of complying with legal requirements around unsubscription.

Read More