Google & Yahoo Bulk Sender Changes FAQ

Email service providers are required to provide the means for senders to meet the expectations set by Google and Yahoo. Email service providers should:

• Facilitate the ability to verify domain ownership through authentication records like SPF, DKIM, and DMARC

• Automatically add ARC headers to routed and forwarded messages

• Enable one-click unsubscribe through use of unsubscribe headers.

Should a sender not meet the requirements set by Google and Yahoo, their messages will not land in the inbox and instead, return an error message on blockage. An increase in these delivery failures will cause more messages from that sender to land in the spam folder, hurting their deliverability and causing lasting damage.

While the exact specifics of RFC 8058 are outlined by the IETF, one-click unsubscribe can simply be described as a header added to a marketing email that allows users to easily unsubscribe from a message.

This bypasses and solves the issue of multi-step unsubscribe processes and landing pages that might not otherwise unsubscribe a recipient from the list if they never land on the unsubscribe landing page.

There are a myriad of actions and preemptive methods that the sender can utilize to help keep their spam rates low. Some examples include, but are not limited to:

• Regularly cleaning their email list through an email validation tool

• Segmenting their email lists based on time zones, engagement level, or other criteria

• Ensure that all email templates are displaying correctly across multiple devices and service providers

• Sending to customers who have actively opted-in to receive messages

All IP addresses will be required to have their PTR records configured, as outlined by Google in their bulk sender requirement announcement. This can be an ESP’s default PTR record, or, if offered, a custom PTR record specific to the sender.

Instances of mass intentional spam campaigns are far and few between both before and after these bulk sender requirements changes.

However, if you suspect your business has been targeted by such a campaign, contacting the corresponding postmaster for either Gmail or Yahoo and explaining the situation would be the first step forward. It should be noted though, that contacting the postmaster might not remedy the situation if they find that emails sent by your business are unwanted.

When a domain has not met the standards set by Google and Yahoo for its given daily volume, messages will return with the following codes:

4.7.32 This mail has been rate limited because there is no DMARC alignment.

4.7.32 To learn more about Gmail's sender policy, go to

4.7.32  https://support.google.com/mail/answer/81126. Please contact the

4.7.32 administrator of      47 domain if this was a legitimate mail. d5-20020a0cdb05000000b0067f49d274besi8746985qvk.428 - gsmtp  

4.7.26

4.7.26 Unauthenticated email from <domain.com> is not accepted due to

4.7.26 domain's DMARC policy, but temporary DNS failures prevent

4.7.26 authentication. Please contact the administrator of appoderado.cl

4.7.26 domain if this was a legitimate mail. To learn about the DMARC

4.7.26 initiative, go to

4.7.26  https://support.google.com/mail/?p=DmarcRejection n7-20020a0cfbc7000000b0068c45be246bsi597965qvp.76 - gsmtp

4.7.26 This mail has been rate limited because it is unauthenticated. Gmail

4.7.26 requires all senders to authenticate with either SPF or DKIM.

4.7.26

4.7.26  Authentication results:

4.7.26  DKIM = did not pass

4.7.26  SPF [<domain.com>] with ip: [209.61.151.226] = did not pass

4.7.26

4.7.26  For instructions on setting up authentication, go to

4.7.26  https://support.google.com/mail/answer/81126#authentication q9-20020a056830440900b006e115acd815si925000otv.173 - gsmtp 

4.7.27 This mail has been rate limited because SPF does not pass. Gmail

4.7.27 requires all large senders to authenticate with SPF.

4.7.27

4.7.27  Authentication results:

4.7.27  SPF [<domain.com>] with ip: [69.72.34.57] = did not pass

4.7.27

4.7.27  For instructions on setting up SPF authentication, go to

4.7.27  https://support.google.com/a/answer/10685031 ew8-20020a0562140aa800b0068c7fa45187si600714qvb.52 - gsmtp  

5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes

A preference center does not solve the problems outlined in RFC 8058. A one-click unsubscribe header must be used on marketing emails to ensure that a user can unsubscribe from a message without having to engage with a preference center, depending on the user action.

Spam complaints feed into your overall complaint rate on a given domain and do affect your overall ability to land in the inbox. If you have a high spam complaint rate, your messages are more likely to land in the spam folder.

The exact impact of a spam rate is highly dependent on your overall send volume, type of message, and where those emails are being sent from (domain and IP).

This is entirely dependent on how your email program is structured. If you send all messages, both marketing and transactional, from a single domain, then a one-click unsubscribe would add them to the suppression list of that domain.

However, if your sending is split up amongst different subdomains, each subdomain’s suppression list would need to align with a one-click unsubscribe policy.