Have you tried to send an email that got temporarily rejected by Google? You might have received SMTP error message 421, 4.7.26, something that looks like this:
Google is ushering in a new era of email authentication.
In 2023, Google announced new email sender requirements that would start going into effect in February, with full compliance expected for email authentication guidelines in April 2024. Currently, non-compliant senders will receive temporary error codes on a small percentage of their traffic. As senders navigate this new email landscape, they can use these codes to identify what guidelines they’re not meeting before April.
If you’ve received one of these bounce codes, it means that Gmail temporarily rejected your unauthenticated email because you’re not meeting part of the new requirements. While this temporary rejection may not have impacted your mail today, it’s a sign that messages receiving those error codes could get blocked in the future when these new requirements are enforced.
Below, we’ll review what these bounce codes are, what happens when you receive a temporary rejection, and what you can do to make sure your messages are delivered correctly.
What are the new email sender requirements?
Thanks to Google, email best practices are now becoming requirements. They announced that email senders must meet these new guidelines or risk their email getting rejected:
- Authenticate all messages with SPF and DKIM and do so in such a way that the message also passes DMARC (this requires that SPF or DKIM align with the From domain)
- Send from a domain with a DMARC policy of at least p=none
- Have valid forward and reverse DNS that match each other
- Use the one-click unsubscribe header as per RFC 8058
- Maintain a low spam rate of < 0.1%
- Encrypt your email (technically, require TLS)
While they announced these changes in October with a deadline of February 1, 2024, they extended the deadline to allow senders more time to address these. Now, senders have until April to meet these requirements, or all of their non-compliant mail will get rejected.
What are SMTP error messages?
The Simple Mail Transfer Protocol (SMTP) defines the method for exchanging email messages across the internet, and it’s the language spoken by mail servers all over the world. Included in the SMTP specification are commands and reply codes for servers to use when exchanging mail. Those reply codes start with three digits, followed optionally by three numbers separated by decimal points, followed optionally by text.
SMTP replies that start with 4 or 5 (e.g., 421 or 550) indicate that the receiving server has refused the message in question. A reply starting with 4 is called a “temporary failure,” and it means that the sending server is welcome to try again later to deliver the same message, which might be accepted during a future attempt. (Mail server software has retries in response to 4xx refusals built into the code.)
A reply starting with 5, on the other hand, is called a “permanent failure,” and it means that the message in its current form will never be accepted without something changing, either with the content of the message and/or a configuration of the sending or receiving server.
What are Google’s new error messages?
Google extended the original requirements deadline, allowing senders more time before messages become permanently blocked. Part of that effort includes sending out error messages to let senders identify what issues their domain has.
Temporary codes
Gmail has started issuing temporary errors in some cases when messages fail to comply with the new guidelines, especially early in the rollout. The latest version of their FAQ, has those errors, which we will reproduce here along with any further clarifications that we feel will benefit our customers.
Error Code | Description | Valimail Clarification |
4.7.27 | SPF isn’t set up for your sending domains or IP addresses. All senders must use either SPF or DKIM authentication for outgoing messages. Bulk senders must use both SPF and DKIM authentication for outgoing messages | This indicates that authentication of the message with SPF is not possible, likely due to there being no SPF record in place for the domain. |
4.7.30 | DKIM isn’t set up for your sending domains or IP addresses. All senders must use either SPF or DKIM authentication for outgoing messages. Bulk senders must use both SPF and DKIM authentication for outgoing messages. | This indicates that authentication of the message with DKIM is not possible. Either the message is not DKIM signed, or the message is not passing DKIM validation checks for any DKIM signatures that might be present in the message. |
4.7.23 | Your domain or IP address doesn’t have valid forward and reverse DNS records. This is a requirement for all senders | The message is originating from an IP address that does not have valid forward and reverse DNS that match each other. |
4.7.29 | Messages aren’t sent over a secure TLS connection. This is a requirement for all senders. | The message is being transmitted over an unencrypted channel. |
4.7.32 | The domain in the From: header of your messages isn’t aligned with either the SPF domain or the DKIM domain. This is a requirement for bulk senders. | The message is not passing DMARC authentication checks due to lack of alignment between the domains in the message. |
As they are temporary errors, the server trying to send the messages should retry delivery at a later time, and during the early period of the rollout, Google may eventually accept these messages with no change made to their sending configuration. However, as time goes on, at least some, if not all, of these errors may become permanent, and a sender seeing these errors should take steps now to address any shortcomings they may have in meeting the new requirements.
Permanent codes
All codes above are temporary messages. Google is only rate limiting messages that failed authentication checks, rather than outright rejecting them (for now) the messages should get delivered at a later time with no need for any changes to the messages.
However, in the long term, authentication issues will still have to be addressed to meet the new requirements. If you’re not complying with the new authentication requirements when sending to Gmail inboxes, you might have received SMTP error message 550, 5.7.26:
550, "5.7.26", "This message does not have authentication information or fails to pass authentication checks (SPF or DKIM). To best protect our users from spam, the message has been blocked. Please visit Prevent mail to Gmail users from being blocked or sent to spam for more information."
This is a new error response related to the Gmail email sender requirements, joining two others that previously existed that start with “550-5.7.26”.
550, "5.7.26", "Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. Please contact the administrator of domain-name domain. If this was a legitimate mail please visit Control unauthenticated mail from your domain to learn about the DMARC initiative. If the messages are valid and aren't spam, contact the administrator of the receiving mail server to determine why your outgoing messages don't pass authentication checks."
The above response will be received when mail sent using a domain with a DMARC policy of “p=reject” fails DMARC authentication.
550, "5.7.26", "This message fails to pass SPF checks for an SPF record with a hard fail policy (-all). To best protect our users from spam and phishing, the message has been blocked. Please visit Prevent mail to Gmail users from being blocked or sent to spam for more information."
The above response will be received when mail sent using a Return-Path (or bounce) domain that has an SPF record ending “-all” fails SPF authentication checks.
Only the first of these three indicates that the email message did not comply with the new email authentication requirements that Google has in place; the other two are rejections made at the request of the domain owner based on policies expressed in the domain owner’s DMARC or SPF record. That said, all of these error responses beginning with 550 are permanent errors, meaning that the message will not be accepted.
Does Yahoo have new error codes?
While Google is leading the charge with these guidelines, Yahoo is supporting this effort as well. They have similar requirements and timelines, and they have hinted that they will be releasing specific error codes related to these guidelines.
At the time of publication, these errors aren’t known yet, but we will update this with the latest information when it’s available.
How to check if your mail is receiving these error codes
If you’re using an email service provider (ESP) to send your mail, you’ll need to check with them on their process for handling these error codes and informing you. Each ESP could have different documentation and processes for handling these codes.
If you are still unsure of how to find your codes, try contacting your ESP team.
How to fix email sender requirement codes
Keep in mind that the sender guidelines are different for senders who send below or above the 5,000-emails-a-day threshold. And even if you’ve sent 5,000 emails in one day at one point years ago, you’ll be classified as a bulk sender.
If you’re not a bulk sender, you might get these errors because you don’t have SPF or DKIM implemented for your domain. If you are a bulk sender, you also need SPF and DKIM, but you also need DMARC to properly authenticate all of your mail. However, even if you’re a smaller sender, it may be worth setting all of these up because we believe that stricter rules will soon apply to all senders.
To fully and properly authenticate your mail, ensure you do all of the following:
- Make sure a DMARC policy is in place for each domain you use in visible From headers of your email. The DMARC policy must be p=none.
- Make sure your mail is sent using a Return-Path, or bounce, domain that has an SPF record in place. Ideally, this domain will align with the visible From domain, as per DMARC requirements. The domain MUST have an SPF record in place.
- Make sure your mail is DKIM signed when sent. Ideally, the signing domain will align with the visible From domain, as per DMARC requirements, but at a minimum, the mail MUST be DKIM signed.
- Make sure that the mail will pass DMARC validation checks. This means that at least one of SPF and DKIM must pass, and the domain for that pass must align with the visible From domain. Mailbox providers have a preference for the DKIM result to be the one responsible for the aligned pass, and best practices are for both SPF and DKIM to align with the visible From domain and generate a pass, but absolutely one of the two MUST align with the visible From domain and generate a pass.
This comprehensive plan to fully and properly authenticate your mail will, at a minimum, ensure you won’t receive SMTP replies indicating authentication shortcomings. If you aren’t sure what authentication protocols you currently have in place, use our free domain checker to get started.
Get compliant
While these error codes will only be applied to a percentage of non-compliant emails in February, bulk senders will need to be fully compliant with email authentication guidelines by April 2024.
If you’ve received these codes, making your domain compliant is vital to ensuring your emails get delivered.