AMP for email allows senders to send rich and engaging emails to our users. It leverages a subset of AMPHTML components and will allow recipients to interact dynamically with content directly in the message. See the AMP developer documentation for more information.
Verizon Media's support AMP for Email is currently considered in Beta. Please check the list of supported platforms. We will add additional support and features in the future.
In order to use AMP for Email within Verizon Media's mail applications, senders will need to
We require senders to register with us before we enable AMP content within mails sent to our users.
Please follow these steps to get started:
- Read through the guidelines and requirements
- Send a real, production-ready email coming from your production server (with valid SPF/DKIM/DMARC) and the AMP MIME part to email@example.com. Do not forward mails to that address.
- Complete the registration form
Once we respond with an approval you are all set to send AMP mails to our users.
You can reach out to firstname.lastname@example.org with questions and for support.
To be approved and to be able to send AMP emails to Verizon Media the following requirements need to be met:
- Follow our Sending Best Practices
- Register with Verizon Media
- Emails must have a similar HTML or text MIME part. There are many instances where this is shown instead, such as when the user has disabled dynamic email.
- The email must be DKIM signed
- The email must pass DMARC OR DKIM with strict domain alignment
- DMARC disposition of quarantine or reject is recommended and might be enforced in the future
AMP for Email is currently supported on Yahoo Webmail only and restricted to the following browsers:
|Internet Exporer||Not Supported|
Support for AOL Mail and mobile platforms is coming soon.
Known Issues and Restrictions¶
Since we leverage our own validator there are currently some known limitations and issues which will be addressed in some future fixes. In the meantime we recommend working around them. Please reach out to us if there are further questions related to those issues.
- The DOCTYPE tag is assumed to exist. Documents without the tag will fail to return an error.
- Observance of afterbody mode is not implemented. Tags that appear following a body closing tag should be interpreted as within the body tag. Specs that mandate relationships between tags and ancestors related to the body tag will not account for this behavior and will return unexpected errors.
- Attributes are de-duped by the internal html parser (the last value assigned to an attribute is the one returned to the handler). This leads to discrepancies in attribute validation to do with validation of the uniqueness of attributes and unexpected behavior in value validation.
- Validation of URLs found within the HTML document may not return the same errors as the Node.js implementation. This stems from the fact that the internal URL library is lenient in terms of validating hostnames and characters used within the URL.
- The parser obfuscates Unicode values, this is grievous as the amp symbol is never discovered (:zap:), this package only handles the literal "amp4email." Importantly, this validator prioritizes amp4email html content, enforcement of validator logic for other formats is not guaranteed.