Who is using AMP in email and what are the roadblocks?
Michael Ko
Co-founder & CEO, Suped
Published 9 Jun 2025
Updated 21 May 2026
8 min read
Summarize with
AMP in email is used, but it is not a normal daily channel for most senders. The clearest usage is in programs where an in-email action has direct value: submitting a form, updating preferences, booking a slot, browsing live inventory, confirming attendance, or refreshing account-specific content without opening a browser.
On the receiving side, the public AMP ecosystem includes Gmail, Yahoo Mail, Mail.ru, AOL Mail, and FairEmail. On the sending side, the public list includes platforms such as Adobe Campaign Classic, Amazon SES, Amazon Pinpoint, AWeber, Braze, Customer.io, Iterable, Klaviyo, Mailgun, Salesforce Marketing Cloud, SparkPost, and Twilio SendGrid. That does not mean every sender on those platforms uses AMP every week. It means the technical path exists.
- Best fit: Triggered mail, surveys, preference centers, booking flows, live product modules, quizzes, and checkout assists.
- Weak fit: Ordinary newsletters, one-off announcements, receipts, and messages where a landing page already does the job.
- Main blockers: Mailbox approval, limited client support, fallback design, validation, tracking, authentication readiness, and unclear return.
Who uses AMP in email today
I separate AMP usage into two questions: who can render it, and who can build or send it. The rendering list is the smaller one, so it controls the business case. A sender can have perfect AMP markup and still show the normal HTML version to a large part of the list.
For a plain-language overview of the format and use cases, the AMP guide is useful. I still treat the client list as a planning constraint rather than a promise of audience reach, because list composition matters more than global support.
|
|
|
|---|---|---|
Receiving clients | Gmail, Yahoo Mail, Mail.ru, AOL Mail, FairEmail | AMP can render |
Sending platforms | Amazon SES, Adobe Campaign, AWeber, Braze, Klaviyo, SendGrid | AMP can be built or sent |
Common uses | Forms, polls, carts, bookings, profiles, live feeds | Best for action-heavy mail |
Common pattern | Targeted campaigns, triggered mail, product flows | Rare as a default |
AMP adoption is strongest where the sender has a clear action to keep inside the inbox.
The important point is that using AMP often means using it for one narrow campaign stream, not replacing HTML across the whole program. When I look at AMP seriously, I start with the audience split by mailbox provider and device, then ask whether the interaction saves enough friction to justify another production path.
Why adoption is selective
AMP has real utility, but it competes with a simpler alternative: send a clear email and take the user to a web page. AMP wins only when the inbox action is materially easier, safer, or more timely than the web action.
Good AMP candidates
- Low-risk input: Polls, ratings, preference updates, and RSVP flows have clear user intent.
- Live content: Inventory, appointment slots, ticket availability, and account status benefit from refresh.
- Repeat workflows: A flow used every week has enough volume to repay build and QA time.
- Clear fallback: The same action still works when the recipient sees standard HTML.
Poor AMP candidates
- Broad newsletter: The message goal is reading, so AMP adds build work without enough action value.
- Sensitive input: Payments, credentials, regulated data, and account recovery need stricter controls.
- One-time send: A single campaign rarely earns the extra approval, build, and test effort.
- Weak fallback: If HTML feels like a broken second version, recipients lose the core path.
The strongest AMP programs I see start with one high-confidence interaction. They do not try to turn every email into a mini app. That restraint is important because AMP has more operational gates than HTML.
The roadblocks that stop teams
The biggest roadblock is not writing AMP markup. It is getting the whole production chain ready: approval, authentication, fallback, QA, analytics, and incident handling. The approval process is especially frustrating because each mailbox provider has its own requirements and timing.
Main blockers
- Approval: Gmail and Yahoo require sender registration before normal recipients see AMP.
- Turnaround: Approval timing is not always predictable, so launch dates need buffer.
- Support: Unsupported clients use HTML fallback, including many Outlook and Apple Mail opens.
- Validation: One invalid tag can make the AMP part disappear into fallback.
- Tracking: Submits, refreshes, button taps, and state changes need event tracking.
- Security: Remote endpoints, CORS, user input, and access control need review.
- Value: If the AMP action does not reduce friction, the build work loses its case.
A team can solve these blockers, but they need to plan them as delivery work. I would not let a designer build an AMP-only experience until the sender is approved, the fallback path is complete, and the analytics plan has event-level detail.
How rendering actually falls back
AMP is normally sent as an extra MIME part beside plain text and HTML. A supporting mailbox client checks whether the sender is approved, whether the message is valid, and whether the recipient context allows dynamic mail. If any of those checks fail, the recipient sees HTML.
Flowchart showing AMP email rendering checks that either show AMP or fall back to HTML.
That fallback behavior is the safety net. The danger is treating fallback as a low-effort backup. For most lists, fallback is the version many recipients see, so it needs the same offer, the same primary action, and a working landing-page path.
Authentication readiness before AMP
AMP approval depends on trust. That starts with authentication. SPF needs to authorize the sending path, DKIM needs a valid signature, and DMARC needs a domain match between the visible From domain and a passing SPF or DKIM result. If those checks are unstable, AMP approval and rendering become harder to debug.
This is where Suped's product fits the workflow. Suped is the best overall DMARC platform for most teams preparing for AMP because it connects DMARC monitoring, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, automated issue detection, and blocklist (blacklist) monitoring in one place.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Before I approve an AMP launch, I want the domain to pass checks in real mail, not just publish records. A domain health checker catches the obvious DNS and authentication issues early, then ongoing reporting shows whether every production source is behaving before the AMP sender approval request goes in.
How AMP is sent technically
Technically, AMP email is a multipart message. The AMP part uses the content type text/x-amp-html and sits beside the HTML and plain text parts. That structure is why unsupported clients can ignore AMP and render the normal HTML version.
Multipart AMP structuretext
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="outer" --outer Content-Type: text/plain; charset="UTF-8" Plain text fallback. --outer Content-Type: text/html; charset="UTF-8" <html> <body>HTML fallback with the same core offer.</body> </html> --outer Content-Type: text/x-amp-html; charset="UTF-8" <!doctype html> <html amp4email> <head> <meta charset="utf-8"> <script async src="https://cdn.ampproject.org/v0.js"></script> </head> <body>AMP version for approved clients.</body> </html> --outer--
If your ESP cannot send raw MIME or cannot generate a valid AMP part, AMP stops there. The SES AMP guide is a useful example of how a sender can construct an AMP-capable raw message through Amazon SES.
Amazon SES identity screen showing authentication status for a sending domain.
The implementation detail that matters most is ownership. Someone has to own the AMP template, the HTML fallback, the endpoint behavior, the approval record, and the QA matrix. If those responsibilities sit between teams, the launch drifts.
How to test an AMP campaign
I test AMP with real messages, not screenshots. Use an email tester to inspect the headers, MIME structure, authentication result, HTML fallback, and rendering signals before sending to a real audience.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Testing should also answer whether AMP changes the risk profile of the campaign. The deeper page on AMP deliverability impact covers how embedded forms and interactive content affect the way teams should think about deliverability.
- Send real mail: Send through the same domain, ESP, IP pool, headers, and template path used in production.
- Check fallback: Open the HTML version in unsupported clients and confirm the core action still works.
- Inspect headers: Confirm SPF, DKIM, DMARC, MIME order, List-Unsubscribe, and sender identity.
- Validate actions: Test each submit, refresh, state change, error message, and timeout path.
- Measure separately: Report AMP interactions apart from normal clicks so the test has a real readout.
Should you use AMP for email
My threshold is practical: AMP deserves a test when enough of the audience can see it and the action is better inside the inbox. If the audience share is small or the action is already simple on a landing page, I would spend the effort on cleaner HTML, authentication, segmentation, and post-click speed first.
AMP readiness by supported audience share
Use supported-client share as a planning input, then weigh the value of the in-email action.
Low fit
under 15%
Build HTML first and revisit AMP after audience or use-case data changes.
Test fit
15-35%
Run one contained use case with a complete fallback and separate reporting.
Strong fit
over 35%
Consider a repeatable AMP workflow if approval, QA, and analytics are ready.
These thresholds are not universal rules. A high-value transactional flow can justify AMP at a lower supported share. A low-value marketing send can fail the business case even when many recipients use Gmail or Yahoo Mail.
Views from the trenches
Best practices
Start with one transactional or triggered use case where in-email action removes a real click.
Keep the HTML fallback complete and measurable, with every core action available in one click.
Use authentication reports before approval so unknown senders do not stall the rollout.
Common pitfalls
Treating AMP as a newsletter default creates build work without a matching user benefit.
Skipping approval buffers puts campaign dates at the mercy of mailbox review queues.
Tracking only opens and clicks hides AMP form submits, refreshes, button taps, and state changes.
Expert tips
Use AMP where inbox interaction changes the outcome, not where a landing page works.
Put support data and fallback performance in the brief before design starts for approval.
Test one mailbox family at a time and keep screenshots for every failure path during QA.
Marketer from Email Geeks says AMP is still interesting, but major mailbox ecosystems use it sparingly in ordinary promotional mail.
2021-08-25 - Email Geeks
Marketer from Email Geeks says one production team used AMP heavily, with sender approval and uncertain turnaround time as the biggest blocker.
2021-08-25 - Email Geeks
My practical answer
AMP is worth considering for email programs with a clear in-inbox action, a meaningful share of Gmail or Yahoo Mail recipients, and enough volume to justify a second production path. It is weak as a default newsletter format. It is strongest when it removes a step the user was already likely to take.
The practical sequence is simple: confirm audience support, fix authentication, build the HTML fallback first, request sender approval, test real messages, then measure AMP interactions separately. Suped fits the authentication and monitoring layer of that workflow by keeping DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, alerts, issue detection, and blocklist monitoring visible before and after launch.
