Gmail Dynamic Email on the Web in 2019: AMP Actions Inside the Inbox

Anil Jalela · Published Jul 28, 2019 · 11 min read

On July 2, 2019, Gmail made dynamic email generally available on the web. Eligible messages could use AMP for Email so recipients could RSVP, answer a questionnaire, browse a catalog or respond to a comment inside the message. Administrators could disable the feature, individual users could turn it off, and dynamic rendering required external images to be enabled. The launch changed email from a fixed document into a provider-controlled application surface, but only for registered senders and supported recipients. Every message still needed complete static content because authentication, policy, user settings, MIME validity, forwarding or endpoint failure could cause Gmail to render the HTML fallback instead.

The dated mailbox-provider change

Traditional email is assembled before send. The recipient opens a MIME message containing text and HTML that normally remain unchanged except for remotely loaded images. A click moves the user into a browser or application where authenticated state and current inventory can be handled.

Google introduced an AMP for Email developer preview in 2018. The open format allowed a constrained set of interactive components inside email. By July 2019, Gmail web general availability moved the concept into production for domains whose administrators had not disabled it.

The receiver retained several controls. Dynamic email was enabled by default for supported Workspace domains, but administrators and end users could opt out. External images also had to be enabled. A sender could construct valid AMP and still have a substantial audience see static HTML.

That asymmetry defined the correct architecture. AMP was progressive enhancement, not a replacement body. The dynamic experience, HTML alternative and text alternative all had to communicate the same purpose and lead to a truthful current outcome.

How the system worked before the change

Before dynamic email, an RSVP message linked to a website. A comment notification opened the document application. A catalog message showed products selected at send time and sent the recipient to a landing page for current stock or price.

This boundary simplified security. The inbox displayed content, while authenticated state changes occurred on the sender’s website. Cookies, navigation, redirects and normal browser controls were available after the click.

It also created friction and stale content. A recipient could open an old notification after the underlying comment was resolved or see a product that had sold out. The message could not safely fetch and render current application state as a normal web page would.

Analytics assumed a sequence of delivery, open, click and site conversion. That funnel was already imperfect because image requests did not prove attention, but the website click usually marked the transition from message consumption to application interaction.

What changed on the provider side

Dynamic email added a text/x-amp-html alternative to the MIME message. Gmail could validate and render that part for an eligible registered sender. If it did not render, Gmail used the static alternative rather than breaking the message.

AMP components could request current data or submit an action through constrained HTTPS endpoints. Gmail proxies these requests for privacy, so endpoints do not receive ordinary browser cookies. The application must use an appropriate bounded authorization mechanism and implement AMP for Email CORS requirements.

Google requires production senders to register each sender email address. Registration is not simply domain-wide. The submitted example must be a real production-quality message sent from production or equivalent infrastructure, with valid AMP content and the authentication characteristics expected in service.

The feature did not bypass spam filtering or sender requirements. SPF, DKIM, aligned identity, TLS, low complaint rates and current Gmail sender policy still matter. Invalid AMP, unsafe endpoints or policy violations can produce static fallback or loss of sending eligibility.

Message path before and after

Before

Static text + HTML email is delivered
    |
    v
Recipient reads message
    |
    +----> clicks link to website or application
    |
    v
Browser authenticates user and loads current state
    |
    v
Action occurs and sender measures web outcome

After

Registered sender sends text + AMP + HTML alternatives
    | authentication, TLS, policy and MIME validation
    v
Gmail web decides dynamic eligibility
    |
    +----> AMP renders -> proxied HTTPS data/action -> current state
    +----> AMP unavailable -> complete static HTML or text fallback
    |
    v
Action may finish inside message or continue on authoritative website

Who and what the change affected

Effect on delivery, placement and recipient visibility

AMP eligibility is downstream of delivery and policy. A message can authenticate and reach Gmail but display only static HTML because the sender address is unregistered, the AMP part is invalid, the user disabled dynamic email, external images are off, or Gmail policy chooses fallback.

Conversely, successful AMP rendering does not prove inbox placement for future messages. It does not repair weak permission, high complaint rates or misleading content. The sender must maintain the same wantedness and sender-requirement discipline used for ordinary mail.

Fallback quality is therefore a deliverability concern. If the static HTML says only “use the widget above,” unsupported recipients receive an incomplete message. Put current-enough context, accessible action links, legal terms and unsubscribe controls in the HTML and text alternatives.

Dynamic endpoints can create reputation problems indirectly. Slow, failing or inconsistent APIs produce a broken recipient experience after successful delivery. A form that appears to submit but loses the action encourages retries, support contacts or complaints.

Do not send AMP from a new address merely to isolate experiments. Google registration is per sender address, and arbitrary identity rotation fragments recognition and reputation. Use a stable purpose-specific identity with production authentication and a genuine history.

Effect on measurement and diagnosis

Model dynamic rendering as eligibility, not guaranteed exposure. The sender generally cannot prove every Gmail recipient rendered the AMP part. Controlled accounts can verify supported behavior, while production analytics should distinguish observed endpoint requests from assumed message presentation.

Separate data fetch from human action. An amp-list request may load content without indicating intent. A form submission, RSVP or preference change is stronger evidence, but it still needs an idempotent transaction ID and authoritative server-side result.

Preserve channel and surface. Record whether an action came from AMP email, static email, website or application, without placing plaintext recipient identity in URLs. Use opaque, scoped identifiers and protect them from log or analytics leakage.

Do not force the old open-click-conversion funnel onto in-message actions. A recipient can complete a task without a traditional link click, while proxy behavior can distort remote-resource events. Report business outcomes, failures, fallback use and repeat actions alongside email metrics.

Retain the exact sent MIME, AMP validation result, registered sender address, endpoint release, state response and action audit. Dynamic content can change after send; reproducing what the recipient could have seen requires both message and time-bounded application evidence.

Advantages for email marketers

Disadvantages and operational risks

What email teams needed to do at the time

1. Select a bounded use case. Start with RSVP, preference, comment or catalog interaction.
2. Build all MIME alternatives. Include text, valid AMP and complete HTML.
3. Authenticate production mail. Validate SPF, DKIM alignment, DMARC and TLS.
4. Register each sender address. Submit a production-quality reviewed message.
5. Secure endpoints. Implement AMP CORS and request authorization without cookies.
6. Test Gmail web settings. Cover admin enablement, user disablement and images-off fallback.
7. Make actions idempotent. Protect state changes against duplicate submission.
8. Define new metrics. Separate data fetch, task action and business result.

What email teams should do now

1. Follow current registration guidance. Recheck rules before adding any sender address.
2. Validate final received MIME. ESP transformations can remove or invalidate the AMP part.
3. Use one governed content source. Keep AMP, HTML, text and landing-page claims aligned.
4. Operate APIs as production services. Monitor TLS, latency, errors, schema and authorization.
5. Design for proxy behavior. Expect no browser cookies and implement required CORS headers.
6. Keep fallbacks independent. Every recipient must understand and complete the task without AMP.
7. Retain action evidence. Record idempotency key, actor scope, state version and result.
8. Protect privacy. Avoid plaintext identity and unnecessary data in dynamic requests.
9. Test accessibility. Verify keyboard, screen-reader, focus, error and static experiences.
10. Measure outcomes honestly. Do not equate AMP requests with attentive opens.

Worked deliverability scenario

A conference organizer sends an AMP RSVP message from a registered address. The dynamic form shows current seat availability and lets a Gmail web recipient respond without visiting the site. The HTML fallback links to the same RSVP service.

The first endpoint assumes an existing website cookie and redirects unauthenticated requests to login. Gmail proxies the XHR without that cookie, and AMP does not follow the redirect as expected. The message appears interactive but submission fails for production recipients.

The team replaces cookie dependence with a short-lived, scoped, opaque authorization token tied to the invitation and permitted action. The endpoint implements AMP email CORS, validates the state version and uses an idempotency key. It returns a clear “already registered” result if the recipient retries. The website remains the authority for complex changes.

Controlled Gmail accounts test AMP enabled, AMP disabled, images off, forwarded mail and expired invitation states. Reporting distinguishes AMP form submission, fallback-site RSVP and API failure. Completion rises without claiming that every recipient saw dynamic content or that the feature changed spam filtering.

Evidence and diagnostics

• MIME: text, AMP and HTML part order, content type, transfer encoding and final received source.
• Eligibility: registered sender address, admin setting, user setting, external images and client.
• Authentication: SPF, passing aligned DKIM, DMARC result and TLS.
• AMP validation: compiled markup, component rules, size, validation output and release version.
• Endpoint: URL, TLS, method, CORS headers, proxy behavior, latency, status and response schema.
• Authorization: opaque token, scope, expiry, nonce and replay or idempotency behavior.
• State: object version before action, conflict handling, commit ID and displayed result.
• Fallback: HTML and text comprehension, link action, accessibility and terms.
• Outcome: fetch, action attempt, committed task, fallback task, error and business result.

Failure modes and incorrect conclusions

• Calling AMP a new inbox-placement path. Filtering and sender policy still apply.
• Sending only an AMP experience. Unsupported recipients need complete fallback.
• Assuming registration covers a domain. Google registers each sender address.
• Using website cookies for API authorization. Gmail proxies requests without them.
• Returning redirects from XHR endpoints. AMP email restrictions can reject them.
• Allowing an action to replay. Duplicate submission can change state twice.
• Counting data fetches as attentive engagement. Fetch and human action are different.
• Failing to retain dynamic state. Recipient-visible behavior cannot be audited later.

Current status and superseding changes

Dynamic email remains supported in Gmail on the web and supported mobile applications. Google still requires production sender registration, production-quality content, strong authentication, TLS and compliance with current Gmail sender guidelines.

Current security guidance requires passing DKIM, alignment between a valid DKIM signing domain and the From organizational domain, SPF, encrypted transport and AMP-specific CORS for dynamic endpoints. Google proxies XHR requests and does not forward ordinary browser cookies.

Forwarding can remove the AMP MIME part, users can disable dynamic email, and compliance or content-filtering configurations can affect the experience. Static alternatives therefore remain mandatory operational content, not a ceremonial compatibility layer.

The durable architecture is a constrained application embedded in a message: registered identity, validated MIME, least-privilege API authorization, current state, idempotent actions, accessible fallback and evidence that separates provider-controlled rendering from actual recipient outcomes.

Operator checklist

• Record July 2, 2019 as Gmail web general availability.
• Register every production sender email address separately.
• Send production-quality text, AMP and HTML alternatives.
• Validate SPF, aligned DKIM, DMARC and TLS on received mail.
• Implement AMP CORS and expect proxied requests without cookies.
• Use scoped expiring opaque authorization for dynamic actions.
• Make every state-changing request idempotent.
• Keep static HTML and text complete and accessible.
• Test admin disablement, user disablement, images off and forwarding.
• Retain sent MIME, endpoint version, state and action audit evidence.
• Measure fetches, actions and outcomes as separate events.

Primary and contemporaneous references

• Google Workspace Updates: Dynamic email GA July 2, 2019: Primary web general-availability record.
• Google Developers: Register to send dynamic email: Current sender registration requirements.
• Google Developers: AMP email security requirements: Current authentication, TLS, proxy and CORS requirements.
• Google Workspace Help: Dynamic email and content filtering: Current compliance and dynamic-state guidance.

Related NitWings guides

• Gmail Dynamic Email on Mobile
• Email Rendering Testing
• Email Authentication Guide
• Email Attribution Models
• Gmail Bulk Sender Requirements