Why are Zendesk Sell emails sent via Google API landing in Outlook/Hotmail spam despite passing SPF, DKIM, and DMARC?
Matthew Whittaker
Co-founder & CTO, Suped
Published 1 Jul 2025
Updated 16 Aug 2025
8 min read
It can be incredibly frustrating when your emails, particularly those sent through a critical business tool like Zendesk Sell via Google API, consistently land in spam folders. What makes it even more perplexing is when you've done your due diligence, ensuring SPF, DKIM, and DMARC records all pass authentication checks. You might check your domain's health on Google Postmaster Tools and everything looks great there, yet your emails still don't reach Outlook and Hotmail inboxes. I've seen this exact scenario play out many times, and it points to subtleties beyond basic authentication that Microsoft's systems scrutinize.
The issue often isn't a straightforward authentication failure, but rather how the email's journey or its content subtly triggers spam filters. Even with strong authentication, receiving mail servers, especially those operated by Microsoft (Outlook.com and Hotmail), can flag emails based on a combination of factors, including sender reputation, header anomalies, and content analysis.
While Zendesk Sell leverages the Google API for sending, it's not always a clean pass-through. The platform adds its own Message-ID and other headers, and the underlying infrastructure that connects to Gmail can introduce subtle flags. Understanding these nuances is key to resolving deliverability issues even when core authentication is met.
This guide will walk you through the less obvious culprits behind Zendesk Sell emails landing in spam and provide actionable steps to improve your inbox placement.
Even when your email authentication, such as SPF, DKIM, and DMARC, is correctly configured and passing, emails can still land in spam. This is because email deliverability is a complex ecosystem, and authentication is just one piece of the puzzle. Mailbox providers like Microsoft Outlook and Hotmail employ sophisticated algorithms that evaluate numerous factors beyond just these records. They analyze sender behavior, email content, and historical data to determine if an email is legitimate or potential spam.
One often overlooked aspect is the path an email takes before it even reaches Gmail. If Zendesk Sell is sending emails from a default configured AWS EC2 machine, for instance, and that machine is EHLOing as localhost without proper reverse DNS (rDNS) configuration, this can raise red flags. While Gmail might accept and process these emails, the downstream recipient servers, especially Outlook/Hotmail, might view this as suspicious activity. They perform deeper checks, including analyzing the entire chain of 'Received' headers.
The challenge here is that if the problem originates from Zendesk's infrastructure setup connecting to Google, you might have limited direct control over it. Even if your domain's authentication records are perfect, the upstream sending patterns from Zendesk's relay servers could be impacting your deliverability. This can be a tricky conversation with vendors, as they may focus solely on your direct authentication passing.
Analyzing email headers
A crucial step in diagnosing this issue is to compare the full email headers of an email sent directly from Gmail with one sent through Zendesk Sell via Google API. Look closely at the Received headers. You might find differences in the Message-ID, or an additional Received header that reveals the actual sending server information before it reaches smtp.gmail.com. If there's a Received: from localhost or an EC2 hostname, that's a strong indicator.
Direct Gmail send
When sending directly from Gmail, the headers typically show a clean path, with the primary authentication aligned with Google's infrastructure. The Received lines will reflect Google's mail servers directly.
Example of a direct Gmail send headerplaintext
Received: from mail-ua1-f194.google.com (mail-ua1-f194.google.com [209.85.222.194])
by mx.google.com with ESMTPS id xyz.123.2023.01.01.12.00.00
for <recipient@outlook.com>;
Mon, 1 Jan 2023 12:00:00 -0800 (PST)
Zendesk Sell via Google API send
With Zendesk Sell, you'll often see an intermediate Received header that indicates the email originated from Zendesk's (or their provider's) infrastructure, even before it hits Google's servers. This additional hop, especially if configured imperfectly, can be a red flag for strict spam filters, even if the SPF, DKIM, and DMARC pass on the final hop.
Example of Zendesk Sell (via Google API) send headerplaintext
Received: from localhost (ec2-3-209-202-194.compute-1.amazonaws.com [3.209.202.194])
by smtp.gmail.com with ESMTPSA id xyz.456.2023.02.24.01.38.32
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 24 Feb 2023 01:38:32 -0800 (PST)
Microsoft, in particular, is known for its stringent filtering based on the full email path and historical sender behavior across various hops. They might be performing what's known as 2nd received line filtering, where an irregular or low-reputation upstream server, even if it's just a relay to Google, can cause emails to be flagged as spam.
Sender reputation and other filtering factors
A passing SPF, DKIM, and DMARC alone does not guarantee inbox placement, especially with Outlook and Hotmail. Your overall domain and IP reputation play a significant role. Even if your direct Gmail sends are fine, the shared infrastructure used by Zendesk to relay to Google could have a lower reputation, especially if it's sending from generic cloud IPs with poor rDNS.
The DKIM signature is crucial here. While you might see a DKIM=pass result, it's vital to confirm which domain signed the email. If the d= tag in the DKIM signature isn't your sending domain, but rather Zendesk's (like futuresimple.com) or Amazon's, it can impact your domain's individual reputation for these sends. To ensure your domain's reputation is fully leveraged, DKIM should be signed by your domain. This ensures that the reputation of your sending domain is properly associated with the emails, rather than being diluted by a third-party's reputation.
Additionally, Microsoft's new sender requirements, starting in early 2024, emphasize explicit sending practices, including a lower spam complaint rate and a valid DMARC policy. Even with a passing DMARC, a low reputation score on Microsoft's end can trigger the spam filter or even a blocklist entry (or blacklist entry). Factors like user engagement, content quality, and historical complaint rates contribute significantly to this reputation, regardless of authentication passes.
Mitigation strategies and solutions
Since you've confirmed that SPF, DKIM, and DMARC are passing, the focus shifts to less obvious areas. One strategy to improve deliverability, especially when dealing with platforms that act as relays, is to consider using a dedicated outbound relay. This allows you to have more control over the sending environment and header information, potentially scrubbing problematic headers that are introduced by the third-party system.
Alternatively, if a direct outbound relay isn't feasible, you might explore putting a Mail Transfer Agent (MTA) in the middle. This could be a Postfix server on a virtual machine, or a serverless function in a cloud environment. The role of this intermediary MTA would be to intercept the emails from Zendesk Sell, modify or remove any problematic headers (like the Received: from localhost line), and then pass them on to Google's SMTP server for final delivery. This provides a cleaner path for Microsoft to evaluate.
Improving your general email deliverability also involves maintaining a healthy sender reputation. This means consistently sending wanted mail, managing your subscriber lists, and keeping bounce and complaint rates low. Even if your authentication is perfect, a poor sender reputation can override it. Regularly monitor your sender reputation and adjust your sending practices accordingly.
Final thoughts
Ultimately, if you're experiencing persistent deliverability issues with Zendesk Sell to Outlook/Hotmaildespite passing authentication, it's often a sign that there are deeper, more subtle factors at play. These are usually related to the intermediate steps in the email's journey and the underlying infrastructure that bridges Zendesk Sell to Google's API. Focusing solely on SPF, DKIM, and DMARC won't solve these issues if the root cause lies in the server configuration or header manipulation upstream.
When facing these complex scenarios, it's beneficial to thoroughly analyze email headers and consider alternative sending configurations if Zendesk cannot adjust their underlying server configurations. Implementing a dedicated outbound relay or an intermediate MTA to scrub headers can provide the necessary control. This ensures that the messages reaching Microsoft's servers present the cleanest possible sending path, minimizing the chance of being flagged as spam.
Remember, email deliverability is an ongoing process that requires continuous monitoring and adaptation. By delving into the details of your email flow, you can uncover the specific reasons why your Zendesk Sell emails are ending up in spam and implement effective solutions to reach your intended recipients.
Views from the trenches
Best practices
Ensure your DKIM signature is by your sending domain, not just the provider, for stronger reputation.
Compare full email headers between successful direct sends and problematic platform sends to identify discrepancies.
Maintain a healthy sender reputation by focusing on engagement and low complaint rates.
Consider a dedicated outbound relay or an intermediate Mail Transfer Agent (MTA) if platform configuration is an issue.
Overlooking intermediate 'Received' headers that reveal the initial sending server's reputation.
Not monitoring email deliverability to specific providers like Outlook/Hotmail separately.
Relying solely on a third-party's default sending infrastructure without understanding its impact.
Expert tips
If using Google API for sending, verify the EHLO and rDNS configurations of the underlying servers used by your third-party platform.
Investigate the '2nd received line filtering' behavior of recipient mail servers, particularly Microsoft's.
Look for Message-IDs or other headers that reveal the intermediary sender, which could be flagging your emails.
Ensure your sending volume and list acquisition methods comply with email provider guidelines.
Expert view
Expert from Email Geeks says that the default configured AWS compute server EHLOing as localhost and without custom rDNS, when Zendesk is sending mail to Gmail, is the most likely problem, especially if Microsoft is doing 2nd received line filtering.
2023-02-24 - Email Geeks
Marketer view
Marketer from Email Geeks says that the integration is likely creating a pattern that is being matched against known spam, and suggests trying a dedicated outbound relay.
Google API for sending, it's not always a clean pass-through. The platform adds its own Message-ID and other headers, and the underlying infrastructure that connects to Gmail can introduce subtle flags. Understanding these nuances is key to resolving deliverability issues even when core authentication is met.
AWS EC2 machine, for instance, and that machine is EHLOing as localhost without proper reverse DNS (rDNS) configuration, this can raise red flags. While Gmail might accept and process these emails, the downstream recipient servers, especially Outlook/Hotmail, might view this as suspicious activity. They perform deeper checks, including analyzing the entire chain of 'Received' headers.
