Gmail: New spam-related rejections and what you need to know
URL Copied
Gmail has very recently unveiled a series of new deferral/rejection messages. You may want to familiarize yourself with the following new SMTP responses:
421 4.7.28 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited. Please visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our Bulk Email Senders Guidelines. - gsmtp
421 4.7.28 Gmail has detected an unusual rate of unsolicited mail containing one of your URL domains. To protect our users from spam, mail with the URL has been temporarily rate limited. Please visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our Bulk Email Senders Guidelines. - gsmtp
421 4.7.28 Gmail has detected an unusual rate of unsolicited mail originating from your SPF domain. To protect our users from spam, mail sent from your domain has been temporarily rate limited. Please visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our Bulk Email Senders Guidelines. - gsmtp
421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating from your DKIM domain. To protect our users from spam, mail sent from your domain has been temporarily rate limited. Please visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our Bulk Email Senders Guidelines. - gsmtp
That first one is not that new of a bounce/deferral message. It's not very commonly seen by most folks, but it's been around for a good long while now. Over the past couple of years, though, Google has been slowly ramping up the number of instances in which they would apply this rejection or deferral to an email message's delivery attempt. And now, they've added new criteria -- with new messaging clarifying specific reasons for not wanting to accept messages. That's where examples 2, 3 and 4 come into play.
What do these new rejection/deferral messages mean?
URL Domain: One or more domains in one or more links in your email message has a spammy reputation -- is being seen in a lot of mail that they would categorize as spammy. They're not telling you which link is the bad one. It could be a shared link (like an ESP's unsubscribe link) or some website you've chosen to link to.
SPF Domain: This domain is in the return-path address or MFROM address, an email address in a hidden header named "Return-Path." It is sometimes also called the bounce address. This could be a custom domain if you configured such with your email send platform, or it could be a shared domain used by your email sending platform.
DKIM Domain: This is the domain used in the DomainKeys Identified Mail (DKIM) authentication header. This is a hidden header containing a cryptographic signature to verify that a given domain is the sender or responsible party for an email message. This could be your from domain, if your email sending platform is configured to DKIM sign messages with your domain, or it could be your sending platform's domain. Many send platforms add a DKIM signature of their own to all messages, for deliverability and abuse prevention purposes. A message can have more than one DKIM signature, though it is most common for a message to have one (just your domain or just the platform's default DKIM domain) or two (your domain AND the platform's default DKIM domain). If there are multiple DKIM signatures associated with your messages, Gmail is not telling you which one is the problem one.
Shared resources are a problem here. If a sending platform (ESP, CRM, etc.,) can only use a default domain or shared domain for any of these settings, a block against a domain can impact many (possibly unrelated) clients. A block against a shared domain used across all clients will negatively impact deliverability for ALL CLIENTS of that ESP. If an email sending platform doesn't police bad activity, you're at risk. Even if they intend to police bad activity, things are shifting and it may take an ESP time to react. If you run an ESP platform, the time to rethink your shared domain strategy -- for any of these domains -- was yesterday.
Avoiding shared domains doesn't magically put you in the clear. It just prevents you from getting caught up in platform-related issues. If your SPF domain, DKIM domain, and any links in messages are all your own domain, then any blocks against those domains are blocks against you and likely point at a spam-related deliverability issue that you, the sender, not the platform, need to investigate and resolve. Note that Gmail is making it harder to get away with practices that were, in the past, less likely to cause blocking. Thus remember that "but I never used to get blocked for this in years past" means nothing today. Gmail (and almost all ISPs and MBPs) is getting better at rejecting unwanted mail. Why would that mail be unwanted, and how can you fix it? Those are the first questions to ask, to dig into, to figure out what's going on so that you can plan a fix.
Addendum: What is rate limiting? What is a 421 response?
Gmail is not outright rejecting all email messages when they respond to an email message delivery attempt with this rejection message. It is a temporary deferral, as noted by the numeric code (421) starting with a 4 (deliverability nerds will call this a 4xx response). The full "421" isn't particularly insightful, it basically just means "temporary deferral." but the text associated with that rejection tells you that the issue is spam related and that Gmail is rate limiting your email send attempts. This means that they're tightening up the entry way, only allowing a small number of messages through -- not all messages. (And that small number could be as low as zero.) They're limiting the rate (speed) at which the sending mail server is allowed to send messages, meaning fewer messages can get delivered.
Because Gmail is "deferring" messages -- not immediately rejecting them -- they remain in the sending server's (MTA's) email queue. The sending server (MTA) will periodically re-attempt delivery of these messages, but will usually give up after a longer period of time. When the sending platform give up, they'll log the message and recipient as undeliverable. The net here is that these spam issues come with delays -- delays in delivery, delays in logging, delays in showing you that messages aren't being delivered. So don't assume that just because you haven't seen any bounces yet, that everything must be okay. If you or your sending platform has the ability to show you what's going on with mail server queues, this is where you'll want to look to see what's happening in real time.
Gmail has very recently unveiled a series of new deferral/rejection messages. You may want to familiarize yourself with the following new SMTP responses:
That first one is not that new of a bounce/deferral message. It's not very commonly seen by most folks, but it's been around for a good long while now. Over the past couple of years, though, Google has been slowly ramping up the number of instances in which they would apply this rejection or deferral to an email message's delivery attempt. And now, they've added new criteria -- with new messaging clarifying specific reasons for not wanting to accept messages. That's where examples 2, 3 and 4 come into play.
What do these new rejection/deferral messages mean?
Shared resources are a problem here. If a sending platform (ESP, CRM, etc.,) can only use a default domain or shared domain for any of these settings, a block against a domain can impact many (possibly unrelated) clients. A block against a shared domain used across all clients will negatively impact deliverability for ALL CLIENTS of that ESP. If an email sending platform doesn't police bad activity, you're at risk. Even if they intend to police bad activity, things are shifting and it may take an ESP time to react. If you run an ESP platform, the time to rethink your shared domain strategy -- for any of these domains -- was yesterday.
Avoiding shared domains doesn't magically put you in the clear. It just prevents you from getting caught up in platform-related issues. If your SPF domain, DKIM domain, and any links in messages are all your own domain, then any blocks against those domains are blocks against you and likely point at a spam-related deliverability issue that you, the sender, not the platform, need to investigate and resolve. Note that Gmail is making it harder to get away with practices that were, in the past, less likely to cause blocking. Thus remember that "but I never used to get blocked for this in years past" means nothing today. Gmail (and almost all ISPs and MBPs) is getting better at rejecting unwanted mail. Why would that mail be unwanted, and how can you fix it? Those are the first questions to ask, to dig into, to figure out what's going on so that you can plan a fix.
Addendum: What is rate limiting? What is a 421 response?
Gmail is not outright rejecting all email messages when they respond to an email message delivery attempt with this rejection message. It is a temporary deferral, as noted by the numeric code (421) starting with a 4 (deliverability nerds will call this a 4xx response). The full "421" isn't particularly insightful, it basically just means "temporary deferral." but the text associated with that rejection tells you that the issue is spam related and that Gmail is rate limiting your email send attempts. This means that they're tightening up the entry way, only allowing a small number of messages through -- not all messages. (And that small number could be as low as zero.) They're limiting the rate (speed) at which the sending mail server is allowed to send messages, meaning fewer messages can get delivered.
Because Gmail is "deferring" messages -- not immediately rejecting them -- they remain in the sending server's (MTA's) email queue. The sending server (MTA) will periodically re-attempt delivery of these messages, but will usually give up after a longer period of time. When the sending platform give up, they'll log the message and recipient as undeliverable. The net here is that these spam issues come with delays -- delays in delivery, delays in logging, delays in showing you that messages aren't being delivered. So don't assume that just because you haven't seen any bounces yet, that everything must be okay. If you or your sending platform has the ability to show you what's going on with mail server queues, this is where you'll want to look to see what's happening in real time.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.