What are the requirements?
The requirements cover three core areas. In the table below, we’ll break down each area and its specific requirements (including sub-requirements), starting with the meatiest, most time-consuming requirement – email authentication.
Please note that these requirements will need to be put in place for every sending service and/or platform you send mail from – more on that below.
Bulk sender requirements
Requirement | Explanation | Benefit | Enforcement timeline |
Email authentication | |||
Set up SPF and DKIM for each domain that sends mail | SPF and DKIM are two email security protocols. You will need to define records for each protocol and add them to your DNS or the platform you use that hosts SPF and DKIM for your domain. | Improves email integrity and sender verification. | Gradual enforcement from Feb 2024 with error codes on non-compliant email traffic. |
Send with an aligned `From` domain in either the SPF or DKIM domains | SPF and DKIM alignment ensures that the sender’s domain specified in the “From” address aligns with the domains authorized by SPF records and covered by DKIM signatures, respectively. | Without having achieved alignment, you are risking your emails ending up in spam rather than in the inbox of the recipient. | See above |
Publish a DMARC policy for each domain that sends mail with at least a policy of “none” | DMARC is another email security protocol. Together with SPF and DKIM, it protects your domain from exact email impersonation. | Once a policy of reject has been reached, DMARC helps block exact domain impersonation attacks thus protecting your employees, customers and partners from malicious emails being sent on your behalf. | See above |
Ensure that sending domains or IPs have FcrDNS set up | FCrDNS stands for Forward Confirmed Reverse DNS. It is used to show the relationship between an IP address and domain name. | Helps with email deliverability. Without FCrDNS, certain mailbox providers may block or deliver mail to spam. | See above |
Use a TLS connection for transmitting email | TLS encrypts the communications between two points (the sender and the recipient) to ensure messages cannot be read in transit. | Prevents fraudsters from snooping on your emails. | See above |
One-click unsubscribe | |||
Enable one-click unsubscribe for recipients of promotional mail | Make it easy for your recipients to opt out of receiving your emails with a one-click unsubscribe link and ensure this is processed within 2 days. | Decreases chances of being marked as spam (and improves chances of landing in the inbox) thus having a positive impact on spam rates – the final Google and Yahoo requirement! | June 1, 2024 (for more details on specifics, read the Google policy enforcement timeline) |
Low spam rates | |||
Keep spam rates under 0.10% | Google and Yahoo recommend keeping spam rates below 0.1%. You should avoid ever reaching 0.3%. | Improves sender reputation and deliverability rates | Feb 1, 2024 |
Common scenarios that could lead to failure
Here is an illustrative – not exhaustive – list of common scenarios that may lead to bulk senders failing the new Google and Yahoo requirements.
Header components | DMARC policy | SPF | SPF alignment | DKIM | DKIM alignment | FCrDNS | Compliance | |
DMARC Configuration | Message 1 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🌟 This is the best practice for bulk senders |
Message 2 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=none rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | ✅ Senders are only required to have a DMARC record, not DMARC enforcement | |
Message 3 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: no record rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🔴 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | ❌ A DMARC record is required. | |
SPF & DKIM | Message 4 FROM: @example.com MAILFROM/RP: @example.comDMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🔴 | 🔴 | 🟢 | ❌ Requires SPF & DKIM |
Message 5 FROM: @example.com MAILFROM/RP: @somethingelse.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🟢 | 🔴 Sending IP not present in SPF record | 🔴 | 🟢 | 🟢 | 🟢 | ❌ Requires SPF & DKIM | |
Message 6 FROM: @example.com MAILFROM/RP: @somethingelse.com DMARC: no record DKIM: d=somethingelse rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🔴 | 🟢 | 🔴 | 🟢 | 🔴 | 🟢 | ❌ Requires SPF or DKIM alignment. By having neither this message is also not able to have DMARC. | |
FcrDNS | Message 7 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = no record A record: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🔴 | ❌ The sending IP address does not resolve to a valid hostname. |
Message 8 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com A record: no record | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🔴 | ❌ A record does not match the sending IP address. |
Help! Where are Google and Yahoo’s requirements configured?
In the table below, we break out which requirements are configured at the email service provider (ESP) level (Hubspot, MailChimp, etc) and/or at the domain level. This will help you figure out where you need to action each requirement.
It is important to note that if your organization uses multiple ESPs, you will need to configure these items in each platform. The same is true for the use of multiple domains.
Requirement | Configured at ESP/Platform level | Configured at DNS |
Implementation of both SPF and DKIM | ✅ | ✅ |
Sending with an aligned `From` domain in either the SPF or DKIM domains | ✅ | ✅ |
Sending from a domain with a DMARC policy of at least p=none (including a RUA tag, as recommended by Yahoo*) | ❌ | ✅ |
Using a TLS connection for transmitting email | ✅ | ❌ |
Valid forward and reverse DNS (FCrDNS) | ✅ | ✅ |
One-click unsubscribe (RFC 8058) | ✅ | ❌ |
Low spam reported rate | ✅** | ❌ |
*Though the inclusion of the RUA tag is currently only recommended and not mandated by Yahoo, we strongly agree with their stance. The RUA tag specifies where DMARC aggregate reports should be sent which provide a daily overview of a domain’s email traffic. These reports provide crucial insight into your SPF, DKIM, and DMARC authentication status as well as where your domain is being used, which makes it easy to find mail currently not meeting authentication requirements.
**While a low spam rate is under the control of the sender, the mail originates at the ESP level. If for example, you use Salesforce Marketing Cloud for marketing mail and SendGrid for transactional with Mailgun as a backup, your overall spam complaint rate regardless of the sending platform(s) needs to be below the 0.3% threshold.
Who is impacted by these changes?
As of Jan 3, 2024, Google’s Email Sender Guidelines state that the requirements apply to businesses sending emails to any personal Gmail inbox, so an “account that ends in @gmail.com or @googlemail.com”. They further clarify that “the requirements don’t apply to Google Workspace inbound and intra-domain messages.”
Yahoo’s ruling applies to “all domains and consumer email brands hosted by Yahoo Mail”.
How Red Sift can help you get ready
If you want an easy way to make sure your email-sending domains are ready come February 1, 2024, Red Sift makes it easy.
In under a minute, our free Investigate tool checks how you stack up against Google and Yahoo’s requirements and provides a visual breakdown of exactly what you need to action.
