Can AMP code in emails cause increased spam placement in Outlook and Hotmail, even if they don't render AMP?
Michael Ko
Co-founder & CEO, Suped
Published 6 May 2025
Updated 17 Aug 2025
9 min read
The question of whether AMP (Accelerated Mobile Pages) code in emails can lead to increased spam placement in inboxes like Outlook and Hotmail, especially when these platforms don't even render AMP, is a common one. It seems counterintuitive. If the code isn't being used, how could it cause a problem? Yet, many marketers observe a discrepancy in performance. I've seen firsthand how this can be confusing, particularly when one version of an email, seemingly identical in its fallback HTML, performs worse in terms of deliverability.
When you're dealing with transactional emails for a large e-commerce brand, even a small drop in inbox placement can significantly impact conversions. If you've run an A/B test where the AMP-enabled version, despite having a strong sender reputation, sees a noticeable dip in open rates and higher spam placement for Outlook/Hotmail domains, it's natural to suspect the AMP code itself. However, the reality is more nuanced than it appears on the surface.
My experience suggests that while AMP code isn't the direct culprit for blocklist or spam folder placement in non-AMP supporting environments, other factors related to the overall email structure, content, or how metrics are being measured are often at play. Let's delve into why this might be happening and what you should investigate.
The myth of AMP code and Microsoft deliverability
It's a common misconception that if you include AMP for Email code in your messages, it could somehow negatively affect deliverability to Microsoft (Outlook.com, Hotmail, Live.com) inboxes. The fundamental truth here is that Microsoft does not support AMP for Email. Their systems simply ignore the AMP HTML part of a multipart message and render the standard HTML fallback version instead.
This means that for recipients using Microsoft email services, the experience is identical to receiving a regular HTML email. The AMP code essentially becomes irrelevant to the rendering process. Therefore, the presence of AMP code itself should not directly trigger spam filters or cause your emails to land in the junk folder purely because of the AMP component.
If you're observing higher spam placement for emails containing AMP code in Outlook or Hotmail, the problem likely lies elsewhere. It's crucial to look beyond the AMP code and evaluate other aspects of your email content, sending practices, and overall sender reputation. This often involves a deeper dive into email template changes, authentication, and recipient engagement.
The AMP context
Microsoft (Outlook, Hotmail, Live) does not render AMP emails. They specifically announced this decision, opting to display the HTML fallback version instead. For more information, you can refer to this article on Spam Resource.
Fallback HTML
Emails with AMP code are typically multipart messages, including both an AMP HTML part and a standard HTML fallback. Non-AMP supporting clients will always render this standard HTML. Your deliverability issues are tied to this fallback, not the AMP part.
Why Outlook and Hotmail reject AMP
When an email containing AMP code arrives at Outlook.com or Hotmail, their systems process the email in a specific way. Instead of attempting to interpret or render the AMPHTML part, they default to the alternative, non-AMP HTML version of the message. This is standard practice for email clients that don't support dynamic content formats like AMP. It ensures that recipients always see a readable version of the email.
So, if the email looks perfectly fine and renders as simple HTML in Outlook, the problem isn't with the AMP code causing a visual glitch or rendering issue that flags it as spam. The issue would stem from something else within the message or its sending parameters that the Microsoft spam filters are scrutinizing.
This leads me to believe that if you're seeing a significant drop in open rates for the AMP-enabled version, especially within specific email providers like Outlook, it's not the AMP code itself that's directly causing the spam placement. It's more likely an underlying deliverability issue that happens to be co-occurring with your AMP test.
AMP-enabled email delivery
Multipart structure: Emails with AMP typically include both an AMP HTML part and a standard HTML fallback.
AMP supported clients: Gmail and a few others render the interactive AMP version.
Microsoft's handling
Ignores AMP: Microsoft email clients like Hotmail and Outlook do not support AMP for Email. They simply bypass that part of the message.
Renders HTML fallback: The client renders the standard HTML version, ensuring compatibility and readability.
What actually causes spam placement in Microsoft environments
Given that Microsoft doesn't process AMP code, if you're seeing deliverability issues, the focus should shift to the elements that all email providers consider for spam filtering. These include:
Sender reputation: This is paramount. A high volume of spam complaints, bounces, or low engagement can severely impact your domain and IP reputation. Ensure your domain reputation is consistently strong.
Authentication: Properly configured SPF, DKIM, and DMARC records are non-negotiable. Microsoft, like Gmail and Yahoo, is enforcing stricter authentication for high-volume senders. Incorrectly configured authentication can directly lead to spam placement.
Content quality: Even the fallback HTML version can trigger spam filters if it contains malformed HTML, spammy keywords, excessive images, or too many links. Review your email template for any red flags.
Engagement: Poor engagement (low open rates, low click-through rates, high delete-without-reading rates) signals to ISPs that your emails aren't valued, leading to more aggressive filtering. While open rates aren't a perfect metric, consistent low engagement across various providers can hurt.
When comparing two email versions (one with AMP, one without), and you see a difference in deliverability to Microsoft, it's possible that subtle differences in the HTML fallback or even the larger email payload due to the AMP part are being interpreted differently by Microsoft's algorithms. This could be due to:
Code cleanliness: While AMP code is technically ignored, overly complex, or poorly structured multipart messages could theoretically be flagged by some highly aggressive spam filters, even if not directly related to the AMP functionality.
Hidden content: Some elements within the AMP part, even if not rendered, might contribute to the overall perceived spam score if they contain suspicious links or text that the filter can still parse.
Advanced troubleshooting for Microsoft spam issues
If you're facing significant spam placement issues with Outlook or Hotmail, even when using AMP with a fallback, here's what I would recommend looking into:
Review full email headers: Obtain the raw email headers for both the AMP and non-AMP versions of your message, especially from a Microsoft recipient. Look for subtle differences in the authentication results (SPF, DKIM, DMARC), spam scores, or any other header flags that might indicate a problem. Email authentication is critical.
Compare HTML fallback code: Even if the visual output is the same, inspect the raw HTML of the fallback versions. Are there any hidden elements, slightly different tracking pixels (though tracking pixels don't directly cause spam), or distinct comment blocks that could be seen as suspicious? This includes commented code.
IP and domain reputation: Verify your sending IP and domain are not on any significant blacklists or blocklists. Even if your overall deliverability is high, specific lists can impact individual providers.
It's also worth noting that open rates are an increasingly flawed metric for measuring inbox placement due to privacy features like Apple Mail Privacy Protection and pre-rendering by some email clients. While they can be an indicator, they shouldn't be the sole source of truth. Focus on clicks and conversions as more reliable metrics for engagement, and use dedicated deliverability tools for inbox placement testing.
If your AMP email has higher conversions despite lower reported opens, that's a strong signal the content is resonating with those who see it in the inbox. The lower open rate might be a tracking anomaly for Outlook/Hotmail specifically, rather than a true deliverability issue caused by the AMP code.
Views from the trenches
Best practices
Ensure SPF, DKIM, and DMARC are properly configured and aligned for your sending domain, especially for Microsoft.
Regularly monitor your domain and IP reputation using postmaster tools and blocklist checkers.
Segment your audience based on engagement and remove inactive or unengaged subscribers.
Common pitfalls
Relying solely on open rates as a measure of inbox placement, especially with AMP emails.
Assuming AMP code directly causes spam issues in non-AMP supporting clients like Outlook.
Neglecting to monitor your deliverability specifically for Microsoft (Hotmail/Outlook) domains.
Expert tips
Use a dedicated inbox placement tool to accurately measure where your emails land across various ISPs.
Test both your AMP and HTML fallback versions thoroughly before sending to large lists.
Focus on improving engagement metrics like clicks and conversions, as these are harder to fake and indicate true inbox placement.
Expert view
Expert from Email Geeks says that Outlook does not support AMP, so the issue is likely a fundamental deliverability problem and not related to the AMP code itself. They suggest focusing on the basics of email deliverability.
2023-09-20 - Email Geeks
Expert view
Expert from Email Geeks explains that opens are not a reliable metric for inbox placement, as AMP content often gets pre-rendered, and Microsoft clients would render the HTML fallback anyway. They believe AMP or HTML structure alone should not impact inbox placement.
2023-09-20 - Email Geeks
Reframing the AMP deliverability challenge
While it's tempting to blame the presence of AMP code for deliverability woes in non-AMP supporting environments like Outlook and Hotmail, the reality is that their systems simply ignore the AMP part and render the standard HTML fallback. Therefore, direct spam placement due to AMP code is highly unlikely. Instead, the focus should shift to core deliverability factors such as sender reputation, email authentication, and the quality of your fallback HTML content. By thoroughly investigating these areas, you can identify the true culprits behind any increased spam placement and work towards improving your overall inbox delivery.
Microsoft (Outlook.com, Hotmail, Live.com) inboxes. The fundamental truth here is that Microsoft does not support AMP for Email. Their systems simply ignore the AMP HTML part of a multipart message and render the standard HTML fallback version instead.
Outlook.com or Hotmail, their systems process the email in a specific way. Instead of attempting to interpret or render the AMPHTML part, they default to the alternative, non-AMP HTML version of the message. This is standard practice for email clients that don't support dynamic content formats like AMP. It ensures that recipients always see a readable version of the email.
Gmail and a few others render the interactive AMP version.
Hotmail and Outlook do not support AMP for Email. They simply bypass that part of the message.
Apple Mail Privacy Protection and pre-rendering by some email clients. While they can be an indicator, they shouldn't be the sole source of truth. Focus on clicks and conversions as more reliable metrics for engagement, and use dedicated deliverability tools for inbox placement testing.
