To ensure user safety and privacy, dynamic emails are subject to additional security requirements and restrictions.
To ensure the sender of an AMP email is legitimate, emails containing AMP are subject to the following checks:
- The email must pass Domain Keys Identified Mail (DKIM) authentication.
- The DKIM-authenticated signing domain must be aligned with the domain of the email in the
Fromfield. See DKIM Alignment below.
- The email must pass Sender Policy Framework (SPF) authentication.
In addition, it's recommended that email senders use a Domain-based Message Authentication, Reporting and Conformance (DMARC) policy
with disposition set to either
reject. This may be enforced in the
DKIM, SPF and DMARC each appear as separate lines within the "Show Original" menu option in Gmail Web. See Check if your Gmail message is authenticated for more information.
In order for DKIM authentication to be considered "aligned", the Organizational Domain
of at least one DKIM-authenticated signing domain must be the same as the
Organizational Domain of the email address in the
From header. This is equivalent to the
relaxed DKIM Identifier Alignment as defined in the DMARC specification,
RFC7489 Section 3.1.1.
Organizational Domain is defined in RFC7489 Section 3.2
and is also referred to as the "eTLD+1" part of the domain. For example, the domain
example.com as its Organizational Domain.
DKIM-authenticated signing domain refers to the value of the
d= tag of the
For example, if a validated DKIM signature successfully verifies with
email@example.com would all be considered aligned if present in the
firstname.lastname@example.org would not, as
gmail.com doesn't match
To ensure the contents of an AMP email are encrypted in transit, you must TLS Encrypt emails containing AMP.
An icon in Gmail indicates whether an email was sent with TLS Encryption. See Check if a message you received is encrypted for more information.
All XMLHttpRequests (XHRs) that originate from an AMP email are proxied. This is done to protect the user's privacy.
The AMP for Email Cross-Origin Resource Sharing (CORS) requirements are slightly different than the existing AMP CORS requirements.
In terms of Gmail, there are two possible sources of XHR requests:
- Gmail (via a proxy server)
- AMP for Email Playground (which simulates the behavior of the proxy server)
The following describes what headers to expect in a request from each source and the headers that are included in the response by the server.
Requests coming from Gmail's proxy servers contain the following header:
They also contain the following query parameter:
__amp_source_origin=<sender email address>
For example, an XHR request from an amp-list to
that originats from an email sent by
email@example.com looks like this:
Request URL: https://firstname.lastname@example.org Request Method: GET Origin: https://mail.google.com
Your endpoint must verify these values and reject any requests that don't contain them.
All responses must contain the following three headers:
Access-Control-Allow-Origin: https://mail.google.com AMP-Access-Control-Allow-Source-Origin: <your sender email address> Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin
For example, if the email was sent by
email@example.com, then the headers
should include the following:
Access-Control-Allow-Origin: https://mail.google.com AMP-Access-Control-Allow-Source-Origin: firstname.lastname@example.org Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin
If the response doesn't contain these headers, the Gmail proxy server rejects the response and AMP doesn't render it.
Requests coming from the playground contains the following header:
Playground requests also contain the following query parameter:
To be able to work in the playground, your test endpoint must verify these values and reject any requests that don't contain them.
All responses must echo the
__amp_source_origin values from above
if they are valid:
Access-Control-Allow-Origin: https://amp.gmail.dev AMP-Access-Control-Allow-Source-Origin: email@example.com Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin
If the response doesn't contain these values, the CORS request fail, resulting in a browser console warning message.
The following describes additional URL restrictions.
XHR URLs mustn't use HTTP redirection. Requests that return a status code from
the redirection class (
3XX range) such as
302 Found or
308 Permanent Redirect
fail, resulting in a browser console warning message.