There's no two ways about it -- it truly is getting trickier to deliver email to Gmail lately. There's a lot going on here -- from the recent past, to what's happening today, through to the very near future. Let me jump right into it, starting with changes that are more likely to affect ESP/CRM customers, marketing senders and newsletter publishers.
Get ready: the bounce apocalypse is coming.Google warned us in mid-2023 that they will now begin to disable and delete Google accounts (including Gmail accounts) after two years of inactivity. This starts December 1, 2023. Your bounce rates are likely to go up. Don't fret -- these truly are invalid, abandoned addresses. Suppressing these addresses when they bounce helps you reduce useless sending effort. There truly was nobody home. Learn more on this "digital wake up call" from fellow deliverability expert Matthew Vernhout here.
"Over quota" and "out of storage" delays and blocks when sending to Gmail subscribers seem to be increasing. The common error messages here include "the email account that you tried to reach is over quota," "the recipient's inbox is out of storage space," or "the recipient's inbox is out of storage space and inactive." Keep in mind that successful message delivery to a Gmail mailbox could be prevented by a Google account being over quota due to too much data stuffed into NON-email Google services. In other words, you could be getting "over quota" deferrals from somebody who is out of space because they've stuffed their Google Drive too full of important documents. That doesn't always mean the mailbox is inactive (though at least one of the error messages helps clarify this for you). How to handle these bounces might vary based on your send cadence. Perhaps do not immediately suppress Gmail subscribers due to an "out of storage" or "over quota" error message, but also know that you won't want to keep sending to them forever, if they're not clearing up after a second or third send.
More changes are coming. Starting in early 2024, Gmail will require DMARC, as well as fully, properly implemented SPF and DKIM authentication for folks sending to more than 5,000 recipients at a time. High spam complaint rates will now be more likely to cause blocking at Gmail, too. (Yahoo, too.) Yahoo and Gmail recently announced coordinated, similar sender requirement updates that all significant email senders will want to make themselves aware of.
Now that we've started off with the marketer-centric guidance, let's add to it with more platform-oriented observations and challenges.
TLS (Transport Layer Security) seems to now be required to deliver mail to Gmail successfully. TLS is such a best practice, and so commonly implemented, that I'm not even going to test this one myself. But I am seeing multiple reports of senders having trouble with mail delivery attempts to Gmail subscribers being delayed when TLS is not enabled. Perhaps it's a volume thing; without TLS, maybe you can't get as much mail through as you might like. TLS being touted as a best practice for sending email to Gmail is nothing new. Here's me talking about it in 2015.
IPv6 is still a challenging email delivery path to Gmail. I've seen complaints that some senders are receiving authenticated-related errors or DNS-related errors when trying to send to Gmail subscribers over IPv6. In one case, I see somebody swearing up and down that they have proper DNS and authentication in place. Gmail does have spam filter bugs and glitches like everyone else, but it's rare. When in doubt, I still suggest not sending mail to Gmail over IPv6. They are MUCH more stringent and more likely to reject, filter or block your mail when sending over IPv6. And it can be trickier to get DNS and authentication correctly implemented on IPv6. This tends to impact hobbyist or EU-based senders more than others, based on where IPv6 is most popular (especially as far as using it to host mail servers, which is uncommon in the US).
Gmail is keen to stop DKIM replay attacks. And when doing so, they're now more likely to reject mail that has malformed internet email headers. That's where the "RFC 5322" bounces come from. If you're seeing those kinds of errors when sending to Gmail subscribers, your email headers are malformed and/or there are extras that shouldn't be there. (And if you're wondering, what the heck is a DKIM replay attack? Here's where you can go to learn more.)
All of these recent (and coming) changes at Gmail (and Yahoo) show us that deliverability is definitely not a static study. It continues to evolve as these large providers continue to more explicitly define best practices and are now likely to block unwanted, malformed, malicious or malformatted mail more than ever before. Savvy ESP and CRM platforms will continue to evolve as well -- so make sure you're looking to your sending platform for guidance on how they will comply with these evolving standards -- and how they will enable your ability to comply, and deliver mail successfully to the inbox, as well.
There's no two ways about it -- it truly is getting trickier to deliver email to Gmail lately. There's a lot going on here -- from the recent past, to what's happening today, through to the very near future. Let me jump right into it, starting with changes that are more likely to affect ESP/CRM customers, marketing senders and newsletter publishers.
Get ready: the bounce apocalypse is coming. Google warned us in mid-2023 that they will now begin to disable and delete Google accounts (including Gmail accounts) after two years of inactivity. This starts December 1, 2023. Your bounce rates are likely to go up. Don't fret -- these truly are invalid, abandoned addresses. Suppressing these addresses when they bounce helps you reduce useless sending effort. There truly was nobody home. Learn more on this "digital wake up call" from fellow deliverability expert Matthew Vernhout here.
"Over quota" and "out of storage" delays and blocks when sending to Gmail subscribers seem to be increasing. The common error messages here include "the email account that you tried to reach is over quota," "the recipient's inbox is out of storage space," or "the recipient's inbox is out of storage space and inactive." Keep in mind that successful message delivery to a Gmail mailbox could be prevented by a Google account being over quota due to too much data stuffed into NON-email Google services. In other words, you could be getting "over quota" deferrals from somebody who is out of space because they've stuffed their Google Drive too full of important documents. That doesn't always mean the mailbox is inactive (though at least one of the error messages helps clarify this for you). How to handle these bounces might vary based on your send cadence. Perhaps do not immediately suppress Gmail subscribers due to an "out of storage" or "over quota" error message, but also know that you won't want to keep sending to them forever, if they're not clearing up after a second or third send.
More changes are coming. Starting in early 2024, Gmail will require DMARC, as well as fully, properly implemented SPF and DKIM authentication for folks sending to more than 5,000 recipients at a time. High spam complaint rates will now be more likely to cause blocking at Gmail, too. (Yahoo, too.) Yahoo and Gmail recently announced coordinated, similar sender requirement updates that all significant email senders will want to make themselves aware of.
Though authentication is touted as an upcoming requirement, we've seen evidence that Gmail has already been moving to block some unauthenticated mail. It is very much time to implement SPF/DKIM/DMARC, if you haven't already.
Now that we've started off with the marketer-centric guidance, let's add to it with more platform-oriented observations and challenges.
TLS (Transport Layer Security) seems to now be required to deliver mail to Gmail successfully. TLS is such a best practice, and so commonly implemented, that I'm not even going to test this one myself. But I am seeing multiple reports of senders having trouble with mail delivery attempts to Gmail subscribers being delayed when TLS is not enabled. Perhaps it's a volume thing; without TLS, maybe you can't get as much mail through as you might like. TLS being touted as a best practice for sending email to Gmail is nothing new. Here's me talking about it in 2015.
IPv6 is still a challenging email delivery path to Gmail. I've seen complaints that some senders are receiving authenticated-related errors or DNS-related errors when trying to send to Gmail subscribers over IPv6. In one case, I see somebody swearing up and down that they have proper DNS and authentication in place. Gmail does have spam filter bugs and glitches like everyone else, but it's rare. When in doubt, I still suggest not sending mail to Gmail over IPv6. They are MUCH more stringent and more likely to reject, filter or block your mail when sending over IPv6. And it can be trickier to get DNS and authentication correctly implemented on IPv6. This tends to impact hobbyist or EU-based senders more than others, based on where IPv6 is most popular (especially as far as using it to host mail servers, which is uncommon in the US).
Gmail is keen to stop DKIM replay attacks. And when doing so, they're now more likely to reject mail that has malformed internet email headers. That's where the "RFC 5322" bounces come from. If you're seeing those kinds of errors when sending to Gmail subscribers, your email headers are malformed and/or there are extras that shouldn't be there. (And if you're wondering, what the heck is a DKIM replay attack? Here's where you can go to learn more.)
All of these recent (and coming) changes at Gmail (and Yahoo) show us that deliverability is definitely not a static study. It continues to evolve as these large providers continue to more explicitly define best practices and are now likely to block unwanted, malformed, malicious or malformatted mail more than ever before. Savvy ESP and CRM platforms will continue to evolve as well -- so make sure you're looking to your sending platform for guidance on how they will comply with these evolving standards -- and how they will enable your ability to comply, and deliver mail successfully to the inbox, as well.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.