Ken O’Driscoll. 2024 Update: Gmail and Yahoo! Change Their Sending Requirements
Last updated: 10 August 2024
Refer to Chapter 8 (Sender Reputation) and Chapter 11 (Email Authentication) of Email Deliverability Explained (2nd edition) for background information on topics discussed in this post.
Back in October 2023 Google and Yahoo! simultaneously announced that they would begin enforcing new requirements for bulk senders from February 2024 onwards.
By June 2024 all of the new requirements are officially being enforced.
These requirements currently only apply to their personal use domains, such as gmail.com, yahoo.com, and aol.com. Yahoo! Japan (yahoo.co.jp) is explicitly not included. Bulk senders are broadly defined as those sending thousands of messages on a daily basis to these domains.
Some of the requirements are already best practices which many senders are likely to already have in place. Other requirements are may require additional effort to implement.
If you are sending bulk emails to Google or Yahoo! domains you need to understand this. The main requirements from both providers can be summarised as follows:
Use Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)
SPF (RFC 7208) controls who can send messages from your domain. DKIM (RFC 6376) enables a domain to be cryptographically associated with an email message.
SPF has been a de facto requirement for quite some time and implementation is typically part of the onboarding process with email and CRM providers.
Remember, SPF works on the sending domain, which is the domain used the return-path message header of a message. So that is the domain where your SPF record needs to be published.
DKIM has also been a requirement for bulk messages for some time. However, its implementation can be inconsistent. Ideally DKIM should be aligned, meaning that the signing domain matches the From domain in the message. However, this may not be configured by default with all email and CRM providers. Aligning DKIM helps message filters identify your mail flow, which can aid building sending reputation.
If you manage your own sending infrastructure then you should double check that SPF is valid (passes) and your are DKIM signing with aligned domains.
Add a DMARC record and ensure it passes
The new requirement is that a bulk sender must publish a minimum of a non-enforcing DMARC policy and that it passes. That means that either SPF or DKIM needs to be aligned. As I mentioned above, aligning DKIM is preferable.
Both providers also (added December 2023) hint that they favour DMARC reporting to be enabled. This is extremely unlikely to be enforced, however it is generally a good idea, provided that you read the reports.
If you already have DMARC deployed you are probably covered but check with your DMARC vendor to be sure. Otherwise, follow the configuration recommendations from your email and CRM providers.
Keep your spam rate below a certain threshold
Spam rate is the percentage of messages recipients mark as spam over a sample period, usually 24 hours.
Both providers say that senders who consistently exceed a spam rate of 0.3% will have a much higher chance of seeing spam placement. Google (added December 2023) specifically say to aim to, on average, not exceed 0.1% and never consistently exceed 0.3%.
To put this into perspective, if you send 5,000 messages and 15 recipients mark your message as spam, that is your 0.3% threshold right there. Or, if you send 1 million messages, 3,000 complaints is the 0.3% threshold.
It is important to note that these thresholds are per-provider, meaning a spam rate of 0.1% with Google and 0.1% across Yahoo! is not a spam rate of 0.2%. While the new requirements are similar and there is coordination between both providers, they operate independently.
Yahoo! report the spam rate to providers via feedback loop (FBL), Google do not. To understand your spam rate with Google, you will need to sign up to their free Google Postmaster Tools portal.
Also, be aware that not every provider breaks out Yahoo! spam rate from the overall spam rate metric calculation. These new requirements may prompt providers to change this, but it will take time.
There is a lot of information in the book about how to keep your complaint rates low, but it all circles back to sending mail that recipients want to read.
Marketing messages need to have both an unsubscribe link and a one-click unsubscribe header
If a message is not 100% transactional in nature then you need to provide an unambiguous unsubscribe link in the body of the message. The unsubscribe link should unsubscribe them without them having to log in or provide any additional information, other than possibly clicking a confirmation button.
If you use a preference centre which does not support direct unsubscribes then you will need to include a separate unsubscribe link for the campaign next to the link to the preference centre.
You will also need to include a one-click unsubscribe message header, which allows recipients to unsubscribe directly from supported email clients. This header is typically added transparently by email or CRM providers.
There are two methods to implement one-click unsubscribe headers. The original method is specified in RFC 2369 and the newer method is specified in RFC 8058. The original method is currently much more widely supported than the newer one. However, it is likely that these new requirements have prompted some vendors to plan support for the newer specification.
Originally Google only referenced support for RFC 8058, however as of late December (2023) they have now included RFC 2369 as being acceptable too. It is obvious what both providers prefer and you should ensure that any software you use to send messages supports RFC 8058.
There is also a requirement that the unsubscribe requests are honoured within two days. Given that this is simply not possible for bulk senders in certain industries to achieve, I suspect that enforcement of this requirement will be lax, and based on the sender’s other metrics.
If you have written your own sending software or you use a third party unsubscribe service, this requirement is something which you will need to follow up on to ensure that you are compliant.
Have Forward-Confirmed reverse DNS (FCrDNS) on sending IPs
FCrDNS has been a de facto requirement for many years. So it is extremely likely that any email and CRM providers that you use will already implement it.
If you manage your own email infrastructure then you should double check that all sending IPs have FCrDNS.
If you forward bulk messages or are a mailing list, then use Authenticated Receiver Chain (ARC)
I did not cover ARC in the book because it is an experimental protocol which was not widely implemented outside large mailbox providers.
When a message is forwarded programmatically, for example, between two mailbox provider, then SPF and DKIM are vulnerable to being broken since they are fragile in different ways. This can cause inbox placement issues, especially if DMARC is enabled with an enforcing policy.
Mailing lists, also known email discussion groups, “spoof” sender addresses as part of their normal operations when they forward them to the list. They do not do this maliciously, but simply because their existence pre-dates email authentication protocols such as SPF, DKIM, and DMARC.
Authenticated Receiver Chain (ARC) is a protocol which allows a sender to cryptographically sign the authentication status of a received message, before forwarding in to the next destination. The next receiver in line can then use ARC to understand the authentication result of the message before it was forwarded. This allows for the original authentication status of an automatically forwarded message to be preserved, which can aid inbox placement.
The new requirement says that if you are some type of service or intermediary that forwards bulk messages, or expects messages you send to be forwarded, then you should implement ARC and sign those messages before you send them on their merry way. This requirement is particularly relevant to mailbox providers of all sizes and anyone operating mailing lists.
To be clear, forwarding in the context of ARC is programmatic not manual. We are not talking about recipients forwarding messages from their email clients.
Oh, if you are wondering how a typical receiver would know whether or not to trust an ARC signature from a particular provider, that problem has yet to be solved. However, very large receivers like Google and Yahoo! have enough proprietary data on senders to enable them to make informed trust decisions. ARC signing outbound messages, regardless of their forwarding status, will not hurt deliverability and may even help with larger providers.
Ensure that you comply existing RFCs
A less publicised requirement is that senders are now required to fully comply with the Simple Mail Transport Protocol (RFC 5321) and the Internet Message Format (RFC 5322) specifications.
This requirement is only relevant if you have written your own software which constructs or sends bulk emails. Even then, you should have noticed blocks before now if you were sending malformed messages.
I recommend especially focusing on Section 3.6 of RFC 5322 where it talks about the minimum and maximum number of permitted header fields in a message. Overloading headers is a method that is used as part of a DKIM replay attack, and that something that large providers like Google and Yahoo! are particularly susceptible to.
It also wound not do any harm to ensure you are rendering MIME messages properly (see resources for the RFCs).
Wrapping up
Unless you are the email provider, the vast majority of these requirements are your responsibility to ensure they are in place. Familiarise yourself with the requirements, ideally from the actually providers (see below). Talk to your vendors, they are very likely already on top of all of this.
If you already use a reputation dashboard such as Everest or Inbox Monster then you already have access to Google Postmaster Tools data, just be sure to enable it. Otherwise, sign up all of your domains to Google Postmaster Tools (GPT), which been updated to show compliance status. GPT also has an API so you could also surface the data on your own ops dashboards, if that is your thing.
I will continue to update this post if there are significant changes to the requirements.
Resources