Google And Yahoo Email Authentication Requirements for Senders

• Table of Contents
• Who does this apply to?
• Overview of the technical requirements
• Definitions of terms for “domain names”
  • RFC5322.From domain
  • RFC5321.MailFrom domain
  • DKIM d= domain
• Details on each technical requirement
  • SPF
  • DKIM
  • DMARC alignment
  • Forward and Reverse DNS of Sending IPs
  • TLS encryption for email transmission
  • One-Click List-Unsubscribe header (RFC 8058)
  • Unsubscribe link in body of email
• Recommended compliance checklist
• Frequently asked questions
  • How can I test my email for compliance?
  • What happens if I don’t comply?
  • Does complying with these technical requirements mean my email will get to the Inbox?
  • How do I know what RFC5322.From Domains I’m using?
  • How do I know what RFC5321.MailFrom Domains I’m using?
  • What does 5,000 emails per day per sender mean?

Google and Yahoo both recently announced new requirements for senders of bulk email, and that as they begin enforcing these requirements they will begin rejecting email that does not meet the requirements. These requirements will start taking effect in February of 2024. We strongly recommend that you become compliant with these requirements before February 1, 2024.

Most of these requirements are just a stricter implementation of existing best practices, so other than the addition of DMARC, there is a good chance that GreenArrow users who followed our documentation to set up their domains (or who had GreenArrow Support do the installation or setup) will already satisfy nearly all of these requirements.

The purpose of this document is to help OnPrem GreenArrow customers understand the requirements and provide guidance for complying with the requirements. (GreenArrow Cloud customers will receive a ticket explaining exactly what DNS records they need to add.)

Who does this apply to?

These requirements apply to all “bulk senders” which is defined as a “sender” who is sending or has sent more than 5,000 emails per day.

If in doubt, consider yourself a “‘bulk sender” and comply with these requirements.

Overview of the technical requirements

Starting in February 2024, the following technical requirements must be met for Google and Yahoo to accept your email (to either the Inbox or the Spam folder):

Between the two, Google’s requirements are the most strict and will also satisfy Yahoo’s requirements, so in order to simplify things, we have described Google’s requirements – and we recommend setting up your authentication to meet Google’s strictest requirements.

Definitions of terms for “domain names”

Much of these requirements deal with domain names in an email message. It is important to have clear definitions of the places that domain names can appear in an email. These are the terms that this document will use:

RFC5322.From domain

This is the domain name of the email address in the “From:” header of the email.

(RFC5322 is the document that defines the Email Message Format including headers such as the “From:” header)

RFC5321.MailFrom domain

This is the domain name from the email address used in the SMTP MAIL FROM command. This email address is typically recorded in a Return-Path header when an email is delivered to a mailbox. This is the email address that bounce messages are delivered to. It is also sometimes called the “Envelope Sender.”

(RFC5321 is the document that defines the SMTP protocol, including the MAIL FROM command of SMTP.)

DKIM d= domain

This is the domain name of a valid DKIM signature. This is specified in a DKIM-Signature header in the d= parameter. It does not need to match any of the other domain names, although it often does. Because an email can have more than one DKIM signature, it can have more than one DKIM d= domain.

This document provides some more information.

Details on each technical requirement

SPF

Description of requirement:

Email must be SPF authenticated.

SPF authentication was already strongly recommended; it is now required.

What is SPF:

SPF authenticates the RFC5321.MailFrom domain of an email, by comparing the IP address that sent the email to an allow-list published in a DNS TXT record of the RFC5321.MailFrom domain.

Simple compliance guide:

Ensure that for every RFC5321.MailFrom domain that you use for sending:

• the domain has a published SPF record; and
• this SPF record includes all of your sending IPs or all IPs that you use to send email for this domain

DKIM

Description of requirement:

Email must have at least one valid DKIM Signature for any domain.

What is DKIM:

DKIM authenticates an email message against an arbitrary domain name using a cryptographic signature. Emails can have more than one DKIM signature for more than one domain name.

The full details about DKIM can be found in our documentation here. This page (and its sub-pages) contain details about what DKIM is, how to set it up in GreenArrow, and how to configure GreenArrow’s signing behavior.

Simple compliance guide:

Any DKIM signature will comply, however, it’s typically easiest if you DKIM sign your email with the RFC5322.From domain, which has been GreenArrow’s recommendation for quite some time. DKIM signing the email with the RFC5322.From domain also gets you “DMARC alignment”, which is part of why it’s the recommended method here.

To do this, ensure that for each RFC5322.From domain that you use for sending:

• you have a DKIM key configured in GreenArrow for the domain name,
• the DKIM key has “default for the domain” set to true, and
• the public key of this DKIM key is published in DNS

DMARC alignment

Description of requirement:

Email must validate as DMARC-aligned and there must be a published DMARC record (of any valid policy).

What is DMARC:

For anyone who is completely unfamiliar with DMARC, this blog post has a good overview.

Google also published a comprehensive walkthrough for how to set up DMARC.

The DMARC policy needs to be configured on the RFC5322.From domain.

The easiest way to validate an email as DMARC-aligned is to:

• DKIM sign the email with the RFC5322.From domain.

Additionally these will also validate an email as DMARC-aligned:

• Have the RFC5321.MailFrom domain validate with SPF and be an exact match or sub-domain of the RFC5322.From domain.
• Have a DKIM d= domain from a valid DKIM signature be a sub-domain of the RFC5322.From domain.

Simple compliance guide:

1. DKIM sign all email with the RFC5322.From domain

   Instructions for doing this are described in the “Simple compliance guide” under “DKIM”

2. Publish a DMARC record for every RFC5322.From domain:

   For anyone who is unfamiliar with DMARC or who does not already have a DMARC policy on their RFC5322.From domain, we recommend creating a basic DMARC record with a policy of p=none.

   This policy is effectively the same as not having a policy in place (which means it is a very safe policy to use without the risk of causing emails to be rejected or quarantined), while also still satisfying this requirement from Google/Yahoo.

   Here is an example of the DMARC policy we recommend (for example.com):

   _dmarc.example.com TXT "v=DMARC1; p=none;”
   

Forward and Reverse DNS of Sending IPs

Description of requirement:

Email must be received by Google or Yahoo from an IP with matching forward and reverse DNS.

This is not a new requirement.

Simple compliance guide:

All sending IPs must be properly configured with a matching Forward and Reverse DNS record. Instructions for setting this up can be found in our documentation for Adding a New IP Address to GreenArrow. Specifically, DNS setup is covered in Step 3 of that section of the documentation.

This is not a new requirement, so if you are out of compliance with this requirement you probably already know it because you would be getting a lot of email delivery failures. You can reasonably skip checking this.

TLS encryption for email transmission

Description of requirement:

Email must be transmitted using TLS to Google or Yahoo

GreenArrow behavior:

The encryption settings for GreenArrow deliveries are managed via the starttls_use and starttls_require directives in our documentation here.

Use of starttls_use without starttls_require will allow GreenArrow to fall back to unencrypted transmission of the email if TLS negotiation fails. Because of this new requirement, this option may result in poor delivery/inboxing of emails that have to fall back to an unencrypted connection.

Simple compliance guide:

We recommend at least:

1. Instruct GreenArrow to always attempt to use TLS on email deliveries for all domains

   (This has been the default configuration in GreenArrow for some time.)

   To enable this, add this configuration to greenarrow.conf (if not already present):

   ip_address * {
     domain * {
       starttls_use yes
     }
   }
   

   Additionally, make sure that you do not have a starttls_use no directive anywhere in your configuration that would override this on any specific domains or IP addresses.

   You may also want to:

2. Require that all deliveries to Yahoo and Gmail are done using TLS.

   This is not required, we do now recommend it in light of these new requirements.

   This configuration will prevent GreenArrow from falling back to non-TLS deliveries to Gmail and Yahoo if there happens to be some problem starting up a TLS connection. Since Gmail and Yahoo are saying that TLS is required, we can now assume that it will always be available.

   ip_address * {
     domain gmail.com,googlemail.com,mx:*.google.com,yahoo.com,aol.com,mx:*.yahoodns.net,mx:*.yahoo.com {
       starttls_require yes
     }
   }
   

One-Click List-Unsubscribe header (RFC 8058)

Description of requirement:

Email must contain a List-Unsubscribe header that uses RFC 8058 to signal that it is a one-click unsubscribe URL

Specifically, this means that there needs to be a List-Unsubscribe header with an HTTP/HTTPS URL and there needs to be a List-Unsubscribe-Post: List-Unsubscribe=One-Click header (which is what communicates that the List-Unsubscribe header may be submitted using a HTTP POST for one-click unsubscribe behavior).

Email which is truly transactional (in the eyes of the recipient) does not need to have this unsubscribe functionality.

Simple compliance guide:

GreenArrow Studio:

GreenArrow Engine SimpleMH email:

GreenArrow Engine Raw Injection email:

Unsubscribe link in body of email

Description of requirement:

Email must contain an unsubscribe link in the body of the email that is present and clearly visible.

The requirement here is that marketing and subscribed messages must include “a clearly visible unsubscribe link in the message body”.

Email which is truly transactional (in the eyes of the recipient) does not need to have an unsubscribe link.

GreenArrow behavior:

GreenArrow can manage your unsubscribe links for you in GreenArrow Marketing Studio and in GreenArrow Engine (using SimpleMH).

Senders are not required to use GreenArrow’s unsubscribe features, you just need to have an unsubscribe link that is clearly visible in the message body.

Simple compliance guide:

Review your email templates or content to ensure they meet this requirement.

Recommended compliance checklist

Here is a straight-forward checklist to ensuring compliance. This is not the only way to comply, but this checklist takes you down a straight-forward path to compliance.

1. DKIM & DMARC:

   • Get a list of all RFC5322.From domains that you are using (see FAQ question on this topic).
   • Ensure each RFC5322.From domain has a DKIM key setup in GreenArrow with “default for my domain” set to true and the public key is published in DNS.
   • Ensure that each RFC5322.From domain has a DMARC record setup. If there is not a valid DMARC record, then add the “do nothing” DMARC record documented in the “Simple compliance guide”

2. SPF:

   • Get a list of all RFC5321.MailFrom domains (see FAQ question on this topic)
   • Ensure that each RFC5321.MailFrom has a valid SPF record that authorizes all sending IP addresses.

3. One-Click List-Unsubscribe header (RFC 8058)

   • For GreenArrow Studio:
     • By default, Studio puts you in compliance, so you only need to check if you are overriding the default behavior.
     • Check if you have any Special Sending Rules that add the list-unsubscribe header. If so, update them to comply. (See the “simple compliance guide” under “One-Click List-Unsubscribe header (RFC 8058)”).
   • For GreenArrow Engine SimpleMH Email:
     • By default, Engine puts you in compliance, so you only need to check if you are overriding the default behavior.
     • To check if you are overriding the default behavior, look at your email injecting code to see if you ever add any of the following headers: List-Unsubscribe, X-GreenArrow-List-Unsubscribe-HTTP-URL, or X-GreenArrow-Disable-Auto-List-Unsubscribe-Header. If the answer is no, then you are good.
     • If you are adding one of the above headers, then see the “simple compliance guide” under “One-Click List-Unsubscribe header (RFC 8058)” for what to do.
   • For GreenArrow Engine Raw Injection Email:
     • Ensure that you are adding complaint List-Unsubscribe and List-Unsubscribe-Post headers using RFC 8058.

4. TLS encryption for email transmission

   • The default for new installations of GreenArrow has been compliant for many years.
   • Verify you have the correct greenarrow.conf configuration in place. To do this, see the “Simple compliance guide” under “TLS encryption for email transmission”

5. Forward and Reverse DNS of Sending IPs

   • This is not a new requirement, so if you are out of compliance with this requirement you probably already know it because you would be getting a lot of email delivery failures. You can reasonably skip checking this.

6. Unsubscribe link in body of email

   • This is not a new requirement. This was already a requirement, so you could reasonably skip checking this.
   • Verifying this may require auditing the body of your email messages.
   • In GreenArrow Studio you can enable a feature that will not allow you to send a campaign that is missing an unsubscribe link. (See the “Require Unsub Links” setting in the “Organization” settings page.)

7. Check your work

   • Use the https://AboutMy.email testing tool to test sample messages.
   • We recommend testing every RFC5322.From domain and RFC5321.MailFrom domain.

Frequently asked questions

How can I test my email for compliance?

Senders can manually test their email authentication results by signing up for a free Gmail email account and sending a test message to that email address. Once you receive the test, you can check the results of Google’s validation printed in the email headers.

There are also some 3rd party tools that can analyze a test email and report back to you what it finds.

We have observed a high rate of false negatives (incorrectly reporting a failure when it passes in a manual test) from several 3rd party testing systems in the past, so if you receive a failure from one of these testing systems we recommend validating those results through a manual test as described above before making changes to your email authentication.

Here is a new (free!) service created by an industry expert we know. It provides a comprehensive report (including validating all of these requirements), and our tests so far indicate that the results are accurate:

https://AboutMy.email

What happens if I don’t comply?

The Mailbox Providers don’t publish the exact results/metrics that they’re using to measure the severity of non-compliance, but they clearly state that non-compliance will result in non-delivery of messages, or delivery to the spam folder.

Moving to require this degree of authentication is a significant change in the industry. So while we are hopeful that they will be somewhat lenient in the initial weeks after enforcing the new requirements, it is likely that the deliverability impacts of non-compliance will be immediate starting in February.

Does complying with these technical requirements mean my email will get to the Inbox?

No. These are requirements for your email to be accepted by Gmail and Yahoo, after which point they may put it in the Inbox or Spam folder.

How do I know what RFC5322.From Domains I’m using?

In GreenArrow Studio you can look at the “From Email” setting in the “Delivery Settings” of each Campaign and Autoresponder to see what RFC5322.From Domains you are using.

In GreenArrow Engine, the RFC5322.From Domain of each email is determined by the From header for SMTP injection and by the from_email field for the HTTP Submission API.

GreenArrow logs the RFC5322.From Domain of each delivery attempt (for both Engine and Studio) in:

• the internal SMTP delivery event logfiles (accessed through hvmail_report) in the from_address field
• the delivery_attempt events (which can be posted to a webhook, written to a logfile, written to a database, or piped to a command) in the from_address field

If you are storing delivery_attempt events, then look at the from_address field for all delivery attempts with the channel of remote.

When looking at the internal SMTP delivery event logfiles, look at the from_address field of the hvmail_report --processed-logfile --human output for all delivery attempts with the channel of remote.

Here is a command line option that prints all RFC5322.From Domains used in the last day (by both Engine and Studio) from the internal SMTP delivery event logfiles:

hvmail_report -q all --last '1 day' --processed-logfile --human | grep ' channel=<remote> ' | perl -e ' while(<STDIN>) { m/ from_address=<[^@]*@(\S+)> / && ( $a{$1} = 1 ) }; print join("\n", sort keys %a), "\n"; '

How do I know what RFC5321.MailFrom Domains I’m using?

In GreenArrow Studio you can look at the “Bounce Email” setting in the “Delivery Settings” of each Campaign and Autoresponder to see what RFC53221.MailFrom Domains you are using.

In GreenArrow Engine SimpleMH email, the RFC5321.MailFrom Domain of each email is determined by the “Bounce Address” of the Mail Class and can be overridden by the X-GreenArrow-BounceMailboxOverride header.

You can also get a list of all possible RFC5321.MailFrom Domains by looking at the Incoming Email Domains configuration, and get a list of all Domains and Domain Aliases that have a bounce mailbox.

GreenArrow logs the RFC5321.MailFrom domain of each delivery (for both Engine and Studio) in:

• the internal SMTP delivery event logfiles (accessed through hvmail_report) in the sender field
• the delivery_attempt events (which can be posted to a webhook, written to a logfile, written to a database, or piped to a command) in the sender field

If you are storing delivery_attempt events, then look at the sender field for all delivery attempts with the channel of remote.

When looking at the internal SMTP delivery event logfiles, look at the sender field of the hvmail_report --processed-logfile --human output for all delivery attempts with the channel of remote.

Here is a command line option that prints all RFC5321.MailFrom Domains used in the last day (by both Engine and Studio) from the internal SMTP delivery event logfiles:

hvmail_report -q all --last '1 day' --processed-logfile --human | grep ' channel=<remote> ' | perl -e ' while(<STDIN>) { m/ sender=<[^@]*@(\S+)> / && ( $a{$1} = 1 ) }; print join("\n", sort keys %a), "\n"; '

What does 5,000 emails per day per sender mean?

There have been a lot of questions around the 5,000 email per day threshold to be considered a “bulk sender:”

An ESP itself is not considered a “sender” here, but the original company/domain/brand with the relationship with the subscribers.

Google and Yahoo representatives have clearly said in conference calls that if you are anywhere near this threshold, no matter how you slice it (domain/brand), then you should consider yourself a “Bulk Sender” and comply with these requirements. Do not attempt to stay under or game this threshold, as they have systems to detect snowshoeing across domains and penalize that behavior.