Gmail: Top 5 Deliverability Do's and Don'ts

Want solid inbox delivery at Gmail? Here's what you need to do (and not do) in 2016:

  1. DO enable DKIM and SPF authentication. Sender Policy Framework (SPF) is a simple DNS record that conveys what IP addresses are allowed to transmit mail for your domain. It's easy to configure and there's absolutely no reason you shouldn’t have already implemented SPF. Domain Keys Identified Mail (DKIM) is a little bit trickier. Your (or your ESP’s) outbound mail server needs to support DKIM directly; it involves signing outbound mail with a cryptographic key. You don’t see a message’s signature by default; it’s stored in a hidden header. But the receiving ISP (in this case, Gmail) uses that to ensure that the mail was truly from the domain name it claims to be from. (That’s a simplistic definition that any handful of email geeks will take issue with, but I’m going to stand behind that and say “that’s what it boils down to.”) Mail that lacks SPF and DKIM authentication is going to be more closely scrutinized by various filtering steps at Gmail. It’s not the only determining factor in inbox placement by any means, but it definitely matters.
  2. DO enable TLS. Back in November, Google warned that they were going to eventually highlight mail sent over unencrypted SMTP connections. They started doing so in February, adding a scary little "unlocked" icon to messages sent over SMTP connections that don't utilize Transport Layer Security. The reality of the situation is that Google is pushing email senders to make it harder for bad guys and governments to monitor email in transit. I don't think sniffing unencrypted marketing mail is that useful to either bad guys or governments, so I question this focus. But if you don't get rid of that little "unlocked" icon, your subscribers will probably start to wonder about you. Best to jump on board and just do it, for perhaps no real reason other than Google wants you to do it. Enabling TLS is typically pretty simple-- it's already supported by almost all mail server software and typically just needs to be enabled. The only likely downside is that the encryption adds overhead to both the mail server software and the connections it makes to other servers. What that means is that mail can end up being delivered a bit more slowly with TLS enabled.
  3. DON'T focus on "Promotions" vs "Updates" tab placement. Google wants to place marketing mail in the "Promotions" tab and trying to outsmart them is something you'll possibly get away with in the short term, but not in the long term. Google likely notices mis-categorized mail and any workaround will probably stop working after their next system update. Instead, focus on sending wanted mail and subscribers are going to read it regardless of what tab it shows up in. (And keep in mind, whichever tab it is under, it is actually in the inbox.)
  4. DON'T buy or rent lists. Google is very sensitive to feedback from Gmail subscribers. Send mail to a purchased list, and enough people will mark that mail as spam, and Gmail's filters will pick up on that and then all your mail goes to spam. Cleaning up after you fall into this trap takes time and is not fun. There is nobody we can call at Google to get them to give you a do-over and reconsider your lack of inbox placement. Sure, we all know people at Google, but they aren't willing to take those calls, because they think the filters are working as advertised and you're getting the deliverability you deserve.
  5. DO focus on engagement. Gmail's filtering is heavily engagement-driven. (You will occasionally find a marketer who swears otherwise, but they're full of beans. I am not.)  If you're struggling to get solid inbox placement, a common fix is to adjust who you're sending to so that you are mailing only subscribers who have opened or clicked in the past eighteen months. Do that for your next three-to-four weeks of mailings and that will likely result in you getting solid inbox placement, and should keep your mail out of the spam folder. (If your mail truly is wanted by your subscribers.)  Then you have to decide what to do about the rest of your subscriber base, the people who aren't responding. There's a potential for strategy there that goes beyond the scope of this simple blog post. Talk to your friendly neighborhood deliverability consultant to figure out how best to handle this.
And here's a bonus tip: DON'T focus only on a technological solution for something that is probably a permission problem. Somewhere around 99% of the time, the reason your mail is going to the spam folder is not going to be because you or your ESP missed something or didn't fully follow Gmail's Bulk Sender Guidelines. There isn't some magic header or code you need to add that will fix a deliverability problem caused by low engagement or a lack of permission. Sure, occasionally an ESP or email platform will mess something up, and you should definitely work with them to check to see that SPF, DKIM, bounce processing, and all that other stuff are working properly. But I just want to set the expectation appropriately -- it is pretty rare that a technical failure is the source of a deliverability issue.

(ETA: Of course, saying this last bit got me into trouble -- the very next client issue I looked at, a DNS issue was causing odd DKIM failures. But I still maintain that this the exception, not the rule.)

Want to learn more about Google's Gmail filters? Laura Atkins from Word to the Wise has got you covered.


  1. Hi Al,

    Great read, thanks for the article.

    I have a few questions!

    "The only likely downside is that the encryption adds overhead to both the mail server software and the connections it makes to other servers. What that means is that mail can end up being delivered a bit more slowly with TLS enabled."

    I agree overhead is generated. Do you think additional server overhead is still applicable even in clustered environments? I haven't seen anyone create a bench mark for this metric. I'm just curious how much a factor it is.

    If an MTA server is experiencing performance issues post implementation, do you think this is due to poor infrastructure, an already existing performance issue, or an already needed hardware/resources upgrade?

    Do you think this is more OR less applicable in enterprise environments (millions of emails per hour)?
    "... and the connections it makes to other servers".

    Have you heard of any ISPs having handshaking issues upon accepting TLS? If so, is this more on the EPS or ISP' end? Any additional info would be great.

    Does TLS encryption increase the size of the email being transmitted. If so, is the size increase even noticeable in terms of server resources? Assuming best practices for creative/HTML are being utilized.

    Scenario: You're explaining TLS to a non tech savvy group and the goal is to implement encryption.You touch on all of the benefits and reasons why it's important to adopt this industry standard. Do you mention the 'take aways' of utilizing TLS (overhead/additional handshake)? By the way, compared to other teams, this specific one is easily overwhelmed by technical topics.


  2. Who in the hells checks the Promotions tab? I don't.

  3. I disabled it almost immediately in my account. I prefer more granular control of what goes where and have configured Gmail's filters accordingly.


Comments policy: Al is always right. Kidding, mostly. Be polite, and you're welcome to join in, even if it's a differing viewpoint.