Talking 2024 Gmail Sender Requirements with Neil Kumaran

With over nine years experience at Google, Neil Kumaran has worked across multiple teams, but always focused on things close to my heart – risk mitigation, security, safety and anti-abuse. It is thus timely that he was willing to sit down and chat with me about the upcoming new Gmail sender requirements, the initial phase of which is set to begin in February.

I think it's easy for most (good) email senders to comply. I do grant, though, that there are some number of email senders who may not be technically savvy enough to know how to implement technologies like DKIM and DMARC on their own, and that work remains to be done to help educate the world about these new requirements. Hopefully discussions like this will help. And keep an eye on Spam Resource for more help and guidance. And with no further ado, on to the interview.

Hey, Neil! Thanks so much for taking the time to talk to me today. I imagine you're very busy preparing to decide exactly how to begin enforcement of the updated sender requirements.

Hey Al! Thanks for giving me this chance to talk to the community, and thank you for the work you do on this publication on making email work more smoothly for everyone. 

You're absolutely right that it's been an extremely busy time for us, but we're also very excited about the opportunity to work together as an industry to meaningfully upgrade the safety of the ecosystem.

As a recap to your readers, the foundation of the new sender requirements are:

1. Strong Authentication: Recipients deserve to trust that the emails they receive are coming from the expected source.
2. Easy Unsubscribe: Recipients should have easy, direct, and quick control over the content they receive.
3. Sending wanted messages: Senders should ensure that recipients are receiving messages that they want.

As we talk through these requirements and motivations, we've received a lot of positive feedback from both senders on the clear guidance and users on how these changes could positively impact their email experience. 

However, we realize that many folks still have questions, and so we're grateful for opportunities like this to help get the word out and answer questions that folks may have!

There's a lot of speculation among senders, email marketers, deliverability folks, theorizing exactly when and how enforcement of these new requirements will begin. I imagine the goal here is to gently nudge folks in the right direction, while doing so in a way that minimizes chances of great pain on either side. What can you tell me (and the world) today about Google's enforcement plans?

We're hoping to make enforcement as smooth of a journey as we can, while optimizing for transparency, actionable guidance, and velocity.

Here's how we're expecting that to work.

• In February, we will start temp fails a small percentage of a bulk sender's non-compliant traffic. This gives senders specific, actionable insight into the exact guidelines they aren't meeting, while their email keeps flowing.
• Later this year, we'll start rejecting a percentage of non-compliant email traffic, and we'll gradually increase the rejection rate. For example, if 75% of a sender's traffic meets our requirements, we'll start rejecting a percentage of the remaining 25% of traffic that isn't compliant. 

As we move through these changes, we'll stay in close touch with the community; listening to feedback and providing what additional guidance we can. You can always find up-to-date FAQs and information on our sender guidelines page.

Anytime there is an increase in spam filtering, or new filtering, or somebody who feels they don't deserve it suddenly sees it, there's a chance that somebody will react very loudly and very angrily about it. What would you say to somebody who is finding themselves newly blocked and who might be upset about that blocking?

We actually think these changes will help address that dynamic. Here's why.

As we talk to senders of all sizes, a common complaint is how opaque the space is, and how hard it is for them to navigate the complex web of standards, technologies, and practices in email today. Worse, implementing the wrong thing, or implementing it in the wrong way can sometimes have worse consequences than doing nothing at all. 

Senders commonly ask us what the basic, foundational things they need to do are, and these guidelines are a direct attempt to provide that clarity. The hope is that they allow us to make the upgrades we need for the entire ecosystem of email users, and that we do it in a way that helps senders through the journey as well.

For me, it's all about deliverability success, helping clients be able to deliver mail successfully to the inbox. Your view of the email universe, though, is through a bit of a different lens. What are some of the challenges that marketing senders perhaps don't realize that you are dealing with?

We have a large and dedicated team working on building solutions to keep spam out of your inbox. And while a lot of attention has (rightfully) been made about the ML and AI protections we added over the last year, in order to truly prevent abuse, we need an ecosystem-wide solution. 

Specifically, spammers today have the means to easily target domains who don't meet our authentication requirements, and with little effort execute an SPF Upgrade attack, DKIM Replay, DNS compromise, or other forms spoofing.

For these attacks to succeed, the abusive messages and the legitimate messages from a sender have to look very similar, so they are hard to distinguish from one another. Our requirements are designed to help prevent these attacks, and also help legitimate senders recover faster in case they were compromised.

In my recollection of the olden times, Gmail never really seemed to block mail. For example, various types of noncompliant mail would deliver, but to the spam folder. Unauthenticated mail, things with malformed headers, are just a couple of examples of that. Nowadays I think that Gmail is much more likely to block various types of noncompliant mail at the edge, never accepting it. Has Google's thinking evolved as far as blocking versus spam folder delivery? Is it about better user protection, evolving threats, some combination of both, or something else?

That's a really good question. Here's how I think about it. Email has evolved significantly over time: from a technology perspective, from a threat perspective, and from a user expectation perspective. Yet, our practices as an industry haven't evolved alongside them. 

Sadly, I'm old enough to remember things like kiosks at malls that allowed you to take pictures and send emails to anyone you wish as anyone you wanted to be.

Today, such an idea seems absurd. Technical, user, and societal expectations on product experiences have all changed. However, in many ways, behind the scenes, large volumes of email are still sent in the same, un (or loosely) authenticated ways.

As an example, the SPF RFC was published in 2006, and DKIM in 2011. Yet, while the vast majority of large senders have adopted these standards, it's not yet universal. And that leaves significant room for spammers and other bad actors to impersonate, attack, and otherwise cause much of the spam and malicious activity that we all hate dealing with.

Our philosophy for protecting users has stayed the same: we want our users to be confident they can send and receive the messages they want on Gmail, quickly, effectively, and securely. To do this, we work very hard to keep the noise out. If we can block an unwanted message confidently and on the edge, we will. If we receive additional intelligence post-delivery, or if we get additional feedback in real-time from users, we will place spam in the spam-folder. Regardless of where we get the signal, our actions all drive toward the same outcome of safeguarding our users' inbox experience.

Now, let's talk about some of the specifics of the updated requirements.

The DMARC requirement doesn't require a reject or quarantine policy, meaning you're not asking senders to specifically lock down their domain to any specific degree, as much as you're working to ensure that senders have at least heard of DMARC. What's the thought process around requiring DMARC, but no specific policy or reporting? How does that benefit Gmail users?

As we've talked about through this chat, our intent this year is to start the journey towards stronger authentication for bulk senders across the ecosystem, but to do so in a transparent way that minimizes disruption.

We'd love to see DMARC p=quarantine, or reject, but we realize it'll take all of us some time to get there. 

So, we're starting with:

1. Requiring both SPF & DKIM. This sets up the fundamentals needed for strong DMARC.
2. Ensuring the DMARC “from” header is aligned with the DKIM domain. This ensures that what the user generally considers as the source of the email has been validated by the sender.
3. A DMARC Policy, set to p=none. This will allow senders to start getting DMARC reports for their domain, which will both help them track down sources of unauthenticated traffic and help them understand potential spoofing and phishing attacks that may impact their business.

Spam complaints can be spikey and the math around percentages and denominators and how you roll it all up (day of send/day of receipt versus day of complaint versus differences in send volume for each of those days) and back in the before times I'd run into issues with other providers penalizing my client for a high complaint rate, when it really a rather low complaint rate – against a large send last week, but with a send denominator now being calculated a week later, when there's very little send activity. Do you plan to do any sort of averaging or smoothing out of data to perhaps help folks not get caught up in what they might consider to be false positive complaint spikes or similar things along those lines?

We recognize the fact that  the math for spam complaints is nuanced. The spam rate we report is based on spam complaints from active users for inboxed emails. In Postmaster Tools, we report spam rates for the day of send, so a high or low send volume on any given day doesn't affect the spam rate of the previous day. We attribute the spam report to when the email was received, not when the report happens. 

I see that the Sender Contact Form is evolving. It's great to see an explanation of the potential opportunity for temporary mitigation. Historically, Google seemed to send no responses to mitigation requests (though I note that at some point in the past, ticket numbers were being issued via auto response). Does Google plan to respond to requests with any sort of status update indicating that the mitigation request was approved or rejected? 

Great question. Next month, we'll start extending Postmaster Tools to provide more information and actionable guidance to senders on how their traffic is complying with the guidelines. We're looking forward to sharing this and more in the space in the coming months.

On the Sender Contact form, no specific updates to share here yet, but you can expect to see us continuing to expand the ways in which we provide transparency and communication with email senders.

What is the one (or two or three) most important thing(s) that you wish you could convince email senders to do or to implement?

We could fill a whole other blog post just answering that question. But a few big picture points as senders consider these changes:

1. When designing your emails, always keep the recipient in mind. Make your emails secure, make sure they are wanted, and make it easy to unsubscribe.
2. This is the time to board this train. Don't delay in making these changes to your infrastructure; the vast majority of senders have adopted these practices already.
3. This is an important and meaningful opportunity for all of us. We look forward to continuing to work with the industry to make the ecosystem collectively safer for our users.

Neil, I appreciate you for taking the time to chat with me about this, and letting me share this with the world. Thank you so much!