The Gmail Verified Sender Program Pilot launched on September 13, 2022. All participants must meet eligibility criteria, fulfill message-based delivery requirements, and follow the Program Pilot policies.
The information below provides technical implementation guidance that may be useful to Pilot participants.
We will continue to update this document with additional guidance as appropriate.
SPF and DKIM Alignment
Messages must be strongly authenticated with aligned SPF & DKIM: SPF and DKIM must be implemented. The DKIM domain must exactly match the sending domain that's verified in the program. The SPF apex domain must also match that of the DKIM apex domain.
The SPF and DKIM domains must be on the same apex domain (e.g. example.com), but can be on different subdomains.
Eligible:
SPF Domain: newsletter.example.com
DKIM Domain: newsletter.example.com
Eligible:
SPF Domain: bounce.example.com
DKIM Domain: newsletter.example.com
One-Click Unsubscribe (Headers)
Messages must be sent with the List-Unsubscribe header and the header must be DKIM signed. If the unsubscribe protocol is HTTP/HTTPS, the message must include the List-Unsubscribe-Post header as well, and it must be DKIM signed. If the unsubscribe protocol is MAILTO, the List-Unsubscribe-Post header is optional.
Senders have the ability to use either one unsubscribe header if they use “mail-to” or use two headers when using a web URL.
Example of a compliant one-click HTTPS unsubscribe:
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Example of a compliant one-click MAILTO unsubscribe*:
List-Unsubscribe: <mailto:listrequest@example.com?subject=unsubscribe>
The precise specifications for "One-Click Unsubscribe" can be found under RFC 8058, which spell out the authoritative implementation details, and should be used as a primary reference by postmasters tasked with implementing one-click unsubscribe functionality.
Note that the List-Unsubscribe header supports the ability to specify multiple unsubscribe methods; the methods are listed in the order of sender's preference, meaning that the first unsubscribe method specified in List-Unsubscribe header will be favored over subsequent ones when the recipient initiates an unsubscribe request. There must be only one List-Unsubscribe header in the message.
The two examples below are borrowed directly from section 8 of RFC 8058.
Example of a compliant one-click HTTPS unsubscribe:
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Example of a compliant combination of MAILTO and HTTPS:
List-Unsubscribe: <mailto:listrequest@example.com?subject=unsubscribe>, <https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
When supplying only a "MAILTO" unsubscribe method, Gmail's one-click unsubscribe implementation provides some flexibility relative to the specifications recorded under RFC 8058. Although the standard requires the presence of an "HTTPS" unsubscribe method (RFC 8058, Section 3.1), Gmail can still function with only a "MAILTO" method, without the need for the List-Unsubscribe-Post header. An example of this approach is below.
Example of a compliant one-click MAILTO unsubscribe*:
List-Unsubscribe: <mailto:listrequest@example.com?subject=unsubscribe>
*The sole unsubscribe method of "MAILTO" can be treated as one-click by Gmail; this may or may not be true for other email service providers. There must only be one "List-Unsubscribe" header in the message.
In summary, when using only a "MAILTO" unsubscribe method, one (and only one) header is necessary: List-Unsubscribe. When using the "HTTPS" method, or a combination of "HTTPS" and "MAILTO" methods, then two headers are necessary: List-Unsubscribe and List-Unsubscribe-Post.
DMARC Alignment
Messages must meet the requirements of strict DKIM alignment against the DMARC domain. This means that the header "From" domain must precisely match the DKIM signing domain.
Senders do not need to explicitly define a strict DKIM alignment requirement in the DMARC record itself (i.e. the adkim=
tag is not required).
Example of a strict DMARC alignment:
From: <sender@example.com>
DKIM: d=example.com
DMARC Rollout Percentage
DMARC rollout/coverage percentage is defined by the pct
tag. Participating domains must either set this tag to 100% (pct=100;
), or must omit this tag entirely from the record (which is then implicitly treated as 100% coverage).
Failure to correctly reflect the pct
requirement in a DMARC record will result in messages being ineligible for the pilot program.
Example of a explicitly set DMARC percentage:
"v=DMARC1; p=quarantine; sp=quarantine; pct=100;"
Example of a implicitly set DMARC percentage (pct omitted):
"v=DMARC1; p=quarantine; sp=quarantine;"
Example of an ineligible DMARC percentage:
"v=DMARC1; p=quarantine; sp=quarantine; pct=75;"
DMARC Policy
A strict DMARC policy must be enabled for the participating domain, along with a strict subdomain policy (if defined).
The primary DMARC policy (p=
) must be either "REJECT" or "QUARANTINE". If a subdomain policy is defined (sp=
), it must be either "REJECT" or "QUARANTINE".
Example of a strict DMARC policy for both the organization domain and subdomains:
"v=DMARC1; p=quarantine; sp=quarantine; pct=100;"
Example of a strict DMARC policy for the organization domain (subdomain policy is implicit):
"v=DMARC1; p=quarantine; pct=100;"
Example of an ineligible DMARC policy:
"v=DMARC1; p=quarantine; sp=none; pct=100;"