Summary
When Zendesk Sell emails, sent via the Google API, land in Outlook or Hotmail spam folders despite passing SPF, DKIM, and DMARC, it indicates that common authentication checks alone are not sufficient for inbox placement. This complex issue often stems from nuanced interactions between Zendesk's specific sending methods, Google's relaying infrastructure, and Microsoft's sophisticated spam filtering algorithms. The problem lies beyond basic email authentication, pointing towards deeper header analysis and sender reputation factors specific to Outlook and Hotmail. Resolving this often requires a detailed examination of email headers and understanding Microsoft's filtering practices.
Key findings
- Authentication passes: The sender's domain passes SPF, DKIM, and DMARC, indicating proper setup of core email authentication protocols.
- Sending mechanism: Zendesk Sell uses the Google API to send emails through the user's Google Workspace account, not its own SMTP servers. Zendesk provides guidelines on email deliverability.
- Header differences: Emails sent via Zendesk Sell often include distinct headers, such as Zendesk's message ID and Received headers from AWS EC2 compute servers.
- Microsoft filtering: Outlook and Hotmail (Microsoft properties) likely employ stricter filtering, potentially including second received line filtering or reputation checks on intermediate servers.
Key considerations
- Analyze full headers: A detailed comparison of email headers from a direct Gmail send versus a Zendesk Sell send is crucial to pinpoint discrepancies affecting deliverability.
- Microsoft's unique criteria: Microsoft's filtering can be particularly sensitive to certain sender patterns or IP reputations, even for shared Google outbound IPs. Learn about deliverability issues with Microsoft Outlook.
- Intermediate server configuration: Issues like a default configured AWS compute server EHLOing as localhost or lacking custom rDNS can be red flags.
- Beyond authentication: While SPF, DKIM, and DMARC are fundamental, they do not guarantee inbox placement if other signals indicate spam or low reputation. Troubleshoot emails landing in spam.
What email marketers say
Email marketers frequently encounter deliverability problems with emails sent through third-party platforms that leverage common email services like Google Workspace. They often observe that despite correct authentication, certain integrations inadvertently create patterns that trigger spam filters, particularly for discerning recipients like Outlook/Hotmail. Discussions among marketers emphasize the importance of understanding the subtle ways these platforms modify email headers and impact overall sender reputation.
Key opinions
- Platform capabilities: Many marketers express concern over the inherent deliverability capabilities of some CRM or sales platforms, suggesting they may not prioritize email sending infrastructure. Mailjet offers a guide on how to avoid spam filters.
- Integration patterns: The specific integration method, even when using Google API, can introduce unique email patterns that spam filters, especially those at Microsoft, learn to identify as problematic.
- Direct vs. platform sending: A common observation is that emails sent directly from a personal Gmail account deliver successfully, while the same content sent via a connected platform like Zendesk Sell lands in the spam folder.
- Domain reputation and volume: For domains that are new or sending low volumes, issues might resolve over time as a positive sender reputation is established. For more information, see our guide to understanding your email domain reputation.
Key considerations
- Header review: Thoroughly examining all email headers, particularly the Received and Message-ID fields, can reveal subtle clues that differentiate successful sends from spam-filtered ones. Many marketers wonder why emails go to spam despite passing authentication.
- Reputation isolation: If possible, configure DKIM to sign with your own domain rather than the platform's, to ensure your domain's reputation is independent.
- Alternative relays: Consider using a dedicated outbound relay or another email service provider that offers more control over sending patterns and header information.
- Content and engagement: Even with perfect technical setup, poor content, low engagement, or high complaint rates can lead to spam placement. Regularly review email content and monitor recipient feedback.
Marketer view
Marketer from Email Geeks explains that the email addresses in question are registered within their platform. These emails typically serve as follow-ups to transactional emails, although the original transactional messages originate from a subdomain. This distinction is important for understanding the specific sending context.
Marketer view
Marketer from Email Geeks details that the problematic emails are follow-ups to transactional messages originating from a subdomain. They question how permission for these addresses is collected, suggesting that the consent process might influence deliverability.
What the experts say
Email deliverability experts dive deep into the technical intricacies of email flow, especially when third-party applications interact with major email providers. They often highlight how subtle header modifications or intermediate server configurations, which might seem minor, can significantly impact deliverability with strict mailbox providers like Microsoft. Their insights focus on identifying hidden red flags that go unnoticed by standard authentication checks.
Key opinions
- Zendesk's relay: Some experts point to Zendesk's use of a default configured AWS compute server to send mail to Gmail, which might EHLO as localhost and lack custom rDNS, impacting trust.
- Layered filtering: Microsoft's email platforms are suspected of performing second received line filtering, meaning they scrutinize the full path an email takes, not just the final sender.
- Mitigation challenges: Google typically will not intervene with Microsoft to mitigate issues arising from shared Google outbound IPs, making direct sender resolution difficult. Stellastra discusses how to stop Zendesk emails going to junk.
- Header scrubbing: A potential solution involves placing a mail transfer agent (MTA) in the middle of the flow to scrub or modify headers before passing the email to Google.
- DKIM signing: While DKIM may pass, the domain used for signing (your domain vs. the platform's) can affect how reputation is attributed.
Key considerations
- Vendor accountability: Zendesk may need to adjust their compute server configurations or relay practices to resolve underlying deliverability issues.
- Intermediate solutions: Implementing an intermediate MTA (e.g., Postfix on a VM) could allow for custom header management and potentially improve deliverability. For more on Gmail deliverability, see our article on why Gmail SMTP emails go to spam.
- Domain reputation: For new or low-volume senders, time and consistent positive sending behavior may be required for reputation to improve.
- DMARC alignment: Ensure that DMARC is configured correctly, checking for alignment failures that could still flag emails as spam, even if SPF/DKIM pass. Learn how to fix DMARC issues in Microsoft 365.
Expert view
Expert from Email Geeks expresses skepticism about Zendesk's inherent deliverability capabilities. They highlight that since emails are relayed through the user's Gmail account, the primary authentication (SPF, DKIM, DMARC) will derive from the user's domain, not Zendesk's.
Expert view
Expert from Wordtothewise.com notes that mailbox providers use many signals beyond authentication when determining inbox placement. These include sender reputation, email content quality, and historical recipient engagement, all of which can override a passing SPF, DKIM, or DMARC.
What the documentation says
Official documentation from platforms like Zendesk and major email providers like Google typically outlines the foundational requirements for email authentication, such as SPF, DKIM, and DMARC. While this documentation is crucial for initial setup, it often does not delve into the complex, real-world scenarios where authenticated emails still land in spam. Such cases frequently arise from the nuanced interactions between third-party sending mechanisms and the advanced, often opaque, filtering logic of recipient mailbox providers.
Key findings
- SPF record configuration: Zendesk documentation emphasizes setting up an SPF record in your DNS settings to authorize Zendesk to send emails on behalf of your domain. This prevents emails from being flagged as spam and removes the via tag. Zendesk provides instructions on allowing email sending.
- Authentication basics: Documentation across various sources consistently highlights SPF, DKIM, and DMARC as fundamental for email deliverability. They are necessary, but not always sufficient. For basic authentication, see our guide to DMARC, SPF, and DKIM.
- DMARC for spam: Some documentation indicates that DMARC is crucial for preventing emails from being flagged as spam, especially when failures in alignment occur. This is a common point for troubleshooting deliverability issues.
- Google API context: When an application uses the Google API to send emails, it essentially uses the user's Gmail or Google Workspace account as the sending agent, inheriting its authentication and some reputation.
Key considerations
- Limited scope: While documentation covers proper setup, it rarely addresses the complex filtering behaviors of specific recipient domains like Microsoft, or how intermediate server configurations might complicate delivery.
- Header visibility: Documentation doesn't typically provide deep insights into how third-party platforms add or modify headers, which can be critical for troubleshooting. For instance, Microsoft's hidden SPF DNS timeout is a complex issue.
- Beyond authentication: The focus on SPF, DKIM, and DMARC in documentation, while essential, can lead to a false sense of security that these alone guarantee inbox placement.
- Specific platform nuances: Platform-specific documentation is unlikely to provide detailed troubleshooting for scenarios involving multiple interconnected services (e.g., Zendesk + Google API + AWS backend).
Technical article
Documentation from Zendesk help advises configuring SPF records to authorize sending from your domain, which helps prevent emails from being flagged as spam and removes the 'via' tag. This is a crucial first step for proper sender identification.
Technical article
Documentation from Zendesk help states that users should check their SPF and DKIM setup as a primary step to improve email deliverability and avoid spam folders. Correct authentication is presented as foundational for trustworthy email.
Related resources
4 resources
Related pages
Why are my emails having deliverability issues with Microsoft Outlook and Hotmail?
Why are my emails landing in spam even though they pass SPF, DKIM, and DMARC?
Why do my emails go to spam due to DMARC, SPF, and DKIM alignment failures?
Why your emails are going to spam in 2024 and how to fix it
How to comply with Outlook's new sender requirements
A simple guide to DMARC, SPF, and DKIM
Why your emails fail at Microsoft: the hidden SPF DNS timeout
How to fix common DMARC issues in Microsoft 365 and Google Workspace
A practical guide to understanding your email domain reputation
Why are emails going to spam in Outlook.com?
