AMP email use case guide

AMP forms in email: capture leads without leaving the inbox

AMP forms in email let subscribers submit details right inside the message, so you remove one click and one load screen. When your endpoint headers, fallback HTML, and Gmail approval are in place, this pattern can lift lead capture from high-intent readers who would never visit a separate page.

Why an in-email form can outperform a landing-page form

Every extra step in a lead flow leaks intent. If your reader has to tap a CTA, wait for a browser tab, then type into a page that may not load quickly on mobile data, some of them will drop. This is old behavior, and it still shows up in modern funnels. HubSpot's analysis of over 40,000 landing pages reported lower conversion rates as form length increased, which is a reminder that friction compounds fast when form work feels heavy (HubSpot, 2024). HubSpot field-length analysis.

AMP form UX shrinks that drop-off window. The user stays in Gmail, enters two fields, and submits in the same viewport. There's no browser context switch and no chance for a slow landing page to interrupt momentum. Industry write-ups on AMP for email show meaningful directional lift on registration and click rates when the offer is tight and the form is small (Litmus, 2024). Litmus AMP for email guide.

You can also frame this through campaign economics. If your current webinar email drives 8,000 opens and a 2.5% click rate to a form, only 200 people even see the page. A 15% page conversion rate turns that into 30 leads. If in-email submit doubles completion, which case-study teams often report for short forms, the same send produces 60 leads. You did not buy more traffic; you reduced workflow loss. That's why AMP forms usually belong in high-intent lifecycle moments instead of broad newsletter sends.

The lift is real for the right journeys, yet adoption is still small. Litmus has repeatedly described AMP for email as a niche tactic with high build effort, and its 2023 reporting put usage around 2% of programs in its sample (Litmus, 2023). Litmus complete AMP guide. You should read this as an opportunity signal: fewer teams ship it well, so good execution can still stand out.

In plain terms, use AMP forms when the ask is short and urgent, such as newsletter signup, demo request, webinar waitlist, or lead magnet unlock. If your process needs many fields, legal consent blocks, or heavy progressive profiling, an external form can still win. Keep both options available and test against the same audience segment.

How AMP forms in email work

The core element is <form action-xhr="...">. In AMP email, you submit through action-xhr, not the classic action attribute. That behavior is documented in the AMP component spec for email, and it's the first thing validators check. amp-form reference and AMP email components spec.

Method support at the component level includes GET and POST; for lead capture you should stick to POST so personal data is not pushed into query strings. After submit, AMP lets you render two response branches. A success branch maps to your success-template payload, and an error branch maps to your error-template payload. In markup, these are usually rendered inside submit-success and submit-error blocks using Mustache templates.

CORS is where many first builds fail. AMP for Email currently has two compatibility paths, and the safest backend supports both. Version 2 relies on request header AMP-Email-Sender and response header AMP-Email-Allow-Sender. Version 1 (legacy, still encountered) uses the query param __amp_source_origin and requires AMP-Access-Control-Allow-Source-Origin plus Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin. AMP CORS in email docs.

Gmail adds another security layer. XHR requests are proxied, cookies are stripped, sender authentication must pass, and missing requirements can force a fallback to HTML. Gmail security requirements. Design your endpoint as stateless and token-based, because cookie sessions are unreliable in this path.

Sandbox rules are also strict. You can't run custom JavaScript, you can't mutate form URLs with amp-bind, and redirect patterns are restricted for email safety. AMP email format spec. If you approach this as a compact, server-backed interaction rather than a mini single-page app, builds stay predictable.

There is one operational detail that gets missed in launch week: sender approval. Gmail requires registration before full production sending, and it checks sender authentication plus quality signals before enabling dynamic content at scale. Gmail sender registration process. If you test only with internal inboxes and skip registration timing, you can end up with a campaign that passes validator checks but still renders fallback HTML for the real audience. Plan registration and QA in the same sprint as endpoint development.

A working AMP form example you can ship

The snippet below is a minimum viable lead form for AMP email. It collects name and email, posts to a backend endpoint, and displays a success message in place. It also includes an explicit error state so users are never left wondering what happened.

<!doctype html>
<html ⚡4email data-css-strict>
 <head>
 <meta charset="utf-8" />
 <script async src="https://cdn.ampproject.org/v0.js"></script>
 <script
 async
 custom-element="amp-form"
 src="https://cdn.ampproject.org/v0/amp-form-0.1.js"
 ></script>
 <style amp4email-boilerplate>body{visibility:hidden}</style>
 <style amp-custom>
 .card { max-width: 520px; margin: 0 auto; padding: 20px; border: 1px solid #d1d5db; border-radius: 12px; }
 label { display: block; margin: 12px 0 6px; font: 600 14px/1.3 Arial, sans-serif; color: #111827; }
 input { width: 100%; box-sizing: border-box; height: 44px; padding: 10px 12px; border: 1px solid #9ca3af; border-radius: 8px; font: 400 16px/1.2 Arial, sans-serif; }
 button { margin-top: 14px; width: 100%; height: 44px; border: 0; border-radius: 8px; background: #1d4ed8; color: #ffffff; font: 600 15px/1 Arial, sans-serif; }
 .msg-ok { margin-top: 12px; color: #065f46; font: 500 14px/1.4 Arial, sans-serif; }
 .msg-err { margin-top: 12px; color: #991b1b; font: 500 14px/1.4 Arial, sans-serif; }
 </style>
 </head>
 <body>
 <div class="card">
 <h2>Get the 2026 inbox playbook</h2>
 <p>Enter your details and we will send the PDF in under 60 seconds.</p>

 <form
 method="post"
 action-xhr="https://api.mailneo.co/amp/leads"
 target="_top"
 >
 <input type="hidden" name="source" value="amp-newsletter-lead" />

 <label for="lead-name">Name</label>
 <input id="lead-name" type="text" name="name" autocomplete="name" required />

 <label for="lead-email">Work email</label>
 <input id="lead-email" type="email" name="email" autocomplete="email" required />

 <button type="submit">Send me the playbook</button>

 <div submit-success>
 <template type="amp-mustache">
 <p class="msg-ok">Thanks {{name}}. Check {{email}} in one minute.</p>
 </template>
 </div>

 <div submit-error>
 <template type="amp-mustache">
 <p class="msg-err">{{message}}</p>
 </template>
 </div>
 </form>
 </div>
 </body>
</html>

Walkthrough, line by line:

  1. Runtime and extension scripts. You include the AMP runtime and amp-form-0.1.js. Without the extension script, the form will render as plain markup and submit behavior fails validation.
  2. Body visibility boilerplate. The boilerplate style is mandatory in AMP email. If you remove it, Gmail can reject the AMP part and show fallback HTML.
  3. Stable visual sizing. Inputs and button are set to 44px height with explicit line-height. That protects tap targets on mobile and helps avoid client-level style drift.
  4. POST endpoint via action-xhr. This is the key route where your backend receives the submit event. It must return JSON and CORS headers for AMP email.
  5. Hidden source attribution. The hidden field lets you segment AMP-lead traffic in your CRM without relying on query params or browser referrers.
  6. Explicit input types. Use type="text" and type="email" for predictable keyboard behavior and basic validation in supported clients.
  7. Success state template. On HTTP 2xx with valid JSON, submit-success renders. The template receives fields from your backend response, so personal confirmation text is easy.
  8. Error state template. If validation fails or your endpoint returns an error, submit-error renders with a human-readable message. Always return a clear action like "try again" or "use fallback link".

This is intentionally small. You can add consent checkboxes, honeypot fields, or campaign IDs, but avoid turning the email itself into a long form. AMP email works best when the interaction takes under 20 seconds and asks for two or three fields.

Before rollout, test this markup in three layers. Layer one is static validation with the AMP validator and your ESP preview. Layer two is provider behavior in real Gmail web and app inboxes, because proxy and keyboard behavior won't match playground conditions every time. Layer three is fallback verification in Apple Mail and Outlook, since they will ignore AMP and use your HTML path. If both versions use the same backend endpoint, your analytics stays comparable and you can split performance by client family with less manual cleanup.

Backend endpoint requirements for AMP form submissions

Treat the backend contract as part of your email template. Most delivery failures in AMP forms are backend response issues, not markup errors. A production endpoint needs five things: strict headers, predictable JSON, no redirect hops, idempotency, and request throttling.

Start with headers. At minimum, return Content-Type: application/json. For AMP email CORS compatibility, support both modern and legacy modes: AMP-Email-Allow-Sender (modern) and the legacy source-origin trio Access-Control-Allow-Origin, AMP-Access-Control-Allow-Source-Origin, and Access-Control-Expose-Headers. AMP email CORS details.

Next is response shape. Return a stable object for success and error paths. In this page we refer to them as success-template and error-template. A practical success body is {"name":"Ava","email":"ava@acme.com"}; a practical error body is {"message":"Email already subscribed"}. Keep field names short and fixed so your Mustache templates stay clean.

Redirect handling is simple: avoid it. The AMP email specs and provider restrictions are strict around redirects during form submission, and even safe 302 patterns can fail in client proxies. AMP email component rules. Return final JSON directly from the first URL.

Idempotency matters more than usual because users will tap submit twice when network latency is high. Include an idempotency token in a hidden field, hash it with sender and campaign IDs, then reject duplicates for a short TTL window. This prevents double lead rows and double automations.

Rate limiting should combine endpoint-level and identity-level controls. A per-IP limit protects infrastructure, while per-email or per-token limits stop replay attempts from proxy traffic. Gmail proxies XHR requests and strips cookies, so you should not depend on cookie sessions for abuse prevention. Gmail proxy and security notes.

Authentication and observability are the two upgrades that separate a proof of concept from a reliable service. Gmail documents a signed assertion flow for proxied requests, and teams that handle sensitive profile updates should verify sender context before writing records. Gmail request authentication. For operations, log request IDs, sender domain, status code, latency, and template branch hit (success-template or error-template). Then chart these by campaign and client. Without that data, you cannot tell whether a performance drop came from copy quality, endpoint latency, or a client rendering change.

Tiny Node/Express sketch:

import express from "express";
import rateLimit from "express-rate-limit";

const app = express();
app.use(express.urlencoded({ extended: false }));
app.use(express.json());

const limiter = rateLimit({ windowMs: 60_000, max: 30 });

app.post("/amp/leads", limiter, async (req, res) => {
 const sender = req.get("AMP-Email-Sender") || "*";
 const sourceOrigin = String(req.query.__amp_source_origin || "");
 const origin = req.get("Origin") || "*";

 res.setHeader("Content-Type", "application/json");
 res.setHeader("AMP-Email-Allow-Sender", sender);
 res.setHeader("Access-Control-Allow-Origin", origin);
 res.setHeader("AMP-Access-Control-Allow-Source-Origin", sourceOrigin);
 res.setHeader(
 "Access-Control-Expose-Headers",
 "AMP-Access-Control-Allow-Source-Origin"
 );

 const name = String(req.body.name || "").trim();
 const email = String(req.body.email || "").trim().toLowerCase();

 if (!name || !email.includes("@")) {
 return res.status(400).json({ message: "Please enter a valid name and email." });
 }

 // idempotency check would go here using token + campaign + sender
 await saveLead({ name, email, source: req.body.source });

 return res.status(200).json({ name, email });
});

app.listen(3000);

If you build this endpoint once as a shared internal service, campaign teams can reuse it across webinars, gated assets, and demo forms with only small payload changes.

Gmail-specific rendering quirks you should test for

AMP validation passing is not the same as pixel-perfect rendering in Gmail apps. There are client quirks that still show up in production campaigns, and most are easy to manage once you know them.

First, the 2023 text-input height bug pattern: teams reported cases where Gmail iOS applied different default form control styles, causing clipped text baselines or compressed tap targets when height was only implicit. The safest fix is boring and effective, set explicit height, line-height, font-size, and box-sizing directly on each input. AMP iOS Gmail input styling issue.

Second, autocomplete behavior is uneven across apps and browsers. AMP's own best-practice docs say autocomplete values are not consistently supported, and some iOS input types are missing in email contexts. Build your form assuming autocomplete may fail, keep field count low, and provide clear labels so manual entry is still quick. AMP email best practices.

Third, mobile keyboard handling can trigger odd jumps in older Gmail iOS app builds. Community reports from 2023 documented scroll jumps and interaction instability during AMP interactions on iOS, which can hurt completion if your form is deep in a long message. AMP4Email Gmail iOS jump issue. Place forms near the top of the message and avoid stacking many interactive blocks before the form.

There is one more backend-side quirk worth testing: Gmail proxy formatting of form data. A documented issue showed semicolons in input values could be split unexpectedly when parsed naïvely by some servers. amp-form semicolon parsing issue. The practical defense is to parse payloads safely, normalize input, and run integration tests with realistic punctuation.

Honest tradeoffs before you commit engineering time

AMP forms are powerful, but they are not a universal answer. Outlook users will never see the interactive version, and Apple Mail users won't either. You still need a full HTML fallback with a visible CTA to a normal landing page. Gmail AMP overview.

Build cost is the second tradeoff. A normal landing-page form can ship in hours. A reliable AMP form asks for endpoint work, CORS headers, registration steps, QA across Gmail apps, and ongoing template maintenance. Teams often underestimate this first sprint.

Fallback maintenance is the third cost. Every copy change, legal line, or field tweak now exists in at least two places: AMP and HTML. If those drift, analytics and user experience drift with them. Keep your fallback as close as possible to the AMP offer and route both through the same backend where you can.

If your audience is mostly Outlook-heavy B2B, start with a strong HTML flow and revisit AMP later. If your list is Gmail-heavy consumer traffic and your CTA is short, AMP forms can be worth the extra build effort.

A fair baseline test helps avoid guessing. Send an A/B split where one cohort gets AMP plus fallback, and the other cohort gets the same copy with HTML-only CTA to a hosted form. Compare qualified leads per 1,000 delivered, not just click rate. That metric captures the full point of AMP forms: finished submissions, not vanity engagement.

How Mailneo customers can ship AMP forms faster

Mailneo customers usually succeed with a staged rollout, not a big-bang launch. Step one is validating AMP syntax and endpoint headers before live traffic. Use the AMP email validator to catch structural issues early. Step two is building a matching HTML fallback and testing the same offer copy in both versions.

For strategy and rollout order, use the pillar guide at the AMP for email guide. It maps use cases where AMP tends to pay back, including lead capture, cart recovery, and lightweight surveys. For groundwork, keep deliverability checks tight with our deliverability guide and sanity-check email copy in the spam checker.

If you want to compare this build against a less technical path, review the shorter AMP for email article first, then decide whether your use case needs in-inbox submit or just a better landing page.

For campaign operators, one practical workflow is to pair this route with pre-send QA tools. Run subject and preview checks before final deploy with the subject line tester and timing checks with the send time optimizer. AMP form quality does not rescue weak positioning, weak timing, or poor deliverability. It improves completion when the offer is already strong and the technical path is clean.

Key takeaways

  • Use AMP forms when the action is short, urgent, and high intent.
  • Build with action-xhr, JSON responses, and explicit success and error templates.
  • Support both AMP email CORS modes so Gmail and other clients behave consistently.
  • Test Gmail app quirks on real devices, especially iOS input and keyboard behavior.
  • Keep HTML fallback strong, because large parts of your list will never see AMP.

FAQ

Do AMP forms work in Outlook or Apple Mail?

No. Those clients render your HTML version, so your fallback CTA must stay fully functional. Think of AMP as enhancement for supporting inboxes, not a replacement for HTML email.

Which method should I use for lead capture, GET or POST?

Use POST for almost every lead form. GET is supported at the component level, but POST keeps personal data out of URLs and aligns with create-record backend patterns.

What is the minimum backend contract for amp-form in email?

Return JSON, set the AMP email CORS headers, avoid redirects, expose source-origin headers for legacy compatibility, and protect against duplicate submits with idempotency keys.